The Death of OCSP: What Happens When Revocation Checking Takes a Step Backward?

The End of an Era

Let's Encrypt's decision to sunset OCSP by August 2025 isn't entirely surprising. The protocol has faced criticism for years over privacy concerns, performance impacts, and reliability issues. Yet, as someone who has worked extensively with government PKI implementations, many feel we're taking a step backward in our ability to respond to security incidents effectively.

Security Ramifications of OCSP Deprecation

In the event of a security breach, the implications of losing OCSP become starkly clear. Your private keys are compromised, and you need to revoke certificates immediately. This scenario becomes particularly concerning when proper Hardware Security Module (HSM) protection isn't in place. Organizations often copy private keys between systems and then retroactively place them in HSMs, rather than following secure practices of generating new Certificate Signing Requests (CSRs) based on key material stored exclusively in the HSM. When private keys have been copied around various systems, the risk of compromise multiplies significantly.

In a world with OCSP, clients could discover certificate revocation within seconds of your action—crucial when unsure about the full extent of key exposure. Now, the industry reverts to a polling-based approach with CRLs (Certificate Revocation Lists), where clients might continue trusting compromised certificates until their next CRL refresh. While organizations maintaining strict private key hygiene face lower risks from key compromise, many still struggle with these fundamentals.

The impact is particularly concerning for government PKI systems, where CRLs are notoriously large and unwieldy. Federal environments have seen CRLs hundreds of megabytes in size—a far cry from the real-time responses OCSP provided. While OCSP wasn't perfect, it represented a step toward real-time security being abandoned.

The Federal PKI Conundrum

This shift creates tension with current federal guidance. NIST 800-52 Rev. 2 (2019) specifically recommends OCSP as the primary method for certificate validation, with OCSP stapling strongly recommended. The federal government now faces a choice: adapt its guidance to this new reality or maintain separate requirements for federal systems.

Learning from Past Breaches

In experience investigating security incidents, misconfigured or absent revocation checking has repeatedly emerged as critical factors in breach scenarios. One case involved an organization that disabled revocation checking for performance reasons—a decision allowing attackers to continue using compromised certificates long after invalidation.

The Path Forward

The industry seems to be pushing toward shorter-lived certificates as an alternative to robust revocation checking. If certificates expire quickly enough, the vulnerability window from compromise is naturally limited. This approach creates a forcing function for organizations to automate their certificate management—ACME (Automated Certificate Management Environment) support becomes critical infrastructure. Organizations relying on manual certificate management processes will need to adapt quickly.

If you maintain your own PKI, most of this won't matter; however, if you rely on a 3rd party for certificates, you should understand their plans for revocation checking.

A Call to Action

Rather than accepting OCSP's end as inevitable, the security community should ask harder questions about why we're giving up on real-time revocation checking. Yes, OCSP had problems—privacy concerns, performance impacts, and reliability issues were real. But these challenges should drive innovation, not resignation.

The security community needs solutions providing:

• Real-time revocation checking without privacy implications
• Reliable performance scaling with the modern internet
• Robust fallback mechanisms that don't compromise security

A Ray of Hope: CRLite

While OCSP's demise might seem like a step backward, CRLite offers a promising alternative. This innovative approach addresses fundamental issues plaguing both CRLs and OCSP, using Bloom filters and Certificate Transparency logs to create an efficient, privacy-preserving solution.

CRLite offers several compelling advantages:

• Privacy Protection: Unlike OCSP, CRLite doesn't require real-time calls to CA servers, eliminating privacy concerns of exposing browsing history.
• Performance Improvements: By maintaining revocation data locally, CRLite removes performance overhead of network round-trips.
• Reliability: With no dependency on external services, CRLite eliminates the single point of failure that made OCSP checks unreliable.
• Space Efficiency: Using Bloom filters, CRLite represents all certificate revocations in compact form—around 10MB initial download with daily updates of approximately 580KB.

However, CRLite isn't without challenges:

• Device Constraints: Storage and bandwidth requirements, while modest by modern standards, might be problematic for IoT devices or environments with severe bandwidth limitations.
• CA Participation: The system requires CAs to participate by publishing revocation information in compatible format.
• Potential for Abuse: Like any revocation system, CRLite could potentially be used as a censorship tool if CAs are compelled to revoke certificates for non-technical reasons.
• Limited Browser Support: Currently, Firefox is the only browser with CRLite support.

Looking Ahead

As we approach Let's Encrypt's 2025 deadline, organizations need to:

1. Review their certificate management practices and automation capabilities
2. Evaluate their revocation checking mechanisms and plan for a post-OCSP world (at least for Let's Encrypt)
3. Consider implementing shorter certificate lifecycles as a complementary control
4. Monitor the development and adoption of alternatives like CRLite
5. Ensure their security tools and applications can handle certificates without OCSP URLs

OCSP's potential death represents an opportunity to embrace more effective solutions. CRLite, in particular, shows promise as a next-generation approach to certificate revocation. Its ability to provide reliable, privacy-preserving revocation checking without performance penalties makes it attractive for browser vendors and major platforms.

For government and high-security environments, the transition period will require careful planning. While CRLite offers many advantages, organizations should consider a defense-in-depth approach combining multiple strategies, including shorter certificate lifetimes, proper HSM usage, and robust key management practices.