Online Certificate Status Protocol

Online Certificate Status Protocol (OCSP) is an IETF protocol for checking the revocation status of an X.509 certificate via an OCSP responder, instead of downloading a full Certificate Revocation List. In the Web PKI, OCSP is intended to help relying parties detect certificates revoked due to compromise or mis-issuance, but its real-world effect depends on client enforcement and responder reachability.

Overview

OCSP is specified in RFC 6960. A client can query an OCSP responder for the status of a specific certificate and receive a signed response indicating good, revoked, or unknown, along with validity metadata (e.g., “thisUpdate/nextUpdate”). In common TLS deployments, responder URLs are advertised via the certificate’s Authority Information Access (AIA) extension.

Deployment and practical limits

Two patterns dominate in practice:

• Client-side OCSP querying: the client contacts the responder directly (often during connection setup) and caches the response within the responder’s stated validity window.
• OCSP stapling: the TLS server includes (“staples”) a recent OCSP response in the handshake, reducing latency and avoiding the privacy leak of direct client→responder queries. A related TLS mechanism generalizes certificate status delivery for some deployments.

Operationally, OCSP’s main trade-offs are often resolved through ecosystem policy choices rather than protocol mechanics. Because revocation checking depends on reaching an external responder, outages or deliberate blocking can prevent validation; to avoid turning responder failures into widespread service outages, many clients treat OCSP as “soft-fail” and continue when status cannot be obtained. Live OCSP also creates a privacy leak, since a client query can expose which site a user is visiting to the responder operator or on-path observers. At scale, it can add latency (extra network round-trips) and create substantial responder load, while stapling mainly shifts that burden from the CA to certificate holders without eliminating the need for reliable responder issuance.

These constraints have contributed to a broader shift away from per-connection online checks toward alternative distribution approaches; for example, Let’s Encrypt ended its OCSP service and moved to CRL-based publication (also removing OCSP URLs from new certificates), while Mozilla has been rolling out CRLite-based revocation checking in Firefox as an alternative model.

Internet governance implications

OCSP is a useful lens for how “Internet governance” is often executed in practice in the security layer: not through governments or intergovernmental bodies, but through a multi-actor control plane spanning standards, browsers, and industry rulemaking.

First, OCSP sits at the intersection of IETF standardization and private-sector compliance regimes. While OCSP is standardized by the IETF, its operational requirements for the public Web PKI are heavily shaped by browser root programs and CA compliance frameworks such as the CA/Browser Forum Baseline Requirements, which specify expectations around certificate lifecycle and revocation publication/availability (including OCSP-related requirements).

Second, OCSP demonstrates how policy decisions by browser vendors can effectively redefine “the standard” for end users. Chromium-based browsers have historically relied on mechanisms such as CRLSets rather than comprehensive live OCSP checking, reflecting a deliberate trade-off among latency, reliability, privacy, and deployability. Mozilla’s movement toward CRLite is another example of governance-by-implementation: a browser vendor changes revocation enforcement semantics at Internet scale, influencing CA operations and the practical meaning of “revocation” for the ecosystem.

Third, OCSP creates centralization and chokepoint dynamics. OCSP responders are often operated by CAs (or their infrastructure partners), so the ability to obtain revocation information depends on a small set of globally reachable endpoints. This has implications for censorship environments, enterprise filtering, and national network controls: blocking or degrading OCSP traffic can change the security properties clients actually realize (hard-fail creates outages; soft-fail weakens revocation).

Finally, OCSP’s decline in some major deployments illustrates a broader governance pattern in the Web PKI: when online, per-connection checks are operationally fragile or privacy-hostile, the ecosystem migrates toward curated, aggregated, or pre-distributed revocation signals (CRLs via CDNs, browser-updated revocation sets, or compressed proofs such as CRLite). These shifts change accountability and power distribution among CAs, browsers, and relying parties, and they affect how quickly and reliably mis-issued or compromised certificates can be neutralized in practice.

See Also

• X.509
• CA/Browser Forum
• CRLite

Internet Engineering Task Force

Allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery (RFC 8446).

X.509 Public Key Infrastructure for the Internet (RFC 5280).