SSL Certificate Revocation Explained : What the End of OCSP Means for Website Security

SSL Certificate revocation provides a critical security mechanism for invalidating SSL Certificates before their expiration date.

When an SSL Certificate's private key becomes compromised, when organization details change, or when an SSL Certificate is issued incorrectly, revocation ensures browsers stop trusting that SSL Certificate immediately rather than waiting months or years for it to expire naturally.

The methods used to check SSL Certificate revocation status are undergoing significant changes in 2025. Let's Encrypt is ending support for the Online Certificate Status Protocol (OCSP), signaling a broader industry shift toward alternative approaches.

This article explains how revocation checking works, why these changes are happening, and what they mean for website operators and visitors.

Why SSL Certificate Revocation Matters

SSL Certificates are issued with validity periods that can extend up to 398 days under current industry rules.

During this time, circumstances may change in ways that require the SSL Certificate to be invalidated before its natural expiration.

Without revocation mechanisms, a compromised or incorrectly issued SSL Certificate would remain trusted until it expires, creating significant security risks.

Common Reasons for Revocation

The most serious reason for SSL Certificate revocation is private key compromise. If attackers gain access to your SSL Certificate's private key, they can impersonate your website, intercept encrypted communications, and conduct man-in-the-middle attacks. Immediate revocation prevents these attacks from succeeding with the compromised SSL Certificate.

Organizational changes also trigger revocation. If your company is acquired, changes its name, or ceases operations, existing SSL Certificates may contain outdated information. For Organization Validation (OV) and Extended Validation (EV) SSL Certificates, accurate organization details are essential to the SSL Certificate's purpose.

Certificate Authorities (CAs) occasionally issue SSL Certificates incorrectly due to validation failures, technical errors, or security breaches at the Certificate Authority (CA). When these mis-issuances are discovered, the affected SSL Certificates must be revoked to maintain trust in the overall SSL Certificate ecosystem.

The Trust Problem

Browsers inherently trust SSL Certificates signed by Certificate Authorities (CAs) in their root stores. This trust extends for the entire validity period of the SSL Certificate unless browsers have a way to learn that a specific SSL Certificate has been revoked.

Without effective revocation checking, the trust model breaks down. Attackers with access to compromised SSL Certificates could continue exploiting them indefinitely, and mis-issued SSL Certificates would undermine confidence in the entire public key infrastructure. Learn More About SSL Certificate Validation 🔗

Certificate Revocation Lists (CRLs)

Certificate Revocation Lists (CRLs) represent the original method for distributing revocation information.

A Certificate Revocation List (CRL) is a signed list published by a Certificate Authority (CA) containing the serial numbers of all revoked SSL Certificates that have not yet expired.

How Certificate Revocation Lists (CRLs) Work

Certificate Authorities (CAs) periodically generate and publish updated Certificate Revocation Lists (CRLs), typically every few hours or days. Each Certificate Revocation List (CRL) contains a list of revoked SSL Certificate serial numbers along with revocation dates and reason codes. The Certificate Authority (CA) signs the Certificate Revocation List (CRL) to prove its authenticity.

When a browser needs to check whether an SSL Certificate has been revoked, it can download the Certificate Revocation List (CRL) from a URL specified in the SSL Certificate's CRL Distribution Points extension. The browser then searches the list for the SSL Certificate's serial number. If found, the SSL Certificate is revoked and should not be trusted.

Limitations of Certificate Revocation Lists (CRLs)

Certificate Revocation Lists (CRLs) suffer from several practical limitations that have driven the development of alternative approaches.

The most significant issue is size. A Certificate Revocation List (CRL) for a large Certificate Authority (CA) can contain millions of entries, requiring substantial download time and bandwidth.

Certificate Revocation Lists (CRLs) also become stale between publication intervals. If an SSL Certificate is revoked minutes after a Certificate Revocation List (CRL) is published, browsers relying on the previous Certificate Revocation List (CRL) will not learn of the revocation until the next Certificate Revocation List (CRL) is published and downloaded. This delay creates a window during which revoked SSL Certificates remain trusted.

