OCSP (Online Certificate Status Protocol) is a protocol that lets a client ask a certificate authority’s responder whether one specific X.509 certificate is good, revoked or unknown, and receive a signed, time-limited answer. In internet trust, OCSP is one of the two classic revocation checking mechanisms of public key infrastructure, alongside certificate revocation lists.
OCSP is specified in RFC 6960. It was designed to replace downloading large revocation lists with a small per-certificate query, but its privacy and reliability problems have led much of the web PKI to rethink how revocation is checked.
How an OCSP query works
An OCSP exchange starts when a client, usually a browser or TLS library, finds the responder URL in the certificate’s Authority Information Access extension. The client sends a request that identifies the certificate by issuer name hash, issuer key hash and serial number.
The responder returns a response signed by the issuing CA or by a delegated responder certificate. The response carries a status, a thisUpdate time, a nextUpdate time that defines its validity window, and optionally a nonce that binds it to one request.
The table summarizes the three possible certificate statuses and how clients interpret them.
| Status | Meaning | Typical client reaction |
|---|---|---|
| good | Not revoked at the time of signing | Connection proceeds |
| revoked | Revoked, with time and reason code | Connection is refused |
| unknown | Responder does not know the certificate | Treated as failure or ignored |
OCSP responders and the certificate chain
An OCSP responder is an online signing service operated by or for the CA. To avoid exposing the CA’s root or issuing key, most CAs issue a dedicated delegated responder certificate that carries the id-kp-OCSPSigning extended key usage and is valid only for signing status responses.
Revocation applies to every link of the certificate chain, not only the leaf. A complete check therefore covers the server certificate and each intermediate CA certificate, while the trust anchor itself is managed through root store updates rather than OCSP. In practice, many clients check only the leaf, which leaves intermediate revocation to browser-pushed lists.
Delegated responder certificates usually include the id-pkix-ocsp-nocheck extension, which tells clients not to check the revocation status of the responder certificate itself. This avoids an endless loop of status queries, but it means such certificates should have short lifetimes because they cannot be revoked effectively.
Key parameters of OCSP responses
The behavior of OCSP depends heavily on timing parameters. A response that is valid for days reduces load and latency but also delays the moment a revocation becomes visible to clients.
| Parameter | Typical range | What it affects |
|---|---|---|
| Response validity | Several hours to 10 days | How long a revocation can stay unseen |
| Responder refresh interval | Hours to about half the validity | Freshness of cached answers |
| Client timeout | A few seconds | Connection delay when a responder is slow |
| Nonce | Optional, often omitted | Replay protection versus cacheability |
| Transport | HTTP GET or POST | GET enables CDN caching of responses |
Most public responders pre-sign responses and serve them from caches, which is why nonces are rarely used. This trade-off favors scalability over strict freshness.
OCSP stapling and Must-Staple
OCSP stapling moves the query from the client to the server. The TLS server fetches its own OCSP response periodically and attaches it to the handshake, so the browser receives proof of status without contacting the CA.
Stapling removes the privacy leak of clients revealing which sites they visit, eliminates an extra round trip, and protects responders from traffic spikes. The Must-Staple extension in a certificate tells clients to reject any connection that lacks a valid stapled response, which closes the soft-fail loophole but makes server misconfiguration fatal.
OCSP compared with other revocation methods
Revocation can be communicated in several ways, and each method balances freshness, privacy, bandwidth and reliability differently. The comparison below places OCSP among its alternatives.
| Method | How status reaches the client | Main strength | Main weakness |
|---|---|---|---|
| CRL | Client downloads a signed list | Works offline once cached | Lists can grow large |
| OCSP | Client queries a responder | Small per-certificate answer | Privacy leak and soft-fail |
| OCSP stapling | Server supplies the response | Private and fast | Depends on server setup |
| Browser-pushed lists | Vendor aggregates CRLs into updates | No live lookup | Coverage chosen by vendor |
| Short-lived certificates | Certificates expire within days | Revocation rarely needed | Requires reliable automation |
Major browsers have largely stopped performing live OCSP checks for ordinary certificates and rely on aggregated revocation lists pushed with updates. Public CA requirements have also made OCSP optional and CRLs mandatory, and some large CAs have announced the shutdown of their responders.
Limitations and common pitfalls
The central weakness of OCSP is soft-fail behavior. Because responders can be slow or unreachable, most clients continue the connection when no answer arrives, so an attacker who can block the query also defeats the check.
- Privacy exposure: every live query tells the CA which certificate, and therefore which site, a user is visiting.
- Responder outages can slow or break connections for clients that hard-fail.
- Stale staples: servers that fail to refresh their staple serve expired responses.
- Firewall blocks on outbound HTTP to responders cause timeouts in enterprise networks.
- Revocation delay: a compromised key remains usable until cached good responses expire.
The simple explanation
A website certificate is like an ID card, and sometimes an ID card is canceled before it expires because it was stolen. OCSP is a phone line to the issuing office where anyone can ask whether one particular card is still valid.
The office answers with a signed note saying good or revoked. The catch is that if the line is busy, most callers assume the card is fine, which is why newer methods hand the proof to the card holder or keep card lifetimes very short.
How it is used in practice
An operations team running an online banking portal enables OCSP stapling on its load balancers. The balancers fetch a fresh response from the CA every few hours and include it in every TLS handshake, so customers never contact the CA directly.
When a staging certificate’s private key is accidentally committed to a code repository, the team revokes it the same afternoon. Because the staple refresh interval is short, the revoked status appears in the next stapled response, and internal monitoring confirms that clients reject the old certificate.
The team also adds monitoring that alerts when a staple is older than half its validity window, which catches a responder connectivity problem before any user notices.