Public Key Infrastructure

Core Idea

PKI solves the key distribution problem for public-key cryptography: how do you know that a public key actually belongs to the claimed entity? Certificate Authorities (CAs) sign X.509 certificates binding identities to public keys. Trust flows hierarchically from root CAs (pre-installed in browsers/OSes) through intermediate CAs to end-entity certificates. Revocation (CRL, OCSP) handles key compromise. Certificate Transparency logs provide public auditability. PKI is the trust backbone of HTTPS, code signing, and email encryption, but its security depends on every CA in the chain being trustworthy — a single compromised CA can forge certificates for any domain.

Explainer

Public-key cryptography solves the key distribution problem — anyone can encrypt to you using your public key without a pre-shared secret. But this introduces a new problem: how do you know a public key belongs to who it claims? If an attacker substitutes their own public key for your bank's, they can intercept all your encrypted communications. Public Key Infrastructure (PKI) solves this through a hierarchy of trust anchored in Certificate Authorities (CAs).

A CA is a trusted entity that verifies identities and issues X.509 certificates — digitally signed documents binding a public key to an identity (typically a domain name). Your browser or operating system ships with a set of root CA certificates pre-installed in its trust store. When you visit https://example.com, the server presents a certificate chain: the site's certificate (signed by an intermediate CA) and the intermediate CA's certificate (signed by a root CA). Your browser verifies each signature up the chain. If the root CA is in the trust store and all signatures are valid, the browser trusts the site's public key and proceeds with the TLS handshake. This chain of trust is what puts the padlock icon in your address bar.

The system has important fragilities. Any trusted root CA can issue a certificate for any domain. Since browsers trust hundreds of root CAs operated by organizations in dozens of countries, a single compromised or coerced CA can forge certificates for any website, enabling man-in-the-middle attacks. The DigiNotar breach (2011) demonstrated this: attackers obtained fraudulent certificates for google.com and used them to intercept Iranian users' Gmail. Certificate Transparency (CT) mitigates this by requiring CAs to log all issued certificates in public, cryptographically verifiable logs. Domain owners can monitor these logs and detect unauthorized certificates. Chrome now requires CT for all certificates, making secret certificate issuance detectable.

Certificate revocation handles key compromise after issuance. Two mechanisms exist: CRLs (Certificate Revocation Lists) are periodically published lists of revoked certificates (bulky, often stale), and OCSP (Online Certificate Status Protocol) allows real-time status checks (but adds latency and leaks browsing data). OCSP stapling improves this by having the server fetch and include a CA-signed OCSP response in the TLS handshake, eliminating the client's need to contact the CA. Despite these mechanisms, revocation remains PKI's weakest link — many browsers soft-fail (accept the certificate if revocation status cannot be checked), and revocation information propagates slowly. Short certificate lifetimes (Let's Encrypt's 90-day certificates) partially compensate by limiting the window during which a compromised certificate can be misused.