What Is OCSP? How Certificate Revocation Works

A technical guide to the Online Certificate Status Protocol (OCSP) — how it works, how it compares to CRL and OCSP stapling, what changed when Let’s Encrypt shut down OCSP in August 2025, and what enterprise IT teams running EAP-TLS deployments need to know.

Certificate revocation is one of the more overlooked parts of Public Key Infrastructure (PKI) until something goes wrong. When a certificate is compromised, expired early, or issued incorrectly, relying parties need a way to find out — before they accept the certificate as valid. For most of the past two decades, OCSP was the standard answer to that problem.

That answer is changing. The 2025 deprecation of OCSP by Let’s Encrypt — the world’s largest certificate authority — marks a concrete inflection point. This article:

• Explains what OCSP is and how it works
• Covers the full revocation landscape in 2026
• Addresses the specific considerations for enterprise teams running certificate-based network authentication

What Is OCSP?

Online Certificate Status Protocol (OCSP) is a protocol defined in RFC 6960 that allows a Transport Layer Security (TLS) client to check the revocation status of a specific X.509 certificate in real time. Rather than downloading and parsing a full certificate revocation list, the client sends a single request for one certificate and gets a signed response back.

OCSP was developed as a more efficient alternative to CRLs. The original CRL model required clients to download a list of all revoked certificates from a Certificate Authority (CA) — a list that grew continuously and could reach megabytes in size for large CAs. OCSP addressed this by making status checks per certificate and on demand.

The protocol was first defined in RFC 2560 in 1999 and updated to RFC 6960 in 2013. An OCSP response contains three possible statuses:

• Good (the certificate is valid and has not been revoked)
• Revoked (the certificate has been revoked, with a reason code and timestamp)
• Unknown (the responder cannot determine status for this certificate)

How Does OCSP Work?

When a client receives a certificate during a TLS handshake, it may check revocation status before accepting the certificate. The OCSP process follows these steps:

1. Client extracts the OCSP responder URL from the Authority Information Access (AIA) extension embedded in the certificate. This URL points to the CA-operated responder.
2. Client constructs an OCSP request containing the certificate’s serial number, the issuer’s name hash, and the issuer’s public key hash. The request can be sent via HTTP GET (for short requests) or HTTP POST (for longer ones).
3. The OCSP responder receives the request and looks up the certificate’s status in its database, which is updated by the CA when a certificate is revoked.
4. Responder returns a signed OCSP response containing the status (good, revoked, or unknown), a validity period (the response is valid until a specified time), and the responder’s signature.
5. Client validates the response signature against the CA’s public key and checks the validity period. If the response is current and the status is “good,” the handshake proceeds.

OCSP Request Format: GET vs. POST and Nonce Usage

Short OCSP requests are typically sent via HTTP GET, which allows responses to be cached by CDNs and proxies. Longer requests use HTTP POST. An optional nonce field (a unique, random number that alters the encryption) in the request can prevent replay attacks. The responder includes the same nonce in the response, proving the response was generated for this specific request. In practice, many CAs do not support nonces because they prevent response caching.

Soft-Fail vs. Hard-Fail Behavior

When an OCSP responder is unreachable — due to network issues, server downtime, or a timeout — the client must decide what to do. Soft-fail behavior treats an unreachable responder as non-blocking: the handshake proceeds as if the certificate were valid. Hard-fail behavior treats an unreachable responder as a revocation failure: the connection is rejected.

Most browsers and TLS clients implement soft-fail by default. This is a deliberate usability trade-off. A downed CA responder should not take down every website or application that uses its certificates. However, what it means in practice is that OCSP does not reliably block revoked certificates when the responder is unavailable.

Soft-fail transforms OCSP from a hard security control into a best-effort check. Whether that trade-off is acceptable depends on the threat model and the certificate’s use case.

What Is OCSP Stapling?

OCSP stapling shifts the revocation check from the client to the server. Instead of the client querying the CA’s OCSP responder during the TLS handshake, the server pre-fetches its own OCSP response, caches it, and sends (“staples”) it to the client as part of the TLS Certificate Status extension.

This solves several problems with classic OCSP:

• Privacy: In classic OCSP, the CA’s responder sees every client IP address that connects to a given server — the CA learns which users are visiting which sites. With stapling, only the server queries the responder, and the CA never sees client addresses.
• Latency: Classic OCSP adds an extra round-trip to every TLS handshake. Stapling pre-caches the response, so clients receive it without an additional network call.
• Availability: If the CA’s OCSP responder is temporarily unreachable, the server can continue serving the cached response until it expires (typically in 24–48 hours).

OCSP Stapling and the TLS Handshake

The server includes the stapled OCSP response in the Certificate Status message during the TLS 1.3 handshake (or in a Certificate Status Request extension in TLS 1.2). The client validates the stapled response — checking the CA’s signature and the validity period — and does not need to contact the responder directly.

However, it has one important limitation: OCSP stapling is only defined for TLS server certificates. It is not supported for client certificates. This has direct implications for enterprise environments where clients authenticate with certificates — in EAP-TLS and 802.1X deployments, the client certificate cannot be stapled, and the RADIUS server must check revocation through another mechanism.

