OCSP and CRL: Certificate Revocation

Certificate revocation mechanisms allow Certificate Authorities to invalidate certificates before they expire. When a private key is compromised, domain ownership changes, or other security issues arise, the certificate must be revoked. OCSP (Online Certificate Status Protocol) and CRLs (Certificate Revocation Lists) are the two primary mechanisms for checking revocation status.

Here's the uncomfortable truth: we built elaborate systems to revoke trust, then configured them to fail silently because actually checking would slow down your browsing.

Why Certificate Revocation Exists

Certificates have expiration dates, but sometimes they need to be invalidated immediately. A private key gets stolen. A domain changes ownership. A CA issues a certificate to the wrong party. Without revocation, a compromised certificate remains trusted until expiration—potentially months or years of exploitation.

The need is clear. The execution is where everything falls apart.

Certificate Revocation Lists (CRLs)

CRLs are the oldest approach. A Certificate Authority maintains a signed list of revoked certificate serial numbers and publishes it periodically. Clients download the list and check whether a certificate appears on it.

The problem is scale. Popular CAs might revoke thousands or millions of certificates. Downloading complete CRLs for every CA you encounter is impractical. And CRLs update slowly—if a CA publishes daily, a certificate revoked this morning might not appear until tomorrow.

For routine operations, CRLs are too slow. For emergencies, they're far too slow.

Online Certificate Status Protocol (OCSP)

OCSP was designed to fix CRLs. Instead of downloading complete lists, clients query an OCSP responder about specific certificates. The certificate includes the responder's URL. The client asks "is this certificate revoked?" and gets back "good," "revoked," or "unknown."

This is more efficient—you only ask about certificates you're actually checking. Responses can reflect revocations within minutes rather than days.

But OCSP creates new problems.

Why OCSP Fails in Practice

Privacy leakage. Every OCSP query tells the CA which certificate you're checking—effectively revealing which websites you're visiting. Your browsing history, leaked to certificate authorities.

Performance cost. Every HTTPS connection requires an additional round-trip to the OCSP responder. Users notice the latency.

The soft-fail disaster. Here's where it all breaks down. OCSP responders sometimes fail. They go down, they're slow, they're blocked by firewalls. If browsers refused to connect when OCSP failed, the Internet would constantly break.

So browsers soft-fail. If the OCSP responder is unreachable, the browser accepts the certificate anyway.

Think about what this means. The revocation check works perfectly—until there's an actual attack. An attacker who compromises a certificate simply blocks OCSP queries. The browser shrugs and connects anyway. It's like a smoke detector that turns itself off when it smells smoke.

OCSP Stapling

OCSP Stapling addresses the privacy and performance problems. Instead of the client querying the OCSP responder, the server does it. The server periodically fetches its own OCSP response and "staples" it to the TLS handshake.

No client-to-CA traffic. No privacy leakage. No latency penalty. The client still gets revocation information, but from the server rather than a separate query.

This actually works well—when servers implement it. Many don't. And if the server's stapling configuration breaks, connections fail, so operators are cautious about enabling it.

Must-Staple

The Must-Staple certificate extension tells clients: reject this certificate if the server doesn't provide a stapled OCSP response. This prevents attackers from disabling stapling to avoid revocation detection.

Adoption is minimal. Must-Staple creates operational risk—if stapling breaks, everything breaks. Most operators won't accept that trade-off.

Browser Approaches: CRLSets and OneCRL

Chrome and Firefox gave up on real-time revocation checking for most certificates. Instead, they distribute compact revocation lists with browser updates.

Chrome's CRLSets and Firefox's OneCRL contain only high-priority revocations—CA compromises, major incidents, certificates that absolutely must be blocked everywhere. These lists are small enough to ship to every browser user.

This works for emergencies. It doesn't scale to routine revocations. If your individual website certificate is compromised, CRLSets won't help you.

The Harsh Reality

Certificate revocation is widely acknowledged as broken:

• Soft-fail means revocation checks don't work during actual attacks
• OCSP without stapling leaks your browsing history
• Real-time checking adds latency users won't tolerate
• No mechanism reliably covers all certificates

The security community's response has been pragmatic: if we can't fix revocation, reduce our dependence on it.

Short-Lived Certificates

If certificates expire quickly, revocation matters less. A compromised certificate that expires in three days creates a much smaller window than one valid for two years.

Let's Encrypt issues 90-day certificates. Some proposals push for 7-day or even 1-day lifetimes. At that point, revocation becomes nearly irrelevant—just wait for expiration.

This requires seamless automation. If humans must manually renew certificates every week, things will break. But automation is increasingly practical.

CRLite and the Future

Mozilla's CRLite compresses all revocation information into efficient filters small enough to distribute to every browser. Instead of querying responders or downloading massive lists, browsers could check revocation locally against compact, frequently-updated filters.

This could finally make revocation work without the privacy, performance, or reliability trade-offs. It's not yet widely deployed, but it represents the most promising path forward.

Checking Revocation Status

Despite the limitations, you can check certificate revocation:

OpenSSL with OCSP:

openssl ocsp -issuer issuer.pem -cert cert.pem -url http://ocsp.example.com -CAfile root.pem

Browser developer tools sometimes show OCSP status in their security panels.

SSL Labs and similar services check revocation as part of comprehensive certificate analysis.

What Actually Works

Revocation isn't completely useless:

Major incidents get handled through CRLSets/OneCRL, which distribute revocations quickly and universally.

Proper OCSP Stapling provides reliable revocation information without the costs of client-side checking.

Short certificate lifetimes reduce the window where revocation would matter.

The trend is clear: either eliminate the need for revocation through short lifetimes, or develop distribution mechanisms that don't require real-time queries. The era of "ask the CA if this certificate is still good" is ending—not because it was a bad idea, but because the Internet couldn't tolerate the failure modes.