What is certificate revocation?
Certificate revocation is the process of invalidating the operational trust status of a digital certificate (X.509) before its scheduled expiration date. It's carried out by the certificate authority (CA) that originally issued the certificate, and it produces a cryptographically signed statement that tells relying parties (e.g., browsers, applications, and servers) to stop trusting that certificate.
Unlike expiration, which is time-bound and predictable, certificate revocation is reactive. Think of it like revoking a driver's license. A license is valid until its expiration date, but if the holder commits a serious violation or the license is stolen, the issuing authority can revoke it immediately. Digital certificate revocation works the same way.
When a private key is compromised, the certificate holder's identity changes, or a policy violation occurs, the CA must revoke the certificate and communicate that change to any system that might rely on it. It requires the issuing CA to publish a signed statement declaring the certificate invalid. If this data doesn't reach the relying party, like the client or browser, the compromised certificate remains trusted, which is a serious risk.
When should a certificate be revoked?
Certificates are usually revoked due to one of the following scenarios. By knowing these risks, your organization's security teams will be able to build the right response infrastructure ahead of time.
- 01.
Private key compromise
This is the most critical scenario. When an unauthorized party gains access to a private key, the cryptographic guarantee behind the associated certificate is worthless. The attacker can impersonate the certificate holder, decrypt intercepted traffic, and sign malicious code as if they were the legitimate entity.
Since the certificate appears valid and is signed by a trusted CA, browsers and applications accept it without question. Without rapid revocation, threat actors can execute manipulator-in-the-middle (MitM) attacks by presenting the stolen certificate to unsuspecting clients.
- 02.
Employee offboarding and organizational changes
When an employee leaves an organization, any certificates issued to their accounts must be immediately revoked. Without this step, former employees can maintain access through certificate-based authentication, which often bypasses password changes and MFA controls entirely.
The same applies to domain ownership transfers, company name changes, and service decommissioning. When a web service shuts down, its TLS certificate should be explicitly revoked rather than left to expire naturally.
Certificate revocation methods: CRL vs. OCSP vs. OCSP Stapling
There are three primary approaches to distributing revocation information. Each comes with different trade-offs in performance, privacy, and operational complexity.
- 01.
CRL
Certificate revocation lists (CRLs) are the original approach to revocation. A CRL is a file published by a CA containing the serial numbers of all certificates it has revoked. Clients download the full list from a certificate distribution point (CDP), parse it, and check whether a specific certificate's serial number appears.
Where CRLs work well
Privacy is where CRLs shine. Because clients download a general list rather than querying about specific certificates, the CA can't track which certificates individual clients are validating.
Where CRLs fall short
CRLs are not scalable. Clients must download the entire list, which creates significant bandwidth consumption for large PKIs. CRL files can grow to 10—20MB or more in enterprise environments, and every client needs the full file before it can validate a single certificate.
- 02.
OCSP
Online Certificate Status Protocol (OCSP) was developed to solve the scalability problem of CRLs. Instead of downloading an entire revocation list, clients send a targeted query to an OCSP responder asking about a specific certificate's status. The responder replies with one of three values: good, revoked, or unknown.
Where OCSP works well
OCSP supports bandwidth efficiency. Queries and responses are small (a few hundred bytes), making OCSP more practical for mobile devices and IoT endpoints.
Where OCSP falls short
OCSP lacks privacy. Every OCSP query reveals to the responder exactly which certificate a client is checking. This allows the CA to build detailed logs of which clients connect to which services and when. Let's Encrypt cited this privacy risk as the primary reason for ending its OCSP support.
OCSP Stapling
OCSP Stapling resolves the core limitations of both CRLs and standard OCSP. Instead of the client checking revocation status, the server does it. The server periodically queries the OCSP responder for its own certificate's status, caches the signed response, and staples this proof of validity directly onto the TLS handshake.
- 03.
Which certificate revocation approach is preferred?
OCSP Stapling is the preferred approach. This is due to three key reasons:
Low latency : The status proof arrives bundled with the certificate during the TLS handshake. There's no separate round trip required.
Strong privacy : Clients never contact the CA or OCSP responder directly, so there's no risk of leaked browsing activity.
Reduced load : The server fetches one OCSP response and reuses it for all client connections until it expires.
There's still a catch. While OCSP Stapling is the recommended mechanism, browser support for enforcing it (via OCSP Must-Staple) is limited.
CRL vs. OCSP vs. OCSP Stapling comparison
| Feature | CRL | OCSP | OCSP Stapling |
|---|---|---|---|
| Latency | High (full file download) | Moderate (network round trip) | Low (bundled in TLS handshake) |
| Privacy | Strong (no per-query tracking) | Weak (CA sees every query) | Strong (no client-to-CA contact) |
| Bandwidth | High (entire list per client) | Low (small per-query) | Very low (server caches response) |
| Current industry direction | Mandatory (CA/B Forum) | Declining (now optional) | Recommended best practice |
The revocation checking dilemma (hard-fail vs. soft-fail)
When a client system can't obtain a certificate's revocation status, whether due to network errors, responder downtime, or malicious interference, it faces a critical decision: proceed with the connection (i.e., soft-fail) or terminate it (i.e., hard-fail)
Most browsers default to soft-fail. If revocation information is unavailable, they assume the certificate is valid and proceed. This prioritizes availability, but it creates a vulnerability that sophisticated attackers can exploit. For example, an attacker with a stolen certificate can present it to a victim while simultaneously blocking network access to the OCSP responder. The browser, unable to check status, proceeds with the connection, rendering the entire revocation infrastructure useless.
Hard-fail takes the opposite approach. If revocation status can't be verified, the connection is refused. This action is more secure, but introduces a DoS risk. An attacker can cause widespread outages by targeting the OCSP responder itself.
OCSP Stapling breaks this deadlock. Because the server proactively fetches and caches status responses, hard-fail becomes viable without the DoS risk. If the server has a current stapled response, clients can enforce hard-fail safely. If it doesn't, that indicates a problem with the server itself, making connection refusal the appropriate response.
What happens when revocation is poorly managed?
The consequences usually show up in the form of security breaches and operational outages. Poorly managed revocation allows MitM attacks and identity spoofing to persist undetected. Attackers frequently target service account certificates because they have elevated permissions, remain valid for extended periods, and bypass standard controls like password resets and MFA. Once an attacker exports a certificate and private key, they can maintain access for weeks and go under the radar.
On the operations side, poor revocation management causes critical downtime. In Windows environments, oversized CRLs exceeding 20MB commonly cause domain controllers to hit the default 15-second network retrieval timeout, resulting in authentication failures that are extremely difficult to diagnose.
Why certificate revocation is now being rethought
The certificate revocation landscape is evolving rapidly, and the change is driven by two major industry developments.
- 01.
Let's Encrypt ends OCSP
In one of the most significant PKI infrastructure changes in recent years, Let's Encrypt fully decommissioned its OCSP service in August 2025. The world's largest CA, with over 387 million valid certificates, now publishes revocation information exclusively via CRLs.
The rationale was that OCSP posed a privacy risk since CAs can track browsing behavior, provided minimal real security benefit due to soft-fail defaults, and cost significant resources to maintain at scale. This decision followed the CA/Browser Forum's Ballot SC-063 to make OCSP optional, signaling an industry-wide retreat from real-time revocation checking.
- 02.
CA/Browser Forum approves 47-day certificates
In April 2025, the CA/Browser Forum passed Ballot SC-081v3, a proposal originally put forward by Apple Inc., to reduce maximum TLS certificate lifetimes from 398 days to 47 days through a phased rollout:
- March 2026: Maximum validity drops to 200 days
- March 2027: Maximum validity drops to 100 days
- March 2029: Maximum validity drops to 47 days, with domain validation reuse limited to just 10 days
The logic is that shorter certificate lifetimes reduce the damage window from a compromised key. If a certificate only lives for 47 days, it expires naturally before most attacks can achieve their objectives, particularly those requiring extended persistence like data exfiltration and lateral movement.
Preparing for what's ahead
The PKI landscape is evolving fast. OCSP is fading, certificate lifetimes are shrinking to 47 days, and the CA/Browser Forum is tightening validation requirements. Organizations that continue to rely on manual certificate management processes will face an accelerating cycle of outages, security incidents, and compliance failures.
The organizations that thrive will be the ones that treat certificate life cycle management as critical infrastructure, with centralized visibility, policy-driven automation, and the ability to respond to security incidents in minutes rather than days.