What Is OCSP Must-Staple?

OCSP Must-Staple is an X.509 certificate extension defined in RFC 7633. When present in a certificate, it instructs clients that a valid stapled OCSP response is required to accept the certificate. If the server fails to include a stapled response, the client rejects the connection.

Must-Staple was designed to close the soft-fail loophole: An attacker who intercepts an OCSP response (or takes down the responder) cannot force a soft-fail that accepts a revoked certificate — because the certificate itself says a stapled response is mandatory.

In practice, Must-Staple adoption has been limited. Most public CAs do not issue Must-Staple certificates by default, and misconfiguring a server with a Must-Staple certificate (for example, forgetting to configure stapling) immediately breaks connectivity. For enterprise internal PKI, Must-Staple is worth considering only if you control both the issuing CA and the server configuration end-to-end.

OCSP vs. CRL vs OCSP Stapling vs. Short-Lived Certificates

The table below explains the attribute differences between OCSP, CRL, OCSP Stapling and short-lived certificates.

Feature	OCSP	CRL	OCSP Stapling	Short-Lived Certs
Revocation Method	Real-time query to CA responder	Client downloads revocation list	Server pre-fetches; client reads “staple”	No revocation check needed
Real-time Status	Yes	Delayed (CRL update interval)	Near-real-time (cached 24–48 hrs)	N/A — expires before action needed
Client Privacy	Low — CA sees client IP	High — no per-request exposure	High — only server contacts CA	High
Latency Impact	Adds round-trip per handshake	Adds download on cache miss	None at handshake time	None
Client Cert Support	Yes (with limitations)	Yes	No	Yes
Infrastructure Burden	CA must operate responder	CA must publish CRL endpoints	Server must implement stapling	CA must support short lifetimes
Status in 2026	Being deprecated by public CAs	Mandatory (Ballot SC-63)	Supported but not universal	Emerging best practice

For enterprise EAP-TLS deployments, OCSP stapling is off the table for client certificates — CRL or short-lived certificates are the practical options.

Why Is OCSP Being Phased Out?

Three problems have primarily driven the industry away from OCSP:

1. Privacy: Every OCSP check exposes the client’s IP address to the CA’s responder. The CA learns which clients are connecting to which services, at what times. For a large public CA like Let’s Encrypt — which issues certificates for hundreds of millions of domains — this creates a significant surveillance surface. Let’s Encrypt cited this privacy concern as the primary reason for deprecating OCSP.
2. Performance and availability: OCSP responders must be available 24/7 at high availability. Downtime or slow responses directly affect TLS handshake latency. Under soft-fail, outages go unnoticed. Under hard-fail, outages break connectivity. Neither outcome is good.
3. Cost at scale: Operating OCSP responder infrastructure that can handle queries for hundreds of millions of certificates requires significant investment. CRLs, distributed via CDN, are cheaper to operate at scale.

The policy changes reflect these problems. The CA/Browser Forum passed Ballot SC-63 in August 2023, making OCSP optional and CRL mandatory for publicly trusted certificate authorities. Let’s Encrypt followed by announcing deprecation in July 2024 and shutting down its OCSP service on August 6, 2025.

For enterprise internal PKI — where the CA and all relying parties are under the organization’s control — these policy changes do not directly apply. But the underlying technical arguments do. If your internal OCSP responder goes down, and your EAP-TLS policy is set to soft-fail, you may not notice until a security review or audit.

OCSP in Enterprise Networks: EAP-TLS, 802.1X, and RADIUS

The public web deprecation of OCSP gets most of the coverage, but enterprise IT teams running certificate-based network authentication face distinct considerations.

In an EAP-TLS deployment, clients authenticate to the network using X.509 certificates. The RADIUS server validates those client certificates during the 802.1X handshake. That validation can include an OCSP check — the RADIUS server queries the CA’s OCSP responder to confirm the client certificate has not been revoked before granting access.

Several issues arise in this scenario:

1. OCSP stapling does not apply: Client certificates used in EAP-TLS cannot be stapled. The server — in this case, the RADIUS server — must check revocation directly, which means querying the OCSP responder or downloading the CRL on every authentication or at a configured interval.
2. Soft-fail is a security gap: If the OCSP responder is unreachable when a device attempts to authenticate, most RADIUS implementations will fall back to soft-fail and allow the connection. A device with a revoked certificate — one that has been lost, stolen, or belongs to a terminated employee — may still connect to the network if the OCSP responder is temporarily down.
3. OCSP adds authentication latency: Each 802.1X authentication involves a real-time OCSP query if OCSP is configured. On high-traffic networks with many devices authenticating simultaneously, this adds measurable latency and creates a dependency on the OCSP responder’s availability and response time.

For enterprise Wi-Fi and wired 802.1X environments, the OCSP errors in enterprise PKI problem is familiar — responder downtime causes authentication failures that are difficult to diagnose when pressured for time. CRL-based revocation avoids this real-time dependency: The RADIUS server checks against a locally cached CRL, which is updated on a defined schedule. If the CRL distribution point is temporarily unreachable, the cached CRL remains valid until it expires.

