Trust · stage 03
Revocation
Withdrawing trust from a certificate turns out to be much harder than granting it.
Stage 03 of six/Trust, piece 3 of 3/Short piece/Next: The critical path
When a certificate needs to die
Issuing a certificate is instantaneous. Revoking one — genuinely, reliably, before any browser trusts it — turns out to be one of the harder problems in web security.
The scenario is straightforward: a private key leaks, a CA is compromised, or a certificate was mis-issued. The certificate must stop being trusted before its natural expiry. Two mechanisms exist to distribute that news: CRL (Certificate Revocation List), a signed file the CA publishes listing bad serial numbers, and OCSP (Online Certificate Status Protocol), a per-certificate query answered in real time. Both are specified by the IETF, and both fail in the same fundamental way.
A browser checking revocation status has to fetch data from a CA's servers. If those servers are unreachable — overloaded, blocked, simply slow — the browser must decide what to do with no answer. Historically, nearly every browser chose "soft fail": proceed as if the certificate were valid. That decision makes revocation checks almost useless against a network-level attacker, who can simply drop the OCSP traffic.
OCSP Stapling sidesteps the round-trip by having the server fetch the signed OCSP response itself and attach it to the TLS handshake. The browser receives proof of validity without making a separate network call, and the CA's infrastructure is no longer on the critical path of every connection. The OCSP Must-Staple extension, if set in the certificate, instructs browsers to reject the certificate when no valid stapled response is present — closing the soft-fail loophole, but only if the CA issues it and the server honours it.
Let's Encrypt and the CA/Browser Forum have pushed shorter certificate lifetimes as the more practical answer. A certificate that expires in forty-seven days causes far less damage if revocation fails than one valid for two years. The working assumption now is that revocation is a useful backstop, not a dependable control.
The problem is structural: the certificate chain establishes trust at the moment of issuance, but the web has no equally reliable mechanism to withdraw it.
Historically, nearly every browser chose "soft fail": proceed as if the certificate were valid.
The certificate must stop being trusted before its natural expiry.
The stage in a room: withdrawing trust from a certificate turns out to be much harder than granting it.