OCSP Response & Request Decoder

How to use

1. Drop the .der file, or paste the response as base64, PEM or a hex dump from a packet capture. Everything is parsed in the page.
2. Read the response status first. Anything other than successful is a complete, unsigned response that carries no certificate status at all.
3. Check the certificate status table: good, revoked or unknown, with thisUpdate and nextUpdate beside it, and the revocation time and reason where there is one.
4. Look at the freshness line and the reference instant next to it. A response past nextUpdate is one a compliant client would refuse.
5. Paste the request you sent into the last box to confirm the responder echoed its nonce, and read the certificates section to see whether a delegated responder holds id-kp-OCSPSigning.

Frequently asked questions

My response is only six bytes. Is it truncated?

Almost certainly not. An OCSPResponse is a SEQUENCE whose first field is the status, and the response bytes that follow are present only when that status is successful. So malformedRequest, internalError, tryLater, sigRequired and unauthorized are complete responses in five or six bytes: no signature, no producedAt, no certificate mentioned. tryLater in particular is what a busy responder returns under load, and a client is meant to retry rather than treat it as a failed check. If you are storing responses for stapling, storing one of these is the bug — nothing downstream can learn anything from it.

Why does the CertID still use SHA-1, and is that a weakness?

Because it identifies rather than authenticates. A CertID is the hash of the issuer name, the hash of the issuer public key and the certificate serial number; it is a lookup key that lets the responder find the right entry, and the answer it returns is protected by the signature over the whole response, not by the hash. A collision attack would need two issuers with the same name hash and key hash and the same serial, which buys an attacker nothing they could not get more easily elsewhere. That is why RFC 6960 still names SHA-1 here while everything else has moved on. A SHA-1 signature on the response, on the other hand, is a real problem, and this decoder flags that separately.

The response has no nextUpdate. When does it expire?

It does not, formally. RFC 6960 says that when nextUpdate is absent, newer information is available at all times, and the response may be relied on until it is superseded. In practice clients apply their own ceiling, but many will accept such a response for as long as it parses, which is exactly the window a replay attack wants. That is what makes the nonce interesting: with one, a captured response cannot be reused for a later question, because the answer is bound to a value the client chose.

The responder dropped my nonce. Is the response invalid?

No, and this is the most common surprise when debugging. Big public CAs precompute responses in bulk and serve them from a CDN, which is incompatible with echoing a per-request nonce, so they simply omit it — RFC 8954 even allows a responder to ignore the extension. The response is still valid; what you lose is the proof that it was made for your request, and you fall back on thisUpdate and nextUpdate for freshness. Paste your request into this tool and it will tell you whether the nonce came back, was dropped, or came back different, which is the case that really does mean you are looking at the answer to someone else's question.

What is the difference between unknown and a response that says nothing?

unknown is a real answer: this responder has no record of that serial, usually because the certificate was issued by a different CA than the one the CertID names, or because it never existed. It is not the same as good, and a client should not treat it as such. It is also not the same as an unauthorized response, which says the responder will not answer for this certificate at all. And if the response carries the extended-revoke extension, the meaning narrows further: such a responder answers revoked, with a revocation time at the start of 1970, for certificates it never issued, so unknown from it means something closer to "not in my scope".

Can this tool tell me which certificate the response is about, or verify the signature?

Not the first, and it deliberately does not claim the second. The CertID is a set of hashes plus a serial, and hashes do not run backwards, so the only way to match a response to a certificate is to hash that certificate's issuer name and key and compare — you need the certificate in hand already. Signature verification needs the issuer public key, which this page does not have and does not fetch, so what you see is a faithful reading of the bytes rather than a trust decision. What it can settle from the bytes alone is who signed: hashing the key of each certificate carried in the response and comparing it with the CertID's issuerKeyHash distinguishes the issuing CA from a delegated responder.

Related tools