OCSP stapling or CRLs: which revocation channel should you actually trust?

OCSP stapling or CRLs: which revocation channel should you actually trust?

What happens when a client tries to learn whether your certificate has been revoked? Two mechanisms compete, and the tradeoff is not symmetric.

Classic OCSP (Online Certificate Status Protocol, RFC 6960) has the client query the CA's responder per-certificate. This leaks the user's browsing target to the CA and adds a blocking round trip. Most browsers responded by soft-failing: if the responder is unreachable, they proceed anyway, which gutted the security value.

OCSP stapling (RFC 6066, the certificate_status extension) flips the direction. Your server fetches the signed OCSP response and attaches it to the handshake. No client-to-CA leak, no extra round trip, and the response is cached server-side for hours.

CRLs (Certificate Revocation Lists, RFC 5280) are the old batch model: a signed list the client downloads wholesale. They scaled poorly until CRLite and Mozilla's compressed-CRL push made browser-side aggregation viable again.

— Use stapling for performance and privacy; it is the default win.
— Treat plain client OCSP as effectively decorative under soft-fail.
— Watch CRLite-style aggregation: it is where browsers are actually heading.

Further reading: RFC 6960; RFC 6066 §8; Mozilla's CRLite research papers.

Bottom line: stapling beats client OCSP on every axis, but the revocation endgame is browser-pushed CRL aggregation, not live queries.