How to Check if a Certificate Is Revoked
A certificate can be perfectly in date and still be poison — revoked because its key leaked or it was issued in error. Checking revocation means asking the CA, through a CRL or OCSP, whether this exact serial has been pulled. This guide covers both mechanisms, why stapling and fail policy matter, and how to tell a real revocation from an inconclusive answer.
In plain words
Checking whether a certificate is revoked means asking its CA — via a CRL or an OCSP query — if the serial has been pulled before expiry, and PlayCISO has a free, browser-based Certificate Revocation Lab to run both and compare them.
Prefer OCSP stapling for fresh, private answers, decide soft-fail vs hard-fail on purpose, and never read unknown as good — only a signed good is a clearance, and a revoked result means replace the key and certificate now.
Step by step
- 1
Know what revocation means and why it matters
Revocation is a CA declaring a still-unexpired certificate no longer trustworthy — usually because the private key was exposed, the cert was mis-issued, or the owner asked for it. A valid, in-date certificate can therefore still be dangerous, so expiry checks alone are not enough. Revocation is the mechanism that lets a CA pull trust back before the clock runs out.
- 2
Read the revocation pointers inside the certificate
Open the certificate and find two extensions: CRL Distribution Points (a URL to a certificate revocation list) and Authority Information Access, whose OCSP entry gives the responder URL. These tell you where to ask about this specific certificate. If a certificate carries neither, you cannot check it at all, which is itself a finding worth noting.
- 3
Check a CRL for bulk, point-in-time status
A CRL is a CA-signed list of revoked serial numbers that you download and search for this certificate’s serial. CRLs are authoritative and work offline once fetched, but they can be large and are only as fresh as their nextUpdate field — a certificate revoked an hour ago may not appear until the next CRL is published. Use CRLs for audits and batch checks.
- 4
Query OCSP for a single fresh answer
The Online Certificate Status Protocol asks the CA’s responder about one certificate and gets back a signed good, revoked, or unknown — far smaller and fresher than a whole CRL. The trade-off is a live network call per check and a privacy leak (the responder learns which sites you visit), which is exactly what stapling is designed to fix.
- 5
Prefer OCSP stapling at the server
With OCSP stapling the TLS server fetches its own signed OCSP response periodically and attaches (staples) it to the handshake, so the client gets fresh revocation proof without contacting the CA itself. This is faster and preserves client privacy. Enable it on your server and confirm a stapled response is actually present in the handshake — a misconfiguration silently falls back to no stapling.
- 6
Decide your soft-fail vs hard-fail policy
If the revocation service is unreachable, a soft-fail client treats the certificate as valid and continues, while a hard-fail client refuses the connection. Soft-fail (the browser default) keeps sites reachable but lets an attacker who can block the OCSP call bypass revocation entirely; hard-fail is secure but brittle if the responder has an outage. Choose deliberately per environment and document it.
- 7
Distinguish unknown from revoked — and act accordingly
Treat the three OCSP outcomes differently: good means proceed; revoked means stop and replace the certificate immediately, treating the key as compromised; unknown means the responder has no record (often the wrong responder or a very new cert) and is not a clearance — investigate rather than assume safe. For a confirmed revocation, rotate to a fresh key and certificate and, if the key leaked, hunt for misuse.
Run CRL and OCSP checks against sample certificates, see stapling in action, and watch how soft-fail and hard-fail diverge — all in your browser.
Related
How trust, keys and certificates work across the PlayCISO labs.
Rotate TLS certificates without downtimeWhat to do the moment a certificate comes back revoked.
Certificate Chain LabA revoked intermediate breaks every leaf beneath it — see the chain validate.
All PlayCISO labsHands-on, browser-based security labs across crypto, cloud and incident response.
Frequently asked questions
What is the difference between a CRL and OCSP?
A CRL is a CA-signed list of all revoked serial numbers that you download and search; it is authoritative and works offline but can be large and stale between publications. OCSP asks a responder about a single certificate and returns a small, fresh signed answer, at the cost of a live network call and a privacy leak. CRLs suit batch and audit checks; OCSP suits per-connection checks, ideally via stapling.
Does a certificate being unknown in OCSP mean it is safe?
No. Unknown means the responder has no status record for that certificate, which usually points to querying the wrong responder, a certificate issued by a different CA, or a cert so new its status has not propagated. It is neither a clearance nor a revocation, so you should investigate the cause rather than treat it as good.
What is OCSP stapling and why use it?
OCSP stapling has the web server fetch its own signed OCSP response on a schedule and attach it to the TLS handshake, so the client gets fresh revocation proof without contacting the CA. It is faster, reduces load on the responder, and keeps the client’s browsing private. Enable it on the server and verify a stapled response actually appears, since a misconfiguration quietly disables it.
What is the difference between soft-fail and hard-fail?
When the revocation service cannot be reached, soft-fail clients assume the certificate is valid and continue, while hard-fail clients refuse the connection. Soft-fail keeps sites usable during responder outages but lets an attacker who can block the check evade revocation; hard-fail is stricter but can cause outages if the responder is down. Browsers default to soft-fail; security-sensitive internal systems often choose hard-fail.
My certificate came back revoked. What should I do?
Stop using it immediately and assume the associated private key may be compromised. Generate a brand-new key and certificate signing request, obtain a fresh certificate, and deploy it. If the revocation was due to key exposure, investigate where the key could have been used by an attacker and rotate anything that trusted it.