Does your browser actually reject a revoked certificate?

Does your browser actually reject a revoked certificate?

The assumption "if a certificate is revoked, my browser will block it" describes how revocation is supposed to work, not how it does. Two legacy mechanisms — CRLs (Certificate Revocation Lists, RFC 5280) and OCSP (Online Certificate Status Protocol, RFC 6960) — both fail open. CRLs grew too large to download routinely. OCSP checks add latency and leak browsing to the CA, so browsers adopted soft-fail: if the responder is slow or unreachable, the browser proceeds as if the certificate were valid.

Adam Langley's well-known critique called soft-fail revocation "useless," because any attacker capable of using a stolen certificate can also block the revocation check — the same network position enables both. Chrome largely disabled live OCSP years ago in favor of CRLSets, a curated push of high-priority revocations; Firefox built CRLite, a compressed Bloom-filter structure pushed to the browser.

These push-based systems work because the browser already has the answer before the handshake, so there is nothing for an attacker to block. But they cover a subset of revocations, not all.

— CRL/OCSP fail open by default
— Soft-fail is defeatable by the same attacker
— CRLSets/CRLite push a curated subset

Further reading: Langley, "Revocation checking and Chrome's CRL" (2012); Firefox CRLite.
Bottom line: Live revocation checking is mostly theater. Browser-pushed lists and short certificate lifetimes are what actually protect you.