OCSP (Online Certificate Status Protocol), standardised in RFC 6960, is a request-response protocol that allows a verifier to query an OCSP responder — a service operated by the CA or a delegated party — for the current revocation status of a specific X.509 certificate. Where a CRL requires downloading an entire list and searching it locally, an OCSP query asks about exactly one certificate and receives a signed response: good (the certificate is currently valid and not revoked), revoked (revoked, with the revocation time and reason), or unknown (the responder does not know this certificate). The OCSP response is signed by the CA’s OCSP signing key (or a dedicated OCSP responder key with the id-pkix-ocsp-nocheck extension, exempt from its own revocation checking to prevent circularity) and carries a thisUpdate and nextUpdate timestamp defining its freshness window. Verifiers in strict mode reject responses outside the freshness window; in practice, OCSP responses are valid for 24 hours to 7 days depending on the CA’s policy, meaning OCSP shares CRL’s staleness problem, albeit with a smaller window.
The naive OCSP model — the client sends a request to the responder on every TLS connection — has two significant problems. Privacy: the OCSP responder learns exactly which certificate the client is verifying, and therefore which website the client is visiting, at the time of the connection. Since OCSP responders are operated by CAs (a small number of parties), this creates a centralised surveillance point for a significant fraction of HTTPS browsing — every connection to a site whose certificate chains to a major CA is reported to that CA’s OCSP responder in real time. Latency: the OCSP query is an additional network round-trip on the TLS handshake critical path, adding 50–300 ms to connection establishment depending on responder proximity and load, and introducing a failure mode if the responder is slow or unavailable. OCSP stapling (RFC 6066 §8, the status_request TLS extension) solves both problems: the server periodically fetches its own OCSP response from the responder, caches it, and staples it to the TLS handshake — delivering it in the CertificateStatus message alongside the certificate. The client receives a fresh, CA-signed response without making its own network request, the CA’s responder sees only the server’s queries (not individual clients), and the OCSP check adds zero latency to the client’s connection. OCSP Must-Staple (RFC 7633, the status_request X.509 extension in the leaf certificate) takes this further: it instructs compliant TLS implementations to require a valid stapled OCSP response and hard-fail if none is present, preventing an attacker who has compromised a certificate’s private key from blocking OCSP checks to extend the certificate’s effective validity.
OCSP’s practical status in the web PKI is ambiguous. Browsers have largely abandoned client-side OCSP checking for leaf certificates: Chrome disabled OCSP soft-fail checking in 2012 (citing the privacy problem and the fact that soft-fail — accepting the certificate if the OCSP check fails — provides no security against an attacker who can block OCSP requests), relying instead on CRLSets and the short certificate lifetimes mandated by the CA/Browser Forum (currently 398-day maximum validity, with proposals for 90-day and 47-day maximums actively under ballot). Firefox retains OCSP for EV certificates but has moved to CRLite (a compressed, locally cached revocation database built from CRLs) for DV certificates. Despite this retreat in the browser context, OCSP stapling remains important for server operators because non-browser TLS clients — Java applications, Python’s requests, Go’s crypto/tls, curl — typically do perform OCSP checking (or at minimum respect stapled responses), and mTLS client certificate verification in cert-manager-managed and SPIFFE/SPIRE-adjacent deployments relies on OCSP or CRL checking for client certificate revocation. Vault’s PKI engine issues certificates with OCSP responder URLs and supports a built-in OCSP responder, making it the natural revocation infrastructure for short-lived certificates issued to Kubernetes workloads. For very short-lived certificates — the hours-to-days lifetime favoured by SPIRE SVIDs, Vault PKI leases, and cert-manager with aggressive renewal — revocation becomes operationally moot: a compromised certificate expires before a CRL or OCSP response is stale enough to matter, which is why short lifetimes are the preferred revocation mitigation in modern certificate management. In the PQC transition, OCSP response signatures must migrate from ECDSA/RSA to ML-DSA alongside the certificates they cover, and OCSP responder keys should be among the first infrastructure keys migrated given their role in the trust validation chain.