Despite these limitations, Certificate Revocation Lists (CRLs) remain part of the SSL Certificate ecosystem and are experiencing renewed importance as the industry moves away from Online Certificate Status Protocol (OCSP).

Online Certificate Status Protocol (OCSP)

Online Certificate Status Protocol (OCSP) was developed as an alternative to Certificate Revocation Lists (CRLs) that addresses some of their key limitations.

Instead of downloading a complete list of all revoked SSL Certificates, Online Certificate Status Protocol (OCSP) allows browsers to query the status of individual SSL Certificates in real time.

How Online Certificate Status Protocol (OCSP) Works

When a browser connects to a secure website, it can send an Online Certificate Status Protocol (OCSP) request to the Certificate Authority (CA) OCSP responder. This request contains the serial number of the SSL Certificate being checked. The Online Certificate Status Protocol (OCSP) responder looks up the SSL Certificate's status and returns a signed response indicating whether the SSL Certificate is valid, revoked, or unknown.

The Online Certificate Status Protocol (OCSP) response is much smaller than a complete Certificate Revocation List (CRL), typically just a few kilobytes. This makes Online Certificate Status Protocol (OCSP) queries faster and more bandwidth-efficient than downloading entire Certificate Revocation Lists (CRLs).

Online Certificate Status Protocol (OCSP) Soft-Fail Behavior

Early Online Certificate Status Protocol (OCSP) implementations encountered a significant practical problem. If the Online Certificate Status Protocol (OCSP) responder was unreachable due to network issues, server problems, or firewalls blocking the request, browsers had to decide whether to trust the SSL Certificate anyway or display an error to the user.

Blocking access to websites whenever Online Certificate Status Protocol (OCSP) servers experienced problems created unacceptable user experience issues. As a result, browsers implemented "soft-fail" behavior, meaning they proceed with the connection when Online Certificate Status Protocol (OCSP) queries fail rather than blocking access.

This soft-fail approach undermines Online Certificate Status Protocol (OCSP) security value. An attacker performing a man-in-the-middle attack can simply block Online Certificate Status Protocol (OCSP) requests, causing the browser to soft-fail and accept a revoked SSL Certificate. The attacker is already in a position to intercept network traffic, so blocking Online Certificate Status Protocol (OCSP) adds no additional difficulty to the attack.

Privacy Concerns

Online Certificate Status Protocol (OCSP) creates privacy implications that have concerned security researchers and privacy advocates for years. When a browser queries an Online Certificate Status Protocol (OCSP) responder, it reveals to the Certificate Authority (CA) which website the user is visiting from their specific IP address.

Even if Certificate Authorities (CAs) do not intentionally collect or retain this browsing data, the technical capability exists. Governments could potentially compel Certificate Authorities (CAs) to log and provide this information. For users concerned about browsing privacy, Online Certificate Status Protocol (OCSP) queries represent an unnecessary information leak.

Online Certificate Status Protocol (OCSP) Stapling

Online Certificate Status Protocol (OCSP) stapling was developed to address both the performance and privacy concerns associated with traditional Online Certificate Status Protocol (OCSP) checking.

With stapling, the web server queries the Online Certificate Status Protocol (OCSP) responder rather than the browser, and includes the signed Online Certificate Status Protocol (OCSP) response in the Transport Layer Security (TLS) handshake.

How Online Certificate Status Protocol (OCSP) Stapling Works

When Online Certificate Status Protocol (OCSP) stapling is enabled, the web server periodically contacts the Certificate Authority (CA) Online Certificate Status Protocol (OCSP) responder and obtains a signed Online Certificate Status Protocol (OCSP) response for its SSL Certificate.

The server caches this response and provides it to browsers during the Transport Layer Security (TLS) handshake as part of the Certificate Status Request extension.

