PKI, CAs, and Revocation

Public Key Infrastructure is the whole system that makes a certificate worth trusting: the Certificate Authorities that issue them, the trust stores that anchor the roots, and the revocation machinery that can invalidate a certificate before its natural expiry. Issuing certificates is the easy part. The hard problem PKI has never fully solved is revoking a compromised one fast enough to matter.

When a server's private key leaks, its certificate is still cryptographically valid until its not-after date — the attacker can impersonate the server until then unless revocation reaches the client first. Two mechanisms, CRL and OCSP, were built to deliver that signal, both scale poorly, and the industry's pragmatic answer turned out to be making certificates so short-lived that revocation barely matters.

The Trust Anchors

Every chain terminates at a root CA whose self-signed certificate is preinstalled in a trust store — the set Mozilla, Apple, Microsoft, and Google curate and ship with browsers and operating systems. Membership is a privilege governed by audits and the CA/Browser Forum baseline requirements; a CA that misissues badly enough gets distrusted and removed, as happened to Symantec's and DigiNotar's roots.

The trust decision is therefore not yours but the trust-store maintainers'. Your client trusts roughly 150 root CAs by default, and any of them can issue a certificate for any domain. That is PKI's structural weakness: the system is only as trustworthy as its least careful CA, which is what name constraints and Certificate Transparency exist to contain.

Revocation: CRL versus OCSP

A Certificate Revocation List (CRL) is a signed file the CA publishes listing the serial numbers of every certificate it has revoked. A client downloads the whole list and checks membership. The problem is size and freshness: a busy CA's CRL grows to megabytes, clients cache it for hours, and a certificate revoked five minutes ago is not on the copy the client already holds.

OCSP (Online Certificate Status Protocol) trades the bulk download for a per-certificate query: the client asks the CA's responder "is serial X still good?" and gets a small signed answer. It is fresher but adds a network round trip to a third party on the connection's critical path, leaks to the CA which sites the user visits, and — the fatal flaw — clients soft-fail. If the responder is slow or down, browsers proceed as if the certificate were valid rather than block the page, which means an attacker who can block the OCSP query also defeats the check.

# query a cert's revocation status directly via OCSP
openssl ocsp -issuer chain.pem -cert server.pem \
  -url http://ocsp.example-ca.org -no_nonce
# Response verify OK
# server.pem: good       <- not revoked, this instant
#   This Update: ...  Next Update: ...

OCSP Stapling and Short-Lived Certificates

OCSP stapling fixes the round trip and the privacy leak. The server itself queries the OCSP responder periodically, caches the signed "good" response, and staples it into the TLS handshake. The client gets a fresh, CA-signed status with zero extra connections and without telling the CA which user is visiting. The status is still only as current as the staple's refresh interval, but it removes the responder from every client's critical path.

The deeper fix is short-lived certificates. If a certificate lives 90 days — or 7, or 1 — the window in which a leaked key is useful shrinks to that lifetime, and revocation stops being load-bearing because the certificate expires before a CRL would have propagated anyway. Let's Encrypt's 90-day default and the move toward even shorter spans are this strategy: rather than fix revocation, make certificates expire fast enough that you rarely need it. The catch is it only works with automated renewal.

CA Compromise and Containment

Because any trusted CA can sign for any domain, a single compromised or coerced CA is a global threat — DigiNotar's 2011 breach produced fraudulent Google certificates used to intercept Iranian users. Two mechanisms limit the blast radius. Name constraints restrict an intermediate to specific domains, so an internal CA scoped to corp.example.com cannot mint a valid certificate for a bank.

Certificate Transparency (CT) requires every publicly trusted certificate to be logged in append-only, publicly auditable logs, and browsers reject certificates that lack a proof of logging. A domain owner monitoring CT logs sees any certificate issued for their name within minutes — including a misissued one — turning silent misissuance into a detectable, attributable event. CT does not prevent a bad CA; it guarantees you find out.