OCSP/CRL Revocation Checker

Find the OCSP responder and CRL distribution points inside a certificate

Paste a PEM-encoded X.509 certificate and this tool extracts the revocation endpoints embedded in it: the OCSP responder URLs from the Authority Information Access extension, and the CRL distribution point URLs. It then hands you the exact openssl commands to query those endpoints, pre-filled with the URLs it found.

Be clear on what that is and is not. This tool reads the certificate; it does not contact the CA. Browsers cannot make an OCSP request to an arbitrary responder — the responders do not send CORS headers, so the request is blocked before it leaves the page. Live revocation checking has to happen from a command line or a server. What you get here is everything you need to run that check, extracted in your browser, plus the answers to the questions that come up while you are doing it.

How to use it

• Paste the certificate between and including the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- lines. The tool base64-decodes the body and scans the DER for URL patterns.
• You get back the subject common name, every distinct OCSP responder URL, and every distinct CRL distribution point.
• Copy the generated commands and run them where outbound HTTP is available.

The certificate never leaves your browser. Decoding and pattern extraction run entirely client-side, with no upload and no network request — which matters, because certificates from internal PKI often carry hostnames you would rather not paste into someone else's server.

There is a domain input mode, but it does not fetch certificates from live hosts; it points you at a checker that does. To go from a hostname to a PEM you can paste here, either retrieve it with openssl s_client -connect example.com:443 -showcerts or export it from your browser's certificate viewer.

Extraction is pattern-based rather than a full ASN.1 parse, which makes it fast and dependency-free but means it reports URLs and the common name, not a complete decoded certificate. If you need the serial number, the extensions, or the full subject and issuer, decode the same certificate with the X.509 decoder — and you will need that serial number to interpret a CRL anyway.

Running the actual check

An OCSP query needs three things: the certificate, the certificate that issued it, and the responder URL. The issuer is not optional — OCSP identifies a certificate by a hash of the issuer name and key plus the serial number, so without the issuer certificate there is nothing to hash.

openssl ocsp -issuer issuer.pem -cert cert.pem -url http://ocsp.example-ca.com -text

The response you care about is a single line: cert.pem: good, revoked, or unknown. If you get unknown, the responder does not recognise the certificate — usually because you paired it with the wrong issuer, or because you are querying a responder that does not serve that CA.

A CRL check is a download and a search:

curl -o crl.der http://crl.example-ca.com/ca.crl then openssl crl -inform DER -in crl.der -text

CRLs are DER-encoded, so -inform DER is mandatory; leaving it off produces an unhelpful parse error. The output is a list of serial numbers with revocation dates. Search it for your certificate's serial — absence from the list means not revoked.

OCSP versus CRL

Both answer the same question by opposite methods. A CRL (RFC 5280) is a signed list of every serial number the CA has revoked, published as a file and refreshed periodically. OCSP (RFC 6960) is a request-response protocol: you ask about one specific certificate and get a signed answer about that certificate.

The privacy row is the one people underrate. Every unstapled OCSP request tells the certificate authority that someone at this IP address is about to load this site, right now. Aggregated across a CA that covers a large slice of the web, that is a browsing-history feed as a side effect of a security check.

OCSP stapling, and the two problems it solves

Stapling inverts who does the asking. Instead of every visitor querying the CA, the server queries the responder on a schedule, caches the signed response, and includes it in the TLS handshake using the Certificate Status Request extension (RFC 6066). The response is signed by the CA and timestamped, so the server cannot forge or replay a stale one beyond its validity window.

That fixes both weaknesses at once:

• Privacy. The CA sees one request per server per refresh interval instead of one per visitor. It learns nothing about who is browsing.
• Latency. An unstapled check inserts a fresh DNS lookup and HTTP round trip to a third-party responder into your page load, on the critical path, before any content renders. Stapling removes it entirely — the answer arrives inside the handshake you were already doing.

Stapling is a server-side configuration (ssl_stapling on in nginx, SSLUseStapling on in Apache) and it is close to free. If you administer a public web server and have not enabled it, that is the single highest-value item on this page. To verify it is working: openssl s_client -connect example.com:443 -status and look for an OCSP Response Status: successful block rather than the words "no response sent".

