OCSP is the online query protocol that lets a relying party ask a certificate authority, in real time, whether a single certificate is still valid. This guide explains how OCSP works, how it compares with CRLs, what stapling and Must-Staple change, and how to operate an OCSP responder at the scale demanded by 47-day TLS lifetimes.
The Online Certificate Status Protocol (OCSP), defined in RFC 6960, is the per-certificate alternative to CRLs. Instead of downloading a full list of every certificate a CA has ever revoked, the relying party sends one small request — "is this serial number still good?" — and the CA's OCSP responder returns a signed answer. The response is typically around one kilobyte, which is two to three orders of magnitude smaller than a busy CA's CRL.
OCSP was standardised in 1999 and refined in RFC 6960 in 2013, with a profile for high-volume HTTP serving in RFC 5019 (Lightweight OCSP). Today, almost every public TLS certificate carries an OCSP responder URL in its Authority Information Access (AIA) extension, and almost every TLS server in a serious deployment serves a stapled response so the client never has to call the CA directly.
OCSP matters more in 2026 than it did five years ago, not less. The CA/Browser Forum has set a path toward 47-day TLS certificates, mutual TLS is now the default inside service meshes and Zero Trust networks, and revocation still has to work in the brief window where a private key has leaked but the certificate has not yet expired. This guide walks through the protocol, the operational pitfalls, and where OCSP fits alongside CRLs, stapling, and Must-Staple.
When a browser, a mutual-TLS client, or a code-signing verifier wants to know whether a certificate has been revoked before it expires, it has two choices. It can fetch the issuing CA's CRL — sometimes a multi-megabyte file containing every revoked certificate in that hierarchy — and grep through it for one serial number. Or it can ask a much smaller question, addressed to a single endpoint, about a single certificate. OCSP is the protocol for that second question.
The protocol is not new. The original OCSP RFC dates from 1999, the current revision (RFC 6960) from 2013, and the high-volume HTTP profile (RFC 5019) from 2007. What has changed is the operational context: TLS lifetimes are shrinking toward 47 days, mTLS is becoming the default inside the perimeter, and any revocation pathway that depends on a fresh online lookup against the CA has to scale to billions of requests a day. OCSP is still load-bearing, but only if it is operated correctly.
A single OCSP exchange is four steps. The first three are mechanical; the fourth is where most production problems live.
The structure looks simple. What makes it interesting is the cache: every relying party along the chain (the browser, the OS validation cache, an intermediate proxy, the CDN in front of the responder) can hold a signed response, and as long as `thisUpdate` and `nextUpdate` still bracket the present, that cached copy is as good as a fresh one. OCSP is therefore not "real time" in the colloquial sense — it is "as fresh as the responder publishes", which is usually somewhere between an hour and a few days.
The relying party extracts the issuer name, the issuer public key, and the certificate serial number from the certificate it is validating. It hashes the issuer name and the issuer public key (SHA-1 by default in RFC 6960, with SHA-256 widely supported), wraps them with the serial number into a `CertID` structure, and packs that into an ASN.1 DER-encoded `OCSPRequest`. The request is typically a few dozen bytes. The responder URL itself is read from the certificate's Authority Information Access extension, specifically the `id-ad-ocsp` access method.
The request travels over HTTP (not HTTPS — the response is signed, so transport encryption would add latency without adding security). RFC 5019 mandates GET for short requests, with the DER bytes base64-then-URL-encoded into the path; longer requests fall back to POST. The responder URL is plain HTTP precisely so that aggressive HTTP caches and CDNs in front of the CA can serve cached responses without terminating TLS.
The responder looks up the serial number in its revocation database and produces an `OCSPResponse` containing a status (`good`, `revoked`, or `unknown`), a `thisUpdate` timestamp (when this answer was true), a `nextUpdate` timestamp (when a new answer will be available), and, if revoked, a revocation time and optional reason code. The whole structure is signed either directly by the issuing CA or, more commonly, by a delegated OCSP signing certificate that carries the `id-kp-OCSPSigning` extended key usage. Responses are typically around 1 KB.
The client verifies the signature against the issuer (or the delegated signer's chain), checks that `thisUpdate` is recent and `nextUpdate` has not passed, confirms the `CertID` in the response matches the one in the request, and reads the status. The response is then cached locally — by serial number, until `nextUpdate` — so that the same query within the same window does not generate a new network round trip.
RFC 6960 defines three status values, and the gap between what they look like they mean and what they actually assert is the source of more than one production incident.
The responder has no record that this certificate is revoked. Crucially, RFC 6960 §2.2 is careful to say "good" does not affirmatively assert that the certificate was ever issued, only that it is not currently on the revocation list. A responder configured to "answer good for any serial it has not heard of" will happily bless certificates that were never minted at all. Production responders should be configured to assert positive issuance, often by switching unknown serials to `unknown` rather than `good`.
The certificate has been revoked. The response carries a `revocationTime` and, optionally, a `revocationReason` matching the CRL reason codes from RFC 5280 (`keyCompromise`, `cACompromise`, `affiliationChanged`, `superseded`, `cessationOfOperation`, `certificateHold`, `privilegeWithdrawn`, `aACompromise`). For permanent revocation reasons such as `keyCompromise`, the status will never change back; for the transient `certificateHold`, a later `good` is permitted.
The responder has no information about this certificate. This is not an error and not a soft pass — it is an explicit "I cannot answer". Properly configured clients should treat `unknown` as a hard failure for a certificate that claims to be issued by a CA whose responder ought to know about it. In practice, many clients soft-fail instead, which is the problem the warning below is about.
CRLs and OCSP solve the same problem with opposite trade-offs. The pairing is so common that most modern PKIs operate both, with the responder backed by the same revocation database that produces the CRL.
The two mechanisms also fail differently. A stale CRL fails closed (the client knows it is stale, refuses), whereas a missing OCSP response fails open in most browsers and TLS stacks (soft-fail). That asymmetry is what makes the OCSP stapling discussion below load-bearing rather than cosmetic.
| <a href="/guide/crl" class="text-[#5081BD] hover:text-[#001363] no-underline font-medium">CRL</a> | OCSP | |
|---|---|---|
| Mechanism | Download the full list of revoked serials | Per-certificate signed query |
| Freshness | Periodic publication (hours to days) | As fresh as `nextUpdate`, typically hours; minutes possible |
| Bandwidth | Whole list each refresh, can be megabytes | About 1 KB per response, cacheable by CDNs |
| Privacy | Client downloads the list; CA learns nothing about which cert is being checked | Direct OCSP leaks "I am about to talk to site X" to the CA; stapling fixes this |
| Offline | Works with a cached CRL inside the validity window | Requires network reachability unless the response is stapled |
| Standard | RFC 5280 | RFC 6960, RFC 5019 (Lightweight profile) |
Before querying anything, you need the responder URL. It lives in the Authority Information Access extension of the certificate itself.
With the responder URL in hand, you can issue a direct OCSP query. This is the lowest-level form of the protocol and the one you reach for when debugging a responder or testing a new one.
For a live TLS server, the more useful test is whether the server staples a response into the handshake at all. That can be done in one call:
The `-status` flag of `s_client` is the single most useful command for diagnosing OCSP problems in production. If it returns `no response sent`, the server is not stapling, and every client connecting to it is either doing a direct OCSP fetch (slow, privacy-leaking) or soft-failing (insecure).
# Extract the OCSP responder URL from a certificate's AIA extension
openssl x509 -in cert.pem -noout -ocsp_uri
# Or the full AIA, including any CA Issuers URLs used to fetch intermediates
openssl x509 -in cert.pem -noout -text | grep -A 4 "Authority Information Access"
# Sample output:
# Authority Information Access:
# OCSP - URI:http://ocsp.example-ca.com
# CA Issuers - URI:http://crt.example-ca.com/intermediate.crt# Fetch the issuing CA's certificate, then ask the responder about cert.pem
openssl x509 -in cert.pem -noout -issuer_hash
curl -o issuer.pem http://crt.example-ca.com/intermediate.crt
# Send a manual OCSP request via OpenSSL
openssl ocsp \
-issuer issuer.pem \
-cert cert.pem \
-url "$(openssl x509 -in cert.pem -noout -ocsp_uri)" \
-resp_text \
-no_nonce
# A healthy response will print:
# Response verify OK
# cert.pem: good
# This Update: ...
# Next Update: ...# Check whether the server staples an OCSP response in the TLS handshake
echo | openssl s_client -connect example.com:443 -servername example.com -status 2>/dev/null \
| grep -E "OCSP response|Cert Status|This Update|Next Update"
# A server that staples correctly returns something like:
# OCSP Response Status: successful (0x0)
# Cert Status: good
# This Update: <recent timestamp>
# Next Update: <future timestamp, typically hours to days ahead>
# A server that does NOT staple returns:
# OCSP response: no response sentRunning an OCSP responder is not the same as running a CRL publisher. It is a high-availability, low-latency online service whose unreachability has been weaponised in the past. Four constraints dominate the design.
A CA is only as trusted as its revocation infrastructure. If the OCSP responder is down for an hour, every relying party that does not have a fresh cached response either soft-fails (insecure) or hard-fails (outage). Production responders run behind a CDN, are replicated across regions, and are monitored against external probes — not just internal health checks. Treat the responder as a tier-zero service, with the same uptime expectations as the CA itself. A 99.95% SLA on the CA combined with a 99.5% SLA on the responder is not a 99.5% PKI; it is a PKI whose effective revocation is broken for forty hours a year.
When a browser fetches an OCSP response directly, the CA's responder sees the certificate's serial number and the requesting IP. From the serial it can infer the site being visited; from the IP it can correlate that to a user. This is not theoretical — every direct OCSP exchange is a telemetry event sent to the CA. The two correct mitigations are stapling on the server side (so clients never talk to the CA) and aggressive responder caching via shared CDNs (so the CA cannot easily map serials back to users). Privacy is the reason browsers like Firefox have been quietly de-emphasising direct OCSP for over a decade.
RFC 6960 supports a `Nonce` extension that prevents a responder from replaying an old "good" response — useful in theory, but it defeats caching, because every request now produces a unique response. The Lightweight profile (RFC 5019) drops nonces in favour of large-scale HTTP caching, which is why production deployments serve nonce-free responses with `thisUpdate` and `nextUpdate` windows of several hours. The trade-off: a compromised certificate can remain "good" in cached responses until `nextUpdate` expires. Pick the window deliberately. Twelve hours is common; one hour is aggressive; seven days (the upper limit some CAs use) is irresponsible for high-value certificates.
As TLS lifetimes shrink toward 47 days, the number of distinct certificates a CA issues per year grows by a factor of roughly eight, and the OCSP query volume grows with it. A responder that comfortably served one-year certificates may not survive the same fleet under 47-day rotation. Pre-sign responses where possible (RFC 5019 explicitly supports this), serve them through a CDN with HTTP caching, and measure response times at p99, not on average. A responder whose p99 is two seconds will break TLS handshakes long before the average looks bad.
OCSP is not a legacy mechanism waiting to be replaced. It is the operational backbone of TLS revocation, even in environments where CRLs are still published — typically as a fallback, an audit trail, and the input from which OCSP responses are generated. The picture most enterprises end up with looks like this:
- Public TLS uses OCSP stapling on every public-facing server, with the CRL kept as a fallback for clients that do not negotiate stapling. The responder is hosted by the public CA; the enterprise operates the stapling configuration on its own load balancers. - Internal mTLS uses a private CA with a private OCSP responder, often co-located with the issuing CA on the same network. Stapling is configured wherever the proxy or sidecar supports it; where it does not, the responder is operated as a tier-zero service inside the perimeter. - Long-lived certificates (code signing, document signing, S/MIME) almost always carry both an OCSP URL and a CRL distribution point, because verifiers may be offline, may run on platforms whose certificate stores update slowly, or may need to assert validity years after the fact.
The interesting design question is no longer "OCSP or CRL?" but "where does each response live, how stale can each cache get, and what happens when the responder is unreachable?". Answering those questions consistently across thousands of services is what a CLM platform exists to do.
Built-in OCSP responder backed by the issuing CA — Evertrust PKI ships with a native OCSP responder driven by the same revocation database that produces the CRLs. Responses are signed either directly by the CA or by a delegated `id-kp-OCSPSigning` certificate, with configurable `thisUpdate`/`nextUpdate` windows so you can dial the freshness/cache trade-off to your environment. The responder is built on the same non-blocking, asynchronous architecture as the rest of the PKI, designed to absorb the query volume that shorter certificate lifetimes will bring.
Stapling-ready responses and high-availability serving — Evertrust PKI supports pre-signed OCSP responses where the issuance policy allows, so they can be served from any HTTP cache or CDN. That matters when one server staples on behalf of millions of clients, and it is how Evertrust PKI keeps p99 latency low under high-volume stapling refresh patterns.
Unified revocation visibility via CLM — revoking a certificate in Evertrust CLM updates the OCSP responder, the CRL, and the inventory in a single workflow, with the option to automatically issue and deploy a replacement so that revocation does not turn into an outage. You see what was revoked, when, why, and what is now in its place — across every CA you operate or consume from.