Browsers receive the Online Certificate Status Protocol (OCSP) response directly from the server they are connecting to, eliminating the need for a separate connection to the Certificate Authority (CA).

The response remains cryptographically signed by the Certificate Authority (CA), so the server cannot forge a valid response claiming a revoked SSL Certificate is still valid.

Benefits of Online Certificate Status Protocol (OCSP) Stapling

Online Certificate Status Protocol (OCSP) stapling improves connection performance by eliminating the browser's need to make a separate Online Certificate Status Protocol (OCSP) query. All revocation information arrives as part of the main Transport Layer Security (TLS) handshake, reducing latency and connection establishment time.

Stapling also addresses the privacy concern. The Certificate Authority (CA) no longer receives queries revealing which users are visiting which websites. The web server already knows its own SSL Certificate status and provides that information directly to connecting browsers.

Limitations of Online Certificate Status Protocol (OCSP) Stapling

Online Certificate Status Protocol (OCSP) stapling requires proper server configuration, and many web servers either do not support it or have it disabled by default. Server administrators must explicitly enable and configure stapling, which does not always happen.

Popular web servers have historically implemented Online Certificate Status Protocol (OCSP) stapling in ways that create reliability concerns. If the server fails to obtain a fresh Online Certificate Status Protocol (OCSP) response before the previous one expires, connections may fail or fall back to non-stapled behavior.

These implementation challenges have limited stapling adoption.

Major Changes in 2025

The SSL Certificate industry is undergoing significant changes to how revocation checking works. These changes reflect years of experience showing that traditional Online Certificate Status Protocol (OCSP) has not delivered the security benefits originally intended while imposing costs and privacy concerns.

Let's Encrypt Ending Online Certificate Status Protocol (OCSP) Support

Let's Encrypt announced it will end Online Certificate Status Protocol (OCSP) support in 2025. As of January 30, 2025, new SSL Certificate requests including the OCSP Must-Staple extension began failing for most accounts.

On May 7, 2025, Let's Encrypt will remove Online Certificate Status Protocol (OCSP) URLs from newly issued SSL Certificates entirely and add Certificate Revocation List (CRL) URLs instead.

Let's Encrypt cited privacy as the primary reason for ending Online Certificate Status Protocol (OCSP). Their Online Certificate Status Protocol (OCSP) responders handled approximately twelve billion requests daily, revealing browsing patterns that users might prefer to keep private. The operational cost of maintaining this infrastructure provided little security benefit given soft-fail behavior.

CA/Browser Forum (CA/B Forum) Makes Online Certificate Status Protocol (OCSP) Optional

The change at Let's Encrypt follows broader industry policy shifts. In August 2023, the CA/Browser Forum (CA/B Forum) voted to make Online Certificate Status Protocol (OCSP) support optional for Certificate Authorities (CAs) while making Certificate Revocation List (CRL) support mandatory. This policy became effective in March 2024.

Microsoft updated its root program requirements in October 2024 with similar provisions, opening the door for individual Certificate Authorities (CAs) to discontinue Online Certificate Status Protocol (OCSP) services as they see fit. Other Certificate Authorities (CAs) are evaluating whether to follow Let's Encrypt's lead.

The Move Toward Short-Lived SSL Certificates

The most significant industry direction is toward shorter SSL Certificate validity periods that reduce or eliminate the need for revocation checking entirely. If an SSL Certificate is only valid for a few days, the window during which a compromised SSL Certificate could be exploited becomes very small.

The CA/Browser Forum (CA/B Forum) has been progressively shortening maximum SSL Certificate validity periods over the years, from five years to three years to two years to the current 398 days. Further reductions to forty-seven days and eventually even shorter periods are under active discussion.

How Browsers Handle Revocation Today

Modern browsers have largely moved away from real-time revocation checking in favor of proprietary mechanisms that avoid the privacy and performance issues of traditional Online Certificate Status Protocol (OCSP) while providing better security against soft-fail attacks.

