Digital Signatures, Certificates

The Story That Explains Digital Signatures

Every time you see a padlock next to a URL, three cryptographic tools are working together in a fraction of a second: digital signatures prove authenticity, certificates prove identity, and SSL/TLS wraps the entire connection in a private tunnel. This tutorial pulls all three apart and shows how they lock together.

The Three Problems Cryptography Must Solve

When Alice sends a message to Bob over the internet, three separate things can go wrong. Digital signatures and TLS solve each one with a different tool.

Symmetric vs Asymmetric Encryption

Before signatures make sense, you need to understand the two families of encryption. TLS uses both — for different reasons at different moments in the handshake.

How a Digital Signature Actually Works

A digital signature is not encryption of the whole message. It is a tiny fingerprint that only the private-key holder could have produced, and anyone with the public key can verify. Here is the exact recipe.

Digital Certificates — The Passport Problem

Without certificates, an attacker could send you their own public key and pretend to be your bank. You would encrypt your password with the attacker's key and send it directly to them. Certificates solve this by binding a public key to a verified identity.

Inside an X.509 Certificate

All internet certificates follow the X.509 standard. When your browser connects to a site, it receives one of these — usually a few kilobytes of structured data. Here is what is actually inside.

Reading a Certificate with OpenSSL

# Fetch the certificate that google.com currently presents
openssl s_client -connect google.com:443 -servername google.com < /dev/null | \
  openssl x509 -noout -text

# Show only the important bits
openssl s_client -connect google.com:443 < /dev/null | \
  openssl x509 -noout -subject -issuer -dates

The Chain of Trust

A browser does not know every certificate on earth. What it knows is a small list of Root Certificate Authorities — about 150 organisations whose public keys ship pre-installed with Windows, macOS, Firefox, Chrome, and Android. Everything else is trusted transitively.

SSL vs TLS — Naming and History

You will hear "SSL" and "TLS" used interchangeably, but they are not the same protocol. SSL is dead. TLS is what actually runs on the web today. The name "SSL" survives out of habit — like calling a smartphone a "phone".

The TLS 1.3 Handshake — Animated

Here is what actually happens in the ~50 milliseconds between typing a URL and seeing the padlock. TLS 1.3 completes the handshake in a single round trip, then encrypted data flows.

Hands-On — Inspecting a Live TLS Connection

1. See the full handshake

# Show cipher suite, cert chain, protocol version
openssl s_client -connect www.wikipedia.org:443 -servername www.wikipedia.org

# Force TLS 1.3 only
openssl s_client -connect www.wikipedia.org:443 -tls1_3

# Refuse anything below TLS 1.2 (test if a server is properly configured)
openssl s_client -connect example.com:443 -tls1_1   # should FAIL on any modern server

2. Generate your own certificate (self-signed, for local testing)

# Create a 2048-bit RSA private key
openssl genrsa -out mysite.key 2048

# Generate a Certificate Signing Request (CSR)
openssl req -new -key mysite.key -out mysite.csr \
  -subj "/C=IN/ST=HP/L=Solan/O=DevOps/CN=mysite.local"

# Self-sign it (valid 365 days) — DEV ONLY, browsers will still warn
openssl x509 -req -days 365 -in mysite.csr \
  -signkey mysite.key -out mysite.crt

# Inspect what you just made
openssl x509 -in mysite.crt -noout -text

3. Get a real, browser-trusted cert with certbot (Let's Encrypt)

# One command → free, auto-renewing, publicly trusted certificate
sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com

# Certbot then auto-installs a cron job that renews before day 90
sudo certbot renew --dry-run

4. Verify with curl

# Fetch a page and dump certificate details in one go
curl -vI https://www.wikipedia.org 2>&1 | grep -E "SSL|subject|issuer|expire"

# Reject connection if cert is bad (default behaviour anyway)
curl https://self-signed.badssl.com  # fails with cert error
curl -k https://self-signed.badssl.com  # -k bypasses (never do in prod)

Real-World Cases — When Certificates Broke the News

Common Attacks Against SSL/TLS

HSTS, Certificate Transparency, and Modern Defences

Enabling HSTS in nginx

# /etc/nginx/sites-available/example.com
server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # Only allow TLS 1.2 and 1.3
    ssl_protocols   TLSv1.2 TLSv1.3;
    ssl_ciphers     ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
    ssl_prefer_server_ciphers off;

    # HSTS: 2 years, cover subdomains, ready for preload list
    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
}

SSL/TLS vs Predecessors — Why This Layer Exists

Golden Rules