TLS and PKI

What TLS actually has to do

TLS has two jobs that people constantly conflate: confidentiality (nobody on the wire can read the bytes) and authentication (you are actually talking to payments.example.com and not an impostor who sits between you). Encryption alone is worthless without the second part — an attacker who can intercept your traffic can just as easily run their own encrypted tunnel to you while reading everything. The whole point of the certificate machinery is to bind the encryption keys to a verified identity, so the channel is both private and provably to the right party.

TLS 1.3 (RFC 8446) is a deliberate reset of the protocol. It deleted the dangerous parts of TLS 1.2 — static RSA key exchange, CBC-mode ciphers, RC4, compression, renegotiation — and kept only forward-secret, AEAD constructions. The practical consequences are two: the handshake is faster (one round trip instead of two for a new connection, and an optional zero round trip for resumption), and the set of ways to misconfigure it shrank dramatically. There is no “downgrade to export crypto” knob left to get wrong.

The 1.3 handshake in one round trip

Here is the sequence for a fresh connection. The client opens with a ClientHello that already includes a key share — an ephemeral Diffie-Hellman public value — for the curves it guesses the server will accept. That guess is the trick that collapses two round trips into one: the client doesn’t wait to be told which parameters to use, it speculates.

The server replies with ServerHello carrying its key share. At that instant both sides can compute the shared secret via Diffie-Hellman and derive symmetric handshake keys — so everything the server sends next is already encrypted, including the certificate. Then comes the part that actually authenticates anyone:

• Certificate: the server’s leaf certificate plus the intermediate(s) needed to chain up.
• CertificateVerify: a signature, made with the certificate’s private key, over a transcript of the whole handshake so far. This is the step that proves the server holds the private key matching the public key in the certificate — not just that it can copy a certificate file someone else owns.
• Finished: a MAC over the transcript that locks the handshake against tampering.

The client validates the chain and the CertificateVerify signature, sends its own Finished, and application data flows. One round trip, end to end.

Certificates, chains, and CAs

A certificate is a signed statement: “this public key belongs to this name, and I — the issuer — vouch for it, until this expiry date.” The name lives in the Subject Alternative Name (SAN) field (the old Common Name is ignored by modern clients). Critically, the server’s leaf certificate is not trusted directly. It is signed by an intermediate CA, which is signed by a root CA. That sequence — leaf → intermediate → root — is the certificate chain.

The reason for the layer of indirection is operational, not cryptographic. Root CA private keys are kept offline in hardware security modules and almost never touched, because if a root key leaks, every certificate it ever anchored is worthless and it cannot be quietly replaced — it is burned into billions of devices. Intermediates do the day-to-day signing and can be revoked and rotated without an apocalypse. The server is expected to send its leaf and the intermediate(s); a server that ships only the leaf produces the classic “chain not trusted” error on clients that don’t happen to cache that intermediate.

How the browser decides a cert is valid

Here is the part engineers most often hand-wave. When the leaf arrives, the client runs a chain of checks, and all of them must pass — failing any one is what triggers the scary full-page warning:

1. Build the chain to a trusted anchor. The client walks leaf → intermediate → root and confirms the root is present in its trust store — the operating system’s or browser’s preinstalled list of root CAs it has decided to trust a priori. Trust is not magic; it bottoms out in this curated list of a few hundred roots. If the chain doesn’t terminate in one of them, the cert is untrusted, full stop.
2. Verify every signature up the chain. Each certificate’s signature must validate against the next certificate’s public key. A break anywhere means the chain is forged or incomplete.
3. Check validity dates. Every certificate in the chain must be within its notBefore/notAfter window. This is the expired-cert 03:00 page.
4. Check the name. The hostname the client asked for must match a SAN entry on the leaf. Connecting to payments.example.com and getting a cert for example.com with no matching SAN fails — this is what stops an attacker presenting a valid certificate for a domain they do control.
5. Check revocation. Has the CA revoked this cert early (key compromise, mis-issuance)? Checked via CRL or, more commonly, OCSP / OCSP stapling, where the server attaches a recent signed “still good” proof so the client doesn’t have to phone the CA.