CRLSets and CRLite

Google Chrome uses a mechanism called CRLSets to check revocation status. Rather than checking revocation for every SSL Certificate in real time, Google compiles information from Certificate Transparency (CT) logs and Certificate Revocation Lists (CRLs) into a compressed format that ships with Chrome updates.

This approach allows Chrome to check revocation status locally without making any network requests, eliminating both latency and privacy concerns. However, CRLSets do not cover all revoked SSL Certificates, focusing primarily on high-value SSL Certificates and those representing significant security risks.

Mozilla Firefox is developing CRLite, a similar technology that compresses revocation information into a format small enough to include in browser updates. CRLite aims to cover all revoked SSL Certificates rather than just selected high-priority ones.

Apple's Approach

Apple maintains its own revocation checking infrastructure that aggregates information from multiple sources. macOS and iOS check revocation through Apple's servers rather than directly contacting Certificate Authority (CA) Online Certificate Status Protocol (OCSP) responders in most cases.

This approach provides Apple with some control over revocation checking behavior while reducing direct privacy exposure to Certificate Authorities (CAs). However, it shifts the privacy consideration to Apple rather than eliminating it entirely.

Extended Validation (EV) SSL Certificate Handling

Browsers historically applied stricter revocation checking to Extended Validation (EV) SSL Certificates than to Domain Validation (DV) SSL Certificates. The reasoning was that Extended Validation (EV) SSL Certificates represent higher-value targets where revocation checking provides greater benefit.

As browsers have reduced the visual distinction given to Extended Validation (EV) SSL Certificates in recent years, some have also relaxed Extended Validation (EV) specific revocation checking requirements. The general trend is toward consistent handling of all SSL Certificate types. Learn More About Extended Validation (EV) SSL Certificates 🔗

What These Changes Mean for Website Operators

The evolution of revocation checking has several practical implications for organizations that operate websites secured by SSL Certificates.

Online Certificate Status Protocol (OCSP) Stapling Configuration

For SSL Certificates from Certificate Authorities (CAs) that continue offering Online Certificate Status Protocol (OCSP), enabling Online Certificate Status Protocol (OCSP) stapling remains a best practice.

Stapling improves connection performance and demonstrates good security hygiene. However, stapling becomes irrelevant for SSL Certificates from Certificate Authorities (CAs) that have discontinued Online Certificate Status Protocol (OCSP).

Newer SSL Certificates from some Certificate Authorities (CAs) may contain only Certificate Revocation List (CRL) URLs.

SSL Certificate Lifecycle Management

As the industry moves toward shorter validity periods, SSL Certificate lifecycle management becomes more important. Organizations accustomed to annual SSL Certificate renewals may need to adapt to more frequent renewals or implement automated SSL Certificate management.

Automated Certificate Management Environment (ACME) based automation, which Trustico® supports through our Certificate as a Service (CaaS) platform, enables automatic SSL Certificate renewal without manual intervention. This automation becomes essential as validity periods shorten. Learn More About Certificate as a Service (CaaS) 🔗

Revocation Planning

Understanding how quickly revocation information propagates helps when you need to revoke an SSL Certificate. With browsers relying on aggregated revocation data rather than real-time Online Certificate Status Protocol (OCSP) checks, there may be delays before all browsers learn of a revocation.

For critical security incidents involving key compromise, replacing the SSL Certificate and updating your server is more important than waiting for revocation to propagate. Attackers exploiting a compromised key will not wait for revocation checking to catch up.

Trustico® and SSL Certificate Revocation

Trustico® SSL Certificates include all standard revocation-related extensions. Our SSL Certificates contain the URLs necessary for browsers to check revocation status using whatever mechanism they implement.

If you need to revoke an SSL Certificate obtained through Trustico® you can utilize our tracking and management portals. Alternately our support team can process revocation requests promptly. Explore Our SSL Certificate Management Portal 🔗

