P53 · PKI, Certificates & TLS/HTTPS

P52 ended on an unsolved problem. Diffie-Hellman lets two strangers agree a secret over a wire anyone can read, but neither of them knows who they agreed it with — an attacker in the middle can run the exchange twice, once with each side, and read everything. This pillar is the answer to that, and the answer is not more mathematics. It is a trusted third party who signed a statement about which public key belongs to which name, and a client that checks that statement carefully before it says a word.

So the pillar starts with the certificate and the chain of trust: what a certificate actually asserts, why it is signed by a certificate authority, and the walk a client performs from the server's certificate up to a root it already trusts — including how those certificates are obtained in practice, since ACME and Let's Encrypt made this an automated part of deployment rather than a purchase. Then the handshake itself, which is anticlimactic in the best way: TLS 1.3 turns out to be your Diffie-Hellman with the server's share authenticated by that certificate, followed by a key schedule that expands one shared secret into separate keys per direction — and forward secrecy falls out of the fact that the secret is fresh per connection. The attacks come with it: downgrade attempts and the man in the middle you now have the tools to stop. The pillar closes on the unglamorous practice — terminating TLS in front of your application, what a secure context means in a browser, mutual TLS — and a capstone that assembles P52 and P53 into one working secure channel.