How does HTTPS establish trust, and what does a certificate prove?

Walking the chain to a root you already trust

The server sends a leaf certificate for its own name plus, usually, one or more intermediates. Your client checks that the leaf's signature verifies under the intermediate's public key, that the intermediate verifies under the next certificate up, and so on until it reaches something it never received over the wire: a root already installed in the operating system's or browser's trust store. That root is self-signed, so it proves nothing cryptographically. It is trusted because it shipped with your device. The whole system therefore rests on a curated list of a few hundred organisations, any one of which can issue for any name. Intermediates bound the damage: root keys stay offline in hardware, intermediates do the daily signing, and a compromised intermediate can be withdrawn without disturbing everything the root anchored. Alongside the signatures, the client checks that the requested name matches a subjectAltName entry (browsers ignore the legacy common name), that the clock falls inside the validity window, and that each CA in the path is marked as one.

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null

# "Verify return code: 0 (ok)" means the chain reached a root in OpenSSL's
# trust store - not that the site behind it is honest.

What the certificate asserts, and what it does not

A certificate is a signed statement that one public key goes with one set of names. To obtain it you generate a keypair, put the public half in a signing request, and prove to the CA that you control the name - by publishing a DNS record, serving a file over HTTP, or answering mail at the domain. That is domain validation, and it covers almost every certificate on the public web. So the certificate proves control of the name at issuance, and nothing about whether the operator is who they imply. A phishing site at paypa1-secure.com gets a valid certificate and an intact padlock, because it genuinely does control that name. Organisation- and extended-validation certificates do vet a legal entity, but browsers dropped the distinctive EV interface treatment, so in practice the padlock carries only the weaker claim.

Authentication and key agreement are separate steps

Candidates routinely describe TLS as the client encrypting a session key with the server's public key. In TLS 1.3 that mechanism does not exist. The handshake runs an ephemeral Diffie-Hellman exchange, normally over an elliptic curve, and both sides derive traffic keys from a shared secret neither transmitted. The certificate's key does one job: the server signs a handshake transcript in CertificateVerify, proving it holds the private key the certificate names.

That decoupling is what forward secrecy means, and why TLS 1.3 has it by construction - RFC 8446 removed static RSA key transport and every other non-ephemeral exchange, so compromising the server key next year does not decrypt a handshake recorded today. Be precise about the exception, because interviewers probe it: resumption using psk_ke alone is not forward secret, and psk_dhe_ke restores the property by mixing in a fresh Diffie-Hellman share.

Nothing in the protocol or in issuance requires the private key to leave the machine that generated it; the server proves possession by signing, never by revealing. The corollary is that terminating TLS at a CDN or an inspecting proxy hands that party either your key or the authority to speak for your name. The cryptography stays intact and the trust boundary moves.

Revocation is the part that does not work

Issuance is strong and withdrawal is weak. Revocation lists are signed enumerations of revoked serials that clients must keep fresh, and they grew too large to fetch on the connection path. OCSP replaced the list with a per-certificate query to the CA, which leaks your browsing and adds a round trip. Worse, clients soft-fail: if the responder is unreachable the connection proceeds, because hard-failing would break the web during any CA outage. An attacker positioned to use a stolen certificate is by definition positioned to drop OCSP traffic, so the check degrades into a formality.

Stapling improves the mechanics, not the guarantee. The server fetches a short-lived signed status for its own certificate and attaches it to the handshake, removing the privacy leak and the round trip - but an attacker simply omits the staple unless the certificate carries must-staple, which almost none do. Browsers therefore moved towards pushed, compressed revocation sets computed by the vendor, Firefox's CRLite being the documented example. The real fix is shortening lifetimes so a leaked key expires on its own: the public maximum has already fallen to just over a year, the CA/Browser Forum has agreed a schedule stepping it down considerably further, and automated issuance makes that tolerable.

Pinning and Certificate Transparency

Pinning narrows trust from "any CA" to "this key": a pinning client rejects a chain that does not contain a specific public key, so a certificate mis-issued by some other CA fails even though it validates cleanly. The header-based version, HPKP, was removed from browsers because a bad pin bricked a site for as long as the header stayed cached, and it now survives mainly in mobile apps and a small set of pins compiled into Chrome. Propose it only alongside backup pins and a rotation plan.

Certificate Transparency attacks the same problem from the other side. CAs submit each issued certificate to append-only, Merkle-tree-backed public logs and get a signed timestamp in return, and Chrome will not trust a publicly issued certificate that cannot present enough of them. It prevents nothing; it makes mis-issuance discoverable, because you can monitor the logs for your own domains and learn that someone obtained a certificate you never requested. Pinning is prevention carrying an outage risk, transparency is detection carrying none, which is why the latter won.

Control of a name is not a statement of character

The answer that reads as adequate rather than strong is "the certificate proves the site is who it says it is". It proves that someone demonstrated control of a DNS name and holds the matching private key; every richer property read into the padlock is imported by assumption.

HTTPS gives you a confidential, forward-secret channel to whoever controls that name. Whether they deserve your password is a different problem.