Revoked SSL Certificate information propagates to browsers through the mechanisms described in this article, ensuring that the revoked SSL Certificate stops being trusted.

Our automated Certificate as a Service (CaaS) platform supports rapid SSL Certificate replacement in situations requiring revocation.

When an SSL Certificate must be revoked, obtaining and deploying a replacement quickly minimizes disruption to your website's availability.

The Future of SSL Certificate Revocation

The SSL Certificate industry continues evolving its approach to revocation as experience reveals the limitations of traditional methods. Several trends suggest where revocation checking is heading.

Shorter Validity Periods

The most significant change will be progressively shorter SSL Certificate validity periods. As SSL Certificates become valid for weeks rather than months, the importance of revocation checking diminishes. A compromised SSL Certificate that expires in days poses far less risk than one remaining valid for a year.

Organizations should prepare for a future where SSL Certificate renewal happens monthly or even more frequently. Automation becomes not just convenient but essential in this environment.

Centralized Revocation Infrastructure

Browser vendors operating their own revocation checking infrastructure represents a likely continued trend. This approach gives browsers control over the privacy and security tradeoffs while reducing dependence on Certificate Authority (CA) infrastructure.

Website operators benefit from this shift through faster revocation propagation when it matters most. High-profile security incidents can trigger manual addition of compromised SSL Certificates to browser revocation databases, providing faster protection than waiting for normal Certificate Revocation List (CRL) publication cycles.

Certificate Transparency (CT) Integration

Certificate Transparency (CT) logs, which record all publicly issued SSL Certificates, provide infrastructure that can potentially support revocation use cases. Research continues into methods for efficiently communicating revocation status through Certificate Transparency (CT) based mechanisms.

Whatever specific technologies emerge, the direction is clearly toward approaches that do not require real-time queries to Certificate Authority (CA) infrastructure for every connection.

Frequently Asked Questions

Website operators and security professionals commonly have questions about SSL Certificate revocation and the changes occurring in 2025.

Will My SSL Certificate Stop Working When Let's Encrypt Ends Online Certificate Status Protocol (OCSP)?

No, SSL Certificates continue functioning normally regardless of Online Certificate Status Protocol (OCSP) availability.

Browsers that previously checked Online Certificate Status Protocol (OCSP) will simply not perform that check for SSL Certificates lacking Online Certificate Status Protocol (OCSP) URLs.

The encrypted connection remains secure. Revocation checking is about identifying compromised SSL Certificates, not about enabling encryption.

Should I Enable Online Certificate Status Protocol (OCSP) Stapling on My Server?

If your SSL Certificate includes an Online Certificate Status Protocol (OCSP) URL and your server software supports stapling, enabling it remains a good practice.

Stapling improves performance and demonstrates security-conscious configuration.

How Do I Revoke an SSL Certificate If Online Certificate Status Protocol (OCSP) Is Going Away?

SSL Certificate revocation continues working through Certificate Revocation Lists (CRLs) and browser-specific mechanisms even without Online Certificate Status Protocol (OCSP).

Contact our support team at Trustico® to request revocation, and the information will propagate through available channels.

Certificate Revocation Lists (CRLs) remain mandatory for all Certificate Authorities (CAs) under current rules.

Are Short-Lived SSL Certificates More Secure Than Traditional SSL Certificates?

Short-lived SSL Certificates reduce the window during which a compromised SSL Certificate can be exploited, which improves security in that specific dimension.

However, they require robust automation to avoid service disruptions from expired SSL Certificates. The security benefit comes from limiting exposure time rather than any cryptographic difference.

Do These Changes Affect Extended Validation (EV) SSL Certificates?

Extended Validation (EV) SSL Certificates are subject to the same revocation checking mechanisms as other SSL Certificate types.

The changes in Online Certificate Status Protocol (OCSP) support and the move toward shorter validity periods apply across all validation levels.

Extended Validation (EV) SSL Certificates continue providing organization identity verification regardless of how revocation checking evolves.