The gap stapling leaves is that a server can simply not staple, and the client has no way to know whether that is a misconfiguration or an attacker suppressing a "revoked" answer. The OCSP Must-Staple extension (RFC 7633) closes it by marking a certificate as one that must always arrive with a stapled response — but it is a foot-gun: if your stapling breaks, the certificate hard-fails instead of degrading, and adoption has stayed low for exactly that reason.

Soft-fail: why revocation checking is weaker than you think

Here is the part that changes how you should reason about revocation. When a browser cannot reach a revocation service — responder down, network blocked, captive portal, timeout — it does not block the connection. It proceeds. That is soft-fail, and it has been the default behaviour in mainstream browsers for years.

The reasoning is pragmatic. Hard-fail would mean that any CA responder outage takes down every site using that CA, worldwide, instantly — converting a CA's availability problem into a global outage. Nobody was willing to ship that, so soft-fail won.

The security consequence follows immediately. An attacker who can present a stolen certificate is, by definition, in a position to interfere with your network traffic. Blocking or timing out the OCSP request is trivially within their power. Soft-fail then turns a "revoked" answer they could not have obtained into no answer at all, and the browser continues. Against exactly the adversary revocation exists to stop, classical OCSP provides close to nothing.

Practical implications:

• Do not treat revocation as a control you can rely on to contain a key compromise. Replacing the certificate and, where it matters, rotating what the key protected is the real remediation.
• Short certificate lifetimes are the actual mitigation. A certificate that expires in weeks limits the damage window without depending on any revocation infrastructure working.
• Server-to-server and client-authentication scenarios are different. There you control both ends, hard-fail is realistic, and checking revocation properly is worth doing.

CRLSets and CRLite: what browsers actually do

Because live checking was slow, leaky and unreliable, the major browsers largely stopped doing it on the fly and moved the problem to push delivery.

Chrome uses CRLSets: Google aggregates CRLs, filters them down to a curated set of revocations judged important — intermediate CAs, known compromises, high-impact certificates — and pushes the result to browsers as a component update. It is fast and it is local, so there is no responder to block and no privacy leak. The tradeoff is coverage: a routine revocation of one leaf certificate is unlikely to make it into a CRLSet. Chrome has been extending this with a more complete pushed revocation set, but the model is the same — the answer arrives before you need it.

Firefox uses CRLite, which aims at the coverage problem directly. It compresses the full set of known revocations for publicly trusted certificates into a compact cascading-filter structure small enough to push to every client and update frequently. The result is a complete revocation answer computed locally, with no request to anyone, and it is able to hard-fail because there is nothing to be offline about.

Both approaches share a design insight worth internalising: the reliable way to check revocation is to already have the answer. Asking a third party at connection time was always going to be blockable, slow and privacy-invasive.

What this means for you as an operator: after you revoke a certificate, do not assume browsers will start rejecting it promptly. Some will, some will not, and the timing depends on push cycles you do not control. Revoke, but also remove the certificate from every server, rotate the key, and monitor for the old one still being served.

Revocation reason codes

When a CRL entry or OCSP response carries a reason, it is one of the RFC 5280 codes. They matter mainly because keyCompromise triggers different handling from a routine replacement.

Troubleshooting what the extraction gives you

• No OCSP URL and no CRL URL found. Legitimate for a root certificate, which is trusted directly and has nothing above it to publish revocation. Also normal for many internal-CA certificates issued without AIA or CDP extensions — which means clients have no way to check them at all.
• Only a CRL, no OCSP. Increasingly common. Several CAs have been retiring OCSP responders in favour of CRLs, given how much operational load a global responder carries for a check most clients soft-fail anyway.
• Could not parse the certificate. The input must be PEM. A DER or PKCS#12 file will not work — convert first with openssl x509 -inform DER -in cert.der -out cert.pem.
• You pasted a chain. The extraction works on the first certificate block. Split the chain and check the leaf and the intermediate separately — intermediates get revoked too, and that is the revocation that takes everything below it with it.