<b>Why does an OCSP check almost never actually block a revoked certificate?</b>

<b>Why does an OCSP check almost never actually block a revoked certificate?</b>

OCSP (Online Certificate Status Protocol, RFC 6960) lets a client ask a CA's responder: is this certificate still valid? In theory, a revoked certificate is caught here. In practice, the dominant browser policy is soft-fail, and the mechanism quietly collapses.

Soft-fail means: if the OCSP responder is unreachable, slow, or returns an error, the client treats the certificate as valid and proceeds. The reasoning is availability — responders go down, and hard-failing would make sites unreachable. But a network attacker who can present a stolen-and-revoked certificate can also simply block the OCSP request, forcing the soft-fail path. The revocation check becomes security theater against exactly the adversary it was designed to stop.

This is not speculation. Adam Langley's 2012 analysis ("Revocation checking and Chrome's CRL") laid out the soft-fail futility argument, and Chrome subsequently disabled online OCSP for most certificates in favor of CRLSets — a curated, pushed list of high-value revocations. Firefox retains OCSP but with short timeouts and soft-fail.

The partial answer is OCSP stapling (RFC 6066, §8): the server fetches and attaches a signed, time-stamped OCSP response itself, removing the responder round-trip and the privacy leak. With the Must-Staple flag (RFC 7633), a missing staple becomes hard-fail.

<b>Further reading:</b> RFC 6960; RFC 7633; A. Langley, imperialviolet.org (2012).

<b>Bottom line:</b> Plain OCSP soft-fail stops honest mistakes, not active attackers; stapling plus Must-Staple is the only configuration that meaningfully enforces revocation.