SSL / TLS guide

Public cryptography basics

TLS relies on asymmetric cryptography: each server has a private key (kept secret) and a matching public key (embedded in its certificate). Data encrypted with the public key can only be decrypted with the private key, and vice versa for signatures. In practice, TLS uses this for authentication and key exchange, then switches to faster symmetric encryption (AES) for the actual HTTP traffic.

A certificate binds a public key to one or more hostnames. It is signed by a Certificate Authority (CA) that browsers trust. Your server presents the certificate; the client verifies the signature against trusted root CAs in its store. Self-signed certs work but browsers show warnings unless you add a custom trust.

What's in a certificate

• Subject / CN — common name (legacy); modern browsers use SAN (Subject Alternative Names)
• Issuer — the CA that signed it (e.g. Let's Encrypt, DigiCert)
• Validity — notBefore and notAfter dates
• Public key — RSA or ECDSA key material
• Chain — intermediate certs linking your cert to a trusted root

The TLS handshake (client → web server)

When a browser visits https://example.com, a simplified workflow is:

1. ClientHello — client sends supported TLS versions, cipher suites, and SNI hostname
2. ServerHello — server picks TLS version and cipher; sends its certificate chain
3. Certificate verification — client checks signature, expiry, hostname (SAN), and chain to a trusted root
4. Key exchange — client and server agree on a shared session key (e.g. via ECDHE)
5. Finished — both sides confirm; encrypted HTTP requests flow over the established channel

If verification fails — expired cert, wrong hostname, untrusted CA, or incomplete chain — the browser shows a security warning or the connection is refused. Use openssl s_client to replay the handshake from the command line.

Certificate files on disk

• .key / .pem — private key (permissions must be restrictive, e.g. 600)
• .crt / .pem — server certificate (public)
• fullchain.pem — server cert + intermediates (what most servers should serve)
• chain.pem — intermediate CA certs only

Let's Encrypt (free certificates)

Let's Encrypt is a free, automated CA using the ACME protocol. Certbot is the common client on Linux: it proves domain control (HTTP-01 or DNS-01 challenge), obtains the cert, installs it, and sets up renewal (typically via systemd timer or cron). Certs are valid 90 days; renewals run automatically before expiry.

On Kubernetes, use cert-manager instead of running certbot in pods. It watches Certificate and Ingress resources, talks to Let's Encrypt (or other ACME CAs), and stores TLS secrets for your ingress controllers.

Learning resources

• Let's Encrypt — how it works — letsencrypt.org/how-it-works
• Certbot documentation — eff-certbot.readthedocs.io
• cert-manager docs — cert-manager.io/docs (Kubernetes TLS automation)
• openssl s_client(1) — man7.org — openssl s_client