Skip to content

The TLS Handshake

Stub — being built out

This is a stub page. The spine lives on Who Said You Could Trust That?; this page expands one piece of it: what actually happens in the half-second between click and padlock. Outline below; prose coming.

The trust structure from the main page is the why. The handshake is the how — the actual exchange where a stranger's server proves the chain and the two sides agree on keys without anyone listening in learning them.

What this page will cover

  • The negotiation — client hello / server hello, protocol version, cipher suite selection. Why TLS 1.3 collapsed the round trips and dropped the legacy footguns.
  • Where the chain check happens — the server sends its leaf (and ideally the intermediates); the client walks the chain back to a root in its store. This is the trust decision from the main page, happening live.
  • Key exchange, intuitively — how the two sides end up with a shared secret nobody on the wire can derive, and why that's not the same as the cert's keypair. Ephemeral keys and forward secrecy: why a stolen private key tomorrow shouldn't decrypt traffic captured today.
  • What "the padlock" actually asserts — and the long list of things it does not assert (that the site is honest, that the company is legitimate, that your data is handled well). The padlock means "the channel is private and the name checks out." Nothing more.
  • Common failure modes — name mismatch, expired leaf, missing intermediate (the "works in my browser, fails in curl" classic), untrusted root, clock skew.

Why it's here

If you operate services, you read handshake failures constantly — in curl -v, in openssl s_client, in load-balancer logs. Knowing which link of the chain a given error points at turns a panic into a five-minute fix.

See also: ACME and Automated Issuance for how the cert got there in the first place, and Pinning and mTLS for when one side wants to be pickier than the public CA system allows.