Short-lived certificates or revocation infrastructure: which is the more honest way to handle compromise?

Short-lived certificates or revocation infrastructure: which is the more honest way to handle compromise?

If a private key leaks, how do you actually limit the damage — by revoking, or by ensuring the certificate expires soon anyway? The two strategies make opposite bets about whether revocation works.

Revocation (OCSP, CRLs) assumes you can reliably tell clients a still-valid certificate is now untrusted. In practice soft-fail, caching, and patchy client support make revocation unreliable — a known, documented weakness for over a decade.

Short-lived certificates take the opposite bet: if a certificate lives only days, revocation barely matters because the window of exposure is inherently small. This is why the industry trend, driven by the CA/Browser Forum, is toward dramatically shorter maximum validity — moving from years to months toward roughly 47-day ceilings — leaning on ACME automation to make frequent renewal painless.

The two are not mutually exclusive, but they prioritize differently: one invests in telling clients to distrust, the other in making distrust unnecessary.

— Automate issuance so short lifetimes are operationally free.
— Treat revocation as a backstop, not your primary containment.
— Expect maximum validity to keep shrinking; design renewal for it now.

Further reading: CA/Browser Forum ballots on validity reduction; RFC 8555 for the automation that enables it.

Bottom line: revocation tries to undo trust and often fails; short lifetimes make trust expire on its own — the industry is betting on expiry over revocation, and your automation should too.