Contents

Online Certificate Status ProtocolEdit

Online Certificate Status Protocol (OCSP) is a component of public key infrastructure that supports real-time verification of the revocation status of X.509 certificates. When a client presents a certificate during a secure connection, OCSP allows the client to query an OCSP responder operated by the certificate issuer to learn whether that certificate has been revoked since issuance. The primary goal is to prevent users from trusting certificates that have been withdrawn due to compromise, misissuance, or other policy violations. OCSP complements older mechanisms such as Certificate Revocation Lists (CRLs) and is widely used in modern TLS deployments to keep trust decisions current without requiring large, constantly updated revocation lists. See Public Key Infrastructure and X.509 for more on the surrounding framework, and Certificate Revocation List for the alternative revocation mechanism.

How OCSP works

  • A certificate includes an OCSP URL in its extensions, pointing to an OCSP responder controlled by the issuer. The client sends a small request that uniquely identifies the certificate by issuer information and serial number to that responder.
  • The responder replies with a signed statement indicating the status of the certificate: good, revoked, or unknown. The response is bound to the issuer’s private key, and the client validates the signature using the issuer’s public key from the trust chain, i.e., the authority that anchors trust in the client’s certificate store (Certificate Authoritys) and their root certificates.
  • The client uses this status, within its TLS or other protocol negotiation decision, to decide whether to continue with the connection. In practice, implementations may treat an unknown status differently than a revoked status, and some configurations allow non-blocking or soft-fail behavior if the responder cannot be reached.
  • OCSP responses include freshness information, such as thisUpdate and nextUpdate times, to help clients assess whether the status is still valid. If the response is stale, clients may retry or fall back to other revocation mechanisms.

OCSP is defined and standardized as part of the broader TLS ecosystem, which also includes X.509 certificates, revocation checks, and the trust anchors that make certificate validation possible. See OCSP for the protocol itself and TLS for the transport layer in which these checks commonly occur.

Variants and enhancements

  • OCSP stapling (also known as TLS stapling) allows the server to fetch an OCSP response from the issuer and present it to the client during the TLS handshake. This reduces client-side network calls to the OCSP responder, improves privacy by limiting which party sees the client’s site visits, lowers latency, and can help ensure timely revocation checks even if the responder is intermittently reachable. This technique relies on a TLS extension commonly referred to as the status extension or status_request, and it is supported by many major servers and clients.
  • The Must-Staple concept is an optional policy that requires a valid stapled OCSP response to be present for a certificate to be accepted. If a server does not provide a stapled response for a must-staple certificate, the connection may fail. Adoption varies by ecosystem and certificate policies, but it illustrates how revocation awareness can be strengthened when supported end-to-end.
  • Non-stapling configurations and alternative approaches (such as relying on CRLs, or using supplementary mechanisms like Certificate Transparency to monitor issuance) reflect a range of deployment preferences. In practice, many deployments combine OCSP with CRLs or rely on stapling to balance performance, privacy, and reliability.
  • Optional request controls within OCSP allow clients to include a nonce to prevent replay or to enforce fresh status information. The presence of such features can influence security properties in environments with aggressive caching or limited connectivity.

Privacy, security, and interoperability considerations

  • Privacy: Plain OCSP queries reveal to the issuer’s network which sites a user visits. OCSP stapling addresses this concern by moving the query away from the client and into the server, reducing the exposure of user browsing patterns to multiple responders.
  • Reliability and availability: If an OCSP responder is unreachable or slow, the client may face delays or must decide to proceed with reasonable trust in the certificate. Different clients implement hard-fail or soft-fail policies to handle these situations, which can affect user experience and security guarantees.
  • Security posture: The trust in OCSP relies on the integrity of the issuer’s private key and the stability of the CA ecosystem. If an issuer’s private key is compromised or a CA is misissued, revocation checks won’t be trustworthy unless revocation data is timely and correctly validated. Browser and platform vendors routinely update trust stores and revocation behavior to reflect evolving realities.
  • Alternatives and complements: Some operators consider DNSSEC/DANE-based approaches, DNS-based revocation, or certificate transparency as parts of a layered strategy to detect and respond to misissued or compromised certificates. These approaches interact with OCSP in different ways and can impact deployment choices.

Implementation and interoperability

  • Widespread support exists among major browsers, servers, and platform certificate stores, though behavior can vary. The implementation details—such as whether to require revocation checks, how to handle unknown statuses, and how to respond to failed OCSP queries—are influenced by policy decisions in the client, the server, and the issuer.
  • Interoperability challenges can arise when the OCSP responder uses nonstandard configurations, when networks block certain types of traffic, or when responders are slow to update revocation data. In practice, stapling helps mitigate some of these issues by centralizing the revocation query process on the server side.
  • The relationship to the broader PKI ecosystem matters: OCSP interacts with certificate issuance practices, root and intermediate CA hierarchies, and the policies that govern certificate revocation and renewal. See Public Key Infrastructure and Certificate Authority for broader context.

See also