For 802.1X environments, CRL-based revocation trades real-time status for operational reliability — a trade-off that makes sense when the alternative is an authentication outage during a responder failure.

What Is Replacing OCSP?

The industry is not abandoning revocation — it is moving to approaches that are more reliable and less privacy-invasive:

• Certificate Revocation Lists (CRLs): CRLs are now mandatory for publicly trusted CAs under CA/B Forum Ballot SC-63. CRLs are published at intervals defined in the certificate’s CRL Distribution Points (CDP) extension. The Base + Delta CRL methodology keeps download sizes manageable: The base CRL contains all revoked certificates, the delta CRL contains only changes since the last base CRL. For enterprise internal PKI, CRLs are well-suited to 802.1X environments and do not require always-on responder infrastructure.
• Short-lived certificates: If a certificate expires in hours or a day, a compromised certificate provides a minimal attack opportunity before it becomes invalid on its own. The certificate revocation list problem shrinks significantly when most certificates never need to be revoked because they expire before they can be exploited. This approach requires infrastructure that can issue and renew certificates automatically — a solved problem with modern managed PKI.
• CRLite (Firefox) and CRLSets (Google Chrome): These are browser-level implementations that aggregate CRL data into compact data structures (bloom filters for CRLite; a curated subset for CRLSets). They apply only to TLS server certificates accessed through the browser — not to enterprise client certificate authentication.

For enterprise PKI, the practical path forward is CRL-based revocation combined with automated certificate lifecycle management. The CA/B Forum’s mandate validates this direction for public certificates; the same logic applies to internal PKI.

How to Manage Certificate Revocation Without the OCSP Overhead?

OCSP errors, responder downtime, and the shift away from public OCSP services put pressure on PKI teams to rethink their revocation architecture. For teams running 802.1X certificate authentication, the gap between what OCSP promises and what soft-fail delivers is a real security consideration — not a theoretical one.

SecureW2 managed PKI configures CRL distribution points automatically. There is no OCSP responder infrastructure to build, maintain, or monitor. JoinNow Cloud RADIUS with the Dynamic Policy Engine checks certificate validity against the identity provider on every authentication — so a deprovisioned user or a device that falls out of compliance is blocked at the network edge, independent of whether an OCSP responder is available.

For teams evaluating a move to short-lived certificates, SecureW2 supports reduced certificate lifetimes with automated renewal via Google Workspace, Jamf, Kandji and Microsoft Intune integrations — the same infrastructure that handles initial device onboarding.

Schedule a demo to see how SecureW2 handles certificate revocation for 802.1X and EAP-TLS deployments, or contact SecureW2 to discuss your PKI architecture.

---

Frequently Asked Questions

What does OCSP stand for?

OCSP stands for Online Certificate Status Protocol. It is defined in RFC 6960 and provides a way for TLS clients to check whether a specific X.509 certificate has been revoked, without downloading the full certificate revocation list (CRL).

What is the difference between OCSP and CRL?

A CRL is a list of all revoked certificates published by a CA; clients download the list and check locally. OCSP is a query protocol — the client sends a request for one certificate's status and receives a real-time response. OCSP adds latency but avoids large list downloads. CRLs can be cached and do not require a live connection to the CA at authentication time.

What is OCSP stapling and why does it matter?

OCSP stapling lets the web server pre-fetch its own OCSP response and includes it in the TLS handshake. The client gets the revocation status without contacting the CA directly. This removes the client privacy leak and the extra round-trip latency. It is only available for server certificates — not client certificates used in EAP-TLS.

Why did Let's Encrypt stop supporting OCSP?

Let's Encrypt shut down OCSP on 6 August 2025, citing privacy concerns. Every OCSP query exposes the querying client's IP address to the CA's responder, allowing the CA to see which clients are accessing which services. Let's Encrypt replaced OCSP with CRL-based revocation, which does not have the same per-client exposure.

Does OCSP work with EAP-TLS and 802.1X authentication?

OCSP can be configured on RADIUS servers for EAP-TLS client certificate validation, but OCSP stapling does not apply to client certificates. RADIUS implementations typically use soft-fail, meaning a downed OCSP responder will not block authentication. For enterprise 802.1X deployments, CRL-based revocation is generally more reliable.

What happens if an OCSP responder is unreachable?

Under soft-fail (the default in most implementations), the TLS handshake proceeds as if the certificate were valid. Under hard-fail, the handshake fails. Most browsers and RADIUS servers use soft-fail to avoid outages caused by CA infrastructure problems. This means OCSP does not provide a hard guarantee that revoked certificates are blocked when the responder is down.

What should replace OCSP in an enterprise PKI?

For enterprise internal PKI, CRL-based revocation with a Base + Delta CRL configuration is the most operationally reliable replacement. For organizations that can implement it, short-lived certificates — with lifetimes of hours to days and automated renewal — reduce the dependency on revocation infrastructure by making revocation less frequently needed.