OCSP Responder (OCSP server)

An OCSP responder is the HTTP service, listed in a certificate's AIA extension, that answers OCSP queries. Under RFC 6960 a response must be signed either by the issuing CA itself or by a delegated responder certificate that the CA issued directly and that carries the OCSP Signing extended key usage. Large CAs pre-generate responses for every unexpired certificate and serve them through CDNs, which works because requests can be sent as HTTP GET and cached until nextUpdate.

Why it matters

The responder is a service that every relying party may hit, so its availability, latency and freshness directly affect websites. If it is down, most browsers soft-fail, but clients enforcing Must-Staple and servers relying on stapling can break. A responder also sees who checks which certificate, the privacy problem that pushed the industry toward stapling, CRLs and browser-pushed revocation lists. After Ballot SC-063 made OCSP optional, some CAs began retiring responders; Let's Encrypt shut its responders down on 2025-08-06.

Example

Query a responder directly and print the full signed response:

openssl ocsp -issuer intermediate.pem -cert cert.pem \
  -url http://ocsp.example.com -resp_text

In the output, Responder Id shows who signed the answer; a delegated responder certificate, when included, lists OCSP Signing under Extended Key Usage. This Update and Next Update show how fresh the cached response is.

Common misconceptions

• The responder checks a live database for every request. Most responses are pre-signed and cached, so a new revocation may only appear after the next refresh.
• Any certificate from the CA can sign OCSP responses. Only the CA key itself, or a certificate the CA issued directly with the OCSP Signing EKU, is authorized.
• A responder outage blocks visitors. Usually not, because clients soft-fail, which is also why an attacker who blocks OCSP can defeat the check.