TLS and the certificate chain of trust

Lessons 2–3 covered how to encrypt data once a shared or exchanged key exists — but that alone doesn't answer a different, equally important question: how does a browser know the server it just connected to is actually the real one, and not an attacker intercepting the connection and presenting their own key as if it belonged to the legitimate site? Without solving this, an attacker could perform a man-in-the-middle attack — transparently relaying (and reading) traffic between a victim and the real site, with encryption in place the entire time.

A TLS certificate is a digitally signed document (lesson 4's signing mechanism, applied here) stating "this public key belongs to example.com," signed by a Certificate Authority (CA) — an organization browsers are configured to trust in advance:

When a browser connects to example.com, the server presents this certificate. The browser verifies the CA's signature on it (exactly the signature-verification process from lesson 4) — if the signature checks out, the browser trusts that the public key in the certificate genuinely belongs to example.com, without ever having communicated with example.com before.

Certificates typically form a chain: a root CA (built into the browser or operating system's trust store) signs an intermediate CA's certificate, which in turn signs the actual website's certificate:

The browser verifies each link in the chain, ultimately checking that the whole chain traces back to a root it already trusts — this indirection lets a small, stable set of root CAs (pre-installed and rarely changed) support an enormous, constantly-changing number of actual websites without every browser needing to individually trust every website operator directly.

Beyond the public key, a certificate includes the domain name(s) it's valid for, an expiration date, and the issuing CA's identity — all of it covered by the CA's signature, so altering any of it invalidates the signature and makes the certificate fail verification. Expiration exists specifically to limit the damage of a compromised key or an outdated security configuration — a certificate isn't trusted forever, and a site's operators have to periodically prove control of the domain again to renew it.

A self-signed certificate is one signed by its own private key instead of a recognized CA — it still enables genuine encryption, but a browser has no reason to trust that the public key inside actually belongs to who it claims to, since there's no chain back to a pre-installed trusted root. This is exactly why browsers show a warning for self-signed certificates — the encryption itself works fine, but the identity claim has no independently verifiable backing, which is precisely the man-in-the-middle risk this whole lesson opened with.

A real TLS handshake combines everything from this domain so far: the server presents its certificate (verified via lesson 4's signature mechanism, and this lesson's chain of trust); the client and server perform a key exchange (lesson 6's Diffie-Hellman, typically) to agree on a session key; and all subsequent data uses fast symmetric encryption (lesson 2) with that session key. Lesson 12 walks through this entire sequence as one coherent flow, once every individual piece has been covered on its own.