PKI & Chains of Trust
A track of P53 · PKI, Certificates & TLS/HTTPS.
Certificates, certificate authorities and the chain-of-trust walk a client runs before it trusts a server — plus how certs are issued in practice (ACME/Let's Encrypt).
Your browser shows a padlock for your bank and a full-page warning for a site whose certificate expired yesterday. Both sites presented a public key. Both encrypted the connection. So what did the browser check, and on whose word did it decide that this particular key really belongs to this particular bank? You have never met your bank's server, and you certainly never configured its key. Somebody vouched for it, and this track is about who, how, and what happens when that vouching goes wrong.
A certificate is a small signed document asserting that a named public key belongs to a named subject, with a validity window. The signature comes from a certificate authority, whose own certificate is signed by another, up to a root certificate that your operating system or browser already trusts because it shipped with it. That is the chain of trust, and verifying it is a walk: check the name matches what you asked for, check the signature at each link, check the dates, check that each issuer was allowed to issue, and stop when you reach a root in your store. You will run that walk yourself, on chains that pass and chains that fail, so the browser warning stops being a mystery and becomes a named check that returned false.
The track then grounds it in practice, because certificates are no longer bought once a year and installed by hand. ACME and Let's Encrypt turned issuance into an automated proof-of-control exchange — you demonstrate that you really run the domain, and a certificate is issued and renewed by a process rather than a person. You will look at what that proof consists of, what it does and does not establish about identity, and why short lifetimes with automatic renewal are safer than long ones renewed by a calendar reminder that somebody eventually misses.