Day 21: TLS handshake, PKI & cert chains
TLS: privacy and authenticity on top of TCP
TLS solves two problems at once: encryption (nobody in the middle can read your traffic) and authentication (you can trust you're actually talking to the server you think you are, not an impostor).
The handshake (TLS 1.3, simplified)
- Client Hello — proposes supported cipher suites and a random value
- Server Hello — picks a cipher suite, sends its certificate (proving identity) and its own random value
- Both sides derive the same symmetric session key using key exchange (without ever sending the key itself over the wire)
- Finished — both sides confirm, and encrypted application data (HTTP) begins
Why the server's certificate matters more than the encryption math
Encryption alone doesn't stop an attacker from intercepting your connection and pretending to *be* example.com. The certificate — signed by a trusted third party — is what lets your browser verify it's really talking to example.com before it trusts anything that party sends.
PKI and certificate chains
A certificate is signed by a Certificate Authority (CA). Your OS/browser ships with a small set of trusted root CAs. A server's certificate is usually signed by an intermediate CA, which is itself signed by a root — a chain of trust. Your browser walks this chain back to a root it already trusts; if it can, the certificate is valid.
example.com's certificate
signed by → Intermediate CA (e.g. Let's Encrypt R3)
signed by → Root CA (already trusted by your OS/browser)Let's Encrypt made this practical at scale by automating domain validation and certificate issuance for free, with short 90-day certificate lifetimes that push everyone toward automated renewal (a direct ancestor of the automated cert-management approach you'll see with cert-manager in Kubernetes, Phase 11).
Key terms
- TLS handshake
- The negotiation that establishes an encrypted, authenticated connection before application data flows.
- Certificate Authority (CA)
- A trusted third party that signs certificates, vouching for the identity they claim.
- Chain of trust
- The path from a server certificate up through intermediate CAs to a root CA your client already trusts.
Why can't encryption alone (without certificates) protect you from a man-in-the-middle attack?
