🔒 SSL/TLS Certificates

Why HTTPS?

Imagine mailing a bank withdrawal slip on a postcard. Every postal worker along the route can read your account number, and any of them could cross out the amount and write in a bigger one. Plain HTTP is exactly that postcard: it travels in clear text across dozens of routers, Wi-Fi access points, and ISPs, any of which can read or rewrite it.

HTTPS is HTTP inside a sealed, tamper-evident envelope. That envelope is TLS (Transport Layer Security), the modern successor to the older SSL protocol. The names are used interchangeably — "SSL certificate" is the common phrase — but every secure connection today speaks TLS, not the long-deprecated SSL.

Since 2018, browsers mark plain HTTP pages as "Not Secure." Beyond trust, HTTPS is now a hard requirement for modern web features — service workers, HTTP/2, the geolocation and camera APIs — and it's a Google ranking signal. There is no longer a reason to run a public site without it.

What TLS Actually Does

TLS delivers three distinct guarantees. It helps to keep them separate, because a certificate is only responsible for one of them.

This is the key insight: encryption alone is not enough. Anyone can generate an encryption key. Without identity, you might be exchanging perfectly encrypted messages with an attacker sitting in the middle. The certificate is what binds a public key to a verified domain name, so identity and encryption together defeat the "man in the middle."

The TLS Handshake

Before the first byte of your web page moves, the browser and server run a quick negotiation called the handshake. Its job: verify the server's identity and agree on a secret key that only the two of them know.

Walking through it: the browser lists what it supports, the server picks the strongest common option and presents its certificate, the browser checks that certificate is trustworthy (next section), and then both sides derive a fresh session key. From that point every HTTP request and response is encrypted with that key. TLS 1.3 compresses this into a single round trip, so the security cost is milliseconds.

Certificates & the CA Chain

How does your browser decide a certificate is legitimate? It doesn't trust your server directly — it trusts a small set of Certificate Authorities (CAs) whose root certificates ship with the operating system and browser. Your certificate is trusted because a CA signed it, forming a chain up to one of those pre-trusted roots.

Each link is a cryptographic signature: the intermediate signs your certificate, the root signs the intermediate. If the browser can follow the signatures all the way to a root it already trusts — and the domain matches, and it hasn't expired — the padlock appears. Break any link (a missing intermediate, wrong domain, expired date) and the user sees a warning.

What's inside a certificate

• Subject — the domain(s) it's valid for (the Common Name and Subject Alternative Names)
• Public key — used during the handshake
• Issuer — which CA signed it
• Validity period — not-before and not-after dates
• Signature — the CA's cryptographic stamp of approval

# Inspect the certificate a live server is serving
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

Let's Encrypt & certbot

Not long ago, certificates cost money and were installed by hand once a year. Let's Encrypt, a non-profit CA launched in 2016, changed the web by issuing certificates that are free, automated, and open. It now secures hundreds of millions of domains.

The magic is the ACME protocol (Automated Certificate Management Environment). Instead of a human proving domain ownership, a program does it: it proves you control the domain, and the CA issues a certificate — all in seconds, all repeatable.

Domain validation challenges

• HTTP-01: certbot places a token at /.well-known/acme-challenge/ and Let's Encrypt fetches it over port 80. Simplest for a single server.
• DNS-01: certbot creates a TXT record on your domain. Required for wildcard certificates and works even when the server isn't publicly reachable.

Getting a certificate with certbot

# Install certbot and the Nginx plugin (Ubuntu/Debian)
sudo apt update
sudo apt install certbot python3-certbot-nginx

# Obtain a certificate AND auto-configure Nginx to use it
sudo certbot --nginx -d example.com -d www.example.com

# Or just fetch certificates without touching server config
sudo certbot certonly --nginx -d example.com

# Wildcard certificate (requires the DNS challenge)
sudo certbot certonly --manual --preferred-challenges dns \
  -d example.com -d '*.example.com'

# Simulate a renewal without actually issuing a new cert
sudo certbot renew --dry-run

# Check the timer is active
systemctl status certbot.timer

TLS Termination & Nginx

Where does encryption get decrypted? In almost every real deployment, not in your Node.js app. Instead a reverse proxy or load balancer sits in front, decrypts TLS, and forwards plain HTTP to your app over a trusted internal network. This is called TLS termination.

Terminating at the proxy means your app doesn't manage certificates, the proxy handles TLS efficiently for every backend, and you can scale app instances freely behind one certificate. Managed platforms (Render, Vercel, AWS ALB, Cloudflare) do this for you automatically — you often never touch a .pem file.

Nginx TLS configuration

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

    # Certificate paths from certbot
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # Modern, secure protocols only
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers off;      # let TLS 1.3 pick; modern guidance
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;

    # Forward to the Node app over plain HTTP on the internal network
    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;   # so the app knows it was HTTPS
    }
}

Redirects, HSTS & Cert Types

Redirect HTTP to HTTPS

Serving HTTPS isn't enough if users can still reach the insecure version. Redirect every HTTP request to HTTPS with a permanent 301.

# A second server block catches plain HTTP and bounces it to HTTPS
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

HSTS — remove the insecure window

Even a redirect has a gap: the very first request travels over HTTP and could be hijacked. HSTS (HTTP Strict Transport Security) closes it. Once a browser sees this header, it refuses to talk to your domain over HTTP at all — for the entire max-age.

# Add inside the HTTPS server block. Two years, including subdomains.
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

Choosing a certificate shape

A wildcard covers only one level (api.example.com, not v1.api.example.com) and requires the DNS-01 challenge to issue. For most projects, a single cert listing example.com and www.example.com via SAN is exactly right.

Practice & Quiz

server {
    listen 80;
    server_name myapp.com www.myapp.com;
    return 301 https://$host$request_uri;
}

# Wildcards require the DNS-01 challenge (a TXT record proves control)
sudo certbot certonly --manual --preferred-challenges dns \
  -d shop.io -d '*.shop.io'

Best Practices & Pitfalls

✅ Do

• Use free, auto-renewing Let's Encrypt certificates and verify the renewal timer
• Serve fullchain.pem so the full CA chain validates for everyone
• Restrict to TLS 1.2 and 1.3; disable everything older
• Redirect HTTP → HTTPS and add HSTS once you're confident
• Terminate TLS at a proxy/load balancer and keep the private key at chmod 600

❌ Don't

• Commit private keys to git or copy them into container images
• Let renewal be a manual calendar reminder (it will be missed)
• Enable HSTS preload before every subdomain is HTTPS-ready
• Serve mixed content — HTTP assets on an HTTPS page get blocked

Summary

📚 Additional Resources

• Let's Encrypt — Getting Started
• certbot (EFF) documentation
• MDN — Transport Layer Security (TLS)
• MDN — HTTP Strict-Transport-Security (HSTS)
• Mozilla SSL Configuration Generator

🚀 What's Next?

Your certificate is issued for a domain name — but a certificate is useless if that name doesn't point at your server. The next lesson covers Domain Configuration: DNS records (A, AAAA, CNAME, TXT, MX), apex vs www, TTL and propagation, and pointing your domain at a host or load balancer.