OCSP 解码器与请求生成器

What OCSP is

The Online Certificate Status Protocol, RFC 6960, lets a client ask a CA about one certificate at a time instead of downloading its whole CRL. The request names the certificate by a CertID: a hash of the issuer's name, a hash of the issuer's public key and the certificate's serial number. The answer — a BasicOCSPResponse — says good, revoked (with the time and usually a reason) or unknown, carries thisUpdate and nextUpdate times like a CRL, and is signed either by the CA itself or by a responder certificate the CA issued for that purpose. Servers can staple a recent answer into the TLS handshake (OCSP stapling), so the client never has to ask.

Where OCSP still matters: many CAs keep responders running for TLS and code signing, enterprise and payment systems check them, and stapled answers are still seen in handshakes. Let's Encrypt shut its responders down in 2025 and browsers rely on CRL-based data, so for some certificates the right tool is the CRL decoder.

Decoding a response

Paste the response as base64 or hex, or drop the .der file that openssl ocsp -respout or curl -o wrote. The decoder reads the response status first: anything but successful (malformedRequest, internalError, tryLater, sigRequired, unauthorized) means the responder did not answer the question, and there is nothing else inside. For a successful response it shows every single response it contains, the producedAt time, the responder's name or key hash, the nonce and the extensions.

The answer is only worth something if it is about your certificate, recent, and signed by someone entitled to answer. Add the certificate and its issuer, and the decoder checks all three:

• Is it about this certificate? The CertID is recomputed from the certificate and the issuer — with SHA-1 or whatever hash the response used — and compared with each single response.
• Who signed it? If the responder ID names the issuer, the signature is verified with the issuer's key. Otherwise the decoder looks for a responder certificate inside the response, checks that the CA issued it, that it carries the OCSP Signing extended key usage, and that it was valid when the answer was produced — the rules of RFC 6960 §4.2.2.2. A response signed by anyone else is not authoritative, however valid its signature.
• Is it fresh? thisUpdate must not lie in the future and nextUpdate must not have passed; the CA/Browser Forum also caps validity at ten days, which the decoder flags when exceeded. If you sent a nonce, add it and the decoder checks that the response echoes it — most public CAs serve pre-signed answers and do not.

Building a request

Switch to "Build a request", paste the certificate and its issuer — or the whole chain, from which the issuer is picked — and the request is built exactly as openssl ocsp builds it: a SHA-1 CertID by default (CA/Browser Forum responders must accept it), optionally SHA-256, SHA-384 or SHA-512, and an optional random nonce in the RFC 8954 form. The request is shown as base64 and hex and can be downloaded as a .der file. For each responder named in the certificate's authority information access extension you get the GET URL of RFC 6960 Appendix A.1, a curl command that posts the request, and the equivalent openssl ocsp command. When the answer comes back, one click takes you to the decoder with the certificate, issuer and nonce already filled in.

What runs where

Everything on this page — decoding, hashing, signature checks, building requests — happens in your browser. The page does not contact any responder: you send the request yourself with the commands above, so the only party that learns which certificate you asked about is the CA you chose to ask. Nothing you paste is sent to us. Share links carry the response, the certificates and the nonce in the URL fragment, which browsers do not send to servers, and never a private key.