What Is OCSP (Online Certificate Status Protocol)?

Before OCSP, the primary method for checking revocation status was downloading a certificate revocation list (CRL), a periodically published file containing every revoked certificate’s serial number. CRLs work, but they require the client to download the entire list, parse it, and check for a match. As PKI deployments grew, so did the size of these lists, creating bandwidth and latency challenges that made real-time validation impractical in many environments.

OCSP solves this problem by flipping the model. Instead of downloading a full list, the client sends a lightweight request for the status of a single certificate. The OCSP responder returns a digitally signed response confirming whether that certificate is good, revoked, or unknown. The result is faster, more efficient revocation checking that scales to modern environments.

For a detailed comparison of the two approaches, including when to use each, read CRL vs OCSP: What You Need to Know.

How OCSP works

An OCSP transaction follows a straightforward request and response pattern. When a client (such as a browser, VPN gateway, or application) encounters a certificate it needs to validate, it locates the OCSP responder URL embedded in the certificate’s Authority Information Access (AIA) extension. The client then constructs a request, sends it to that URL over HTTP, and receives a signed response.

Here is the step-by-step workflow:

1. The client receives a certificate during a TLS handshake or other PKI operation.
2. The client extracts the OCSP responder URL from the certificate’s AIA extension.
3. The client builds an OCSP request containing the certificate’s identifying information.
4. The OCSP responder checks the certificate’s status against its revocation data source.
5. The responder returns a digitally signed response with the certificate’s current status.

The entire exchange typically completes in milliseconds, giving the client near real-time revocation data without the overhead of downloading a full CRL.

The OCSP request and response

An OCSP request identifies the certificate in question using a CertID structure defined in RFC 6960. This structure contains four fields:

• Hash algorithm: The algorithm used to compute the hashes below (typically SHA-1 or SHA-256).
• Issuer name hash: A hash of the issuing CA’s distinguished name.
• Issuer key hash: A hash of the issuing CA’s public key.
• Serial number: The unique serial number of the certificate being checked.

Together, these fields uniquely identify a specific certificate without requiring the client to send the full certificate to the responder.

The OCSP responder evaluates the request and returns a signed response containing one of three status values:

• Good: The certificate is valid and has not been revoked.
• Revoked: The certificate has been revoked, and the response includes the revocation time and (optionally) the reason.
• Unknown: The responder does not have information about the requested certificate.

Each response also includes timestamps: producedAt (when the response was generated), thisUpdate (when the status was last confirmed), and nextUpdate (when the client should check again). These timestamps let clients cache responses and determine freshness.

If the responder cannot process the request, it returns an error status code. Common codes include MALFORMED_REQUEST (the request could not be parsed), INTERNAL_ERROR (the responder encountered a problem), TRY_LATER (the responder is temporarily unavailable), and UNAUTHORIZED (the client is not permitted to query this responder).

What is an OCSP responder?

An OCSP responder is a server that receives certificate status requests and returns a digitally signed response indicating whether a specific certificate is valid, revoked, or has an unknown status. The responder is operated by or on behalf of the CA that issued the certificate.

There are two primary responder models:

• CA-integrated responder: The CA itself signs OCSP responses using its own private key. This is the simplest model, but it means the CA’s signing key must be online and accessible, which introduces security considerations.
• Delegated responder: The CA issues a separate OCSP signing certificate to a dedicated responder. This certificate must include the Digital Signature key usage and OCSPSigner extended key usage. Delegated responders allow the CA’s root or intermediate key to remain offline while still providing real-time status information.

In enterprise PKI environments, a single OCSP responder can answer queries for multiple CAs. Organizations that need high availability typically deploy multiple responder nodes, each with its own copy of the revocation data, behind a load balancer. This architecture ensures that certificate validation continues even if individual nodes experience downtime.

OCSP stapling explained

Standard OCSP requires the browser to contact the CA’s OCSP responder during every TLS handshake. At scale, this introduces latency, creates a dependency on third-party infrastructure, and raises privacy questions. OCSP stapling, defined in RFC 6066, addresses all three concerns by shifting the responsibility for retrieving the OCSP response from the browser to the web server.

How OCSP stapling works

With OCSP stapling, the web server periodically fetches an OCSP response from the CA’s responder and caches it locally. When a browser initiates a TLS handshake, the server includes (or “staples”) that cached OCSP response alongside the certificate in the TLS Certificate Status message. The browser validates the stapled response’s digital signature and checks its freshness timestamps, all without making a separate network request to the CA.

The process works as follows:

1. The web server sends an OCSP request to the CA’s responder, typically on a regular interval (for example, every few hours).
2. The CA’s responder returns a signed OCSP response.
3. The server caches the response.
4. During each TLS handshake, the server delivers the cached response to the connecting client as part of the handshake.
5. The client verifies the response signature and timestamps, then proceeds with the connection.

Because the server handles the OCSP lookup, the browser never needs to contact the CA directly for revocation data during the connection.

Benefits of OCSP stapling

OCSP stapling delivers three key advantages over traditional OCSP:

• Improved performance. 
  The browser receives the certificate’s revocation status as part of the TLS handshake, eliminating the round trip to the CA’s OCSP responder. This reduces connection setup time, particularly for users who are geographically distant from the CA’s infrastructure.
• Improved security. 
  By removing the browser’s need to make a separate OCSP request, stapling reduces the attack surface. It also minimizes the risk of false positives that can occur when OCSP responders are unreachable and clients fall back to a “soft-fail” behavior.
• Enhanced user privacy.
  With traditional OCSP, the CA receives a request for every certificate the user validates, which reveals browsing patterns. With stapling, the CA only receives requests from the web server, not from individual users.

What is OCSP Must-Staple?

OCSP Must-Staple is a certificate extension defined in RFC 7633 that instructs browsers to require a valid stapled OCSP response during the TLS handshake. If the server does not provide a stapled response, the browser must reject the connection rather than proceeding without revocation data.

This extension closes an important gap in the standard OCSP model. Without Must-Staple, most browsers use a “soft-fail” approach: if they cannot reach the OCSP responder (or if the server does not staple a response), they allow the connection anyway. This means a compromised certificate could be accepted if an attacker blocks OCSP traffic between the client and the CA.

Must-Staple enforces a “hard-fail” policy for certificates that include the extension. The tradeoff is that server operators must ensure their OCSP stapling configuration is reliable, because a missing or expired stapled response will cause legitimate connections to fail.

Advantages of OCSP over CRLs

OCSP offers several operational advantages that make it well suited for environments where timely revocation data and resource efficiency matter:

• Real-time status. 
  OCSP checks the status of a certificate at the moment the request is made, rather than relying on a periodically published list. This means revocation information is as current as the responder’s data source allows.
• Smaller response payloads. 
  An OCSP response addresses a single certificate, so it is significantly smaller than a CRL that lists every revoked certificate issued by a CA. This makes OCSP particularly well suited for constrained devices such as smartphones, IoT endpoints, and embedded systems that have limited memory and processing power.
• Reduced bandwidth. 
  Because clients request status for only the certificates they encounter, OCSP eliminates the need to download and parse large CRL files. This is especially valuable in environments with thousands or millions of active certificates.
• Better suited for time-sensitive use cases. 
  In scenarios such as network access control (NAC), where access decisions must be made immediately, real-time OCSP queries provide the responsiveness that CRL caching intervals cannot match.

For a full side-by-side comparison of OCSP and CRLs, including a decision framework for when to use each, see CRL vs OCSP: What You Need to Know.

Limitations and considerations with OCSP

Despite its advantages, OCSP introduces its own set of operational challenges that organizations should understand before relying on it as a primary revocation mechanism.

Privacy concerns

In the standard OCSP model, the client sends the certificate’s serial number to the CA’s OCSP responder for every certificate it validates. This means the CA (or whoever operates the responder) can observe which certificates users are checking, which can reveal browsing activity and other usage patterns. OCSP stapling was developed specifically to mitigate this concern, but not all servers have stapling enabled.

Availability dependency

OCSP introduces a real-time dependency on the responder’s availability. If the OCSP responder goes down, clients must decide what to do. Most browsers and applications use a “soft-fail” approach, meaning they allow the connection to proceed even if they cannot verify the certificate’s revocation status. This behavior effectively makes OCSP optional during outages, which undermines the security value of revocation checking.

The alternative, “hard-fail,” blocks all connections when the OCSP responder is unreachable. While this is more secure, it creates availability risks because a responder outage could take down every service that depends on it for validation.

Performance at scale

Each OCSP check requires a network round trip to the responder. For high-traffic services or clients that validate many certificates in rapid succession, these queries can add measurable latency. While OCSP stapling eliminates the browser-to-CA round trip, the server must still query the responder to refresh its cached responses.

Single point of failure

If an organization runs a single OCSP responder (or a small cluster without geographic redundancy), that responder becomes a critical dependency for every certificate it serves. Responder infrastructure must be designed for high availability, with redundant nodes, load balancing, and monitoring to detect and respond to outages before they affect certificate validation.

How browsers handle OCSP today

The way browsers handle OCSP has evolved significantly, and understanding current browser behavior is important context for any organization managing PKI infrastructure.

Google Chrome does not perform traditional OCSP checks for most publicly trusted certificates. Instead, Google maintains CRLSets, a curated and compressed set of revoked certificate serial numbers that is distributed to Chrome through browser updates. This approach avoids the latency and privacy concerns of live OCSP queries, though CRLSets coverage is limited to high-priority revocations rather than every revoked certificate.

Mozilla Firefox supports OCSP only as a fallback, as their primary strategy shifted towards local certificate validation. The browser has adopted CRLite, a technology that compresses the full set of revocation data derived from CRLs into a compact data structure that can be distributed to browsers. CRLite allows Firefox to perform local revocation checks without contacting an OCSP responder.

Apple Safari performs OCSP checks as part of its certificate validation process. Apple has historically been more reliant on OCSP than Chrome or Firefox, though it also uses local caching and batch checking to reduce the performance and privacy impact of live queries.

The broader industry trend is clear: for the public web, browsers are moving away from live OCSP queries toward locally distributed revocation data. However, OCSP remains the standard validation mechanism in enterprise PKI, private trust hierarchies, and specialized environments where browser behavior does not apply.

Is OCSP being deprecated?

In short, no. However, there is a move to phase OCSP out of the public Web PKI. Major browser vendors have concluded that OCSP is not providing reliable protection because most implementations use a soft-fail model: if the OCSP responder cannot be reached, the browser continues the connection anyway. OCSP also produces latency, raises privacy concerns (because the certificate serial number is revealed to the responder), and adds operational complexity.

As a result, browser ecosystems are moving toward alternative revocation mechanisms. Chrome has long relied on browser-managed revocation data rather than live OCSP queries, while Firefox has adopted CRLite. This shift is further accelerated by the shortening of certificate lifespans, including the move toward 47-day certificates, and the decision of major CAs to discontinue OCSP support.

However, OCSP is not disappearing from PKI as a whole. It remains widely used in enterprise PKIs, government infrastructures, VPN authentication systems, code-signing ecosystems, and other managed environments where clients and responders are under centralized control. In these settings, OCSP continues to provide timely revocation information and supports validation requirements that are not addressed by browser-focused alternatives.

For organizations that operate their own PKI, the practical takeaway is this: OCSP is evolving, not vanishing. Your OCSP infrastructure will still serve a critical role in enterprise and private PKI environments, even as public web browsers rely on different mechanisms.

OCSP monitoring and availability

For organizations that rely on OCSP for certificate validation, monitoring responder availability is not optional. An unresponsive OCSP responder can have cascading effects across your environment, from failed TLS connections to blocked VPN access to stalled application workflows.

The consequences of OCSP responder downtime depend on how your clients are configured. In a soft-fail environment, an outage may go unnoticed because clients silently skip revocation checking. This creates a blind spot where revoked certificates could be accepted. In a hard-fail environment (or when OCSP Must-Staple is in use), a responder outage directly causes connection failures.

Either scenario is problematic. In the first case, you lose the security assurance that revocation checking provides. In the second, you face availability disruptions that can affect your entire infrastructure.

Proactive OCSP monitoring addresses both risks. By continuously checking whether your OCSP endpoints are responsive, you can detect outages before they impact users and trigger automated alerts for your operations team. Certificate lifecycle automation tools provide this capability as part of a broader approach to managing certificate infrastructure, giving your team visibility into OCSP health alongside certificate expiration, issuance, and renewal.

How Keyfactor helps with OCSP

Managing OCSP infrastructure at scale requires more than standing up a responder. It requires visibility, automation, and a PKI platform that treats revocation as a first-class operational concern.

EJBCA, Keyfactor’s PKI platform, includes a built-in Validation Authority (VA) component that supports both OCSP responders and CRL publishing. EJBCA’s OCSP responder supports CA-integrated and delegated signing models, multi-CA deployments, and high-availability architectures with multiple responder nodes.

Keyfactor Command provides continuous OCSP endpoint monitoring and alerting as part of its certificate lifecycle automation platform. Your team can track OCSP responder availability in real time, receive notifications when endpoints become unresponsive, and correlate responder health with the broader state of your certificate environment.

PKI as a Service offers a fully managed PKI that includes OCSP responder infrastructure, so organizations can offload the operational burden of running and monitoring their own revocation infrastructure.