Check certificate revocation status via Online Certificate Status Protocol
Querying OCSP responder...
OCSP Status:
OCSP Response Details
Responder
Produced At
This Update
Next Update
About OCSP Checker
Our free OCSP Checker queries the Online Certificate Status Protocol responder to check real-time certificate revocation status. Get instant revocation status without downloading entire CRL files.
How to Use
1Paste the certificate PEM text to check.
2Click "Check OCSP" to query the OCSP responder.
3View the revocation status (good, revoked, or unknown).
Revocation status comes from the certificate's issuer, not from the server being checked. This page reads the Authority Information Access extension to find the responder, then asks that responder directly.
1Fetch the live certificate and read its responder URL from the AIA extension, along with the issuer's own certificate so the OCSP request can be signed and the response verified. Both are needed: an OCSP response is only trustworthy if its signature checks out.
2Build and send an OCSP request naming the certificate and issuer, and read the status from the response the responder returns. That answer is authoritative — it comes from the authority that issued the certificate.
3Report the status as the responder gave it, and distinguish clearly between a genuine good answer, a revoked verdict, and the case where no responder exists. A certificate with no AIA responder is normal for some authorities and says nothing about its validity.
This checks whether the certificate has been revoked at its authority. Whether the server offers a stapled copy during the handshake is a separate question the stapling page covers, and the two together are what a browser actually uses.
Tips & Best Practices
•Use OCSP for real-time revocation checks — faster than CRL
•Enable OCSP stapling on your server for better performance
•Unknown status may indicate a recently issued certificate not yet in the responder
Frequently Asked Questions
The Online Certificate Status Protocol is a request-and-response mechanism for asking a certificate authority whether a specific certificate has been withdrawn, without downloading a whole revocation list to find one serial number. That efficiency is its virtue and also its cost: a responder has to be available and fast enough to serve every visitor, at a scale that a growing number of authorities have decided is not worth paying. Where authorities have moved away from it, they publish a CRL instead and OCSP simply becomes unavailable.
That the certificate authority has confirmed the certificate is not revoked. It is a positive answer from the issuer, and it is worth checking the response's production timestamp alongside it, because an answer produced days ago says less about today than a fresh one. Note the boundary: GOOD confirms the certificate has not been withdrawn, and says nothing about whether it has expired, whether the chain is complete, or whether it covers the hostname you are connecting to.
The server fetches the OCSP response itself, once, and presents it to every client as part of the TLS handshake instead of letting each client go and ask the authority. It removes a round trip to a third party from every connection, which is usually the single largest latency cost in revocation checking, and it also means the client never contacts the authority directly. It requires the full chain on the server and outbound access to the responder; without both it silently does nothing.
It gives you an authoritative answer without waiting for one. A browser only tells you something is wrong after it has decided something is wrong, and often only in the form of a hard-to-dismiss interstitial. Querying the responder tells you the issuer's current verdict directly, which is what you want when triaging a specific certificate rather than browsing.
Because its issuer does not publish one in the AIA extension. Let's Encrypt is the familiar example: it relies on short certificate lifetimes and CRLs rather than OCSP, and its certificates omit the responder URL. That is a legitimate design choice rather than a fault, and it means this page reports no responder rather than a failure. The CRL path covers those certificates.
It is faster and lighter: an OCSP response names one certificate and is a few hundred bytes, while a CRL can be large and is signed over its whole contents. Revocation therefore propagates to clients much sooner through OCSP. The trade-off is availability — a responder that is down should not cause clients to reject valid certificates, which is why stapling exists to decouple the two.
Because revocation only covers certificates someone has reported. Most compromised certificates are never revoked at all: the attacker uses a valid certificate and has no reason to alert anyone. So a clean revocation status means nobody has reported this certificate, which is reassuring about reputation and says nothing about whether it is genuinely being used by its owner.
That is a responder availability problem rather than a revocation answer, and the two must not be conflated. A client that cannot reach the responder should fall back to trusting the certificate, because failing closed on a responder outage would take down large parts of the internet for no security benefit. That fallback is precisely why stapling matters: the server can serve a cached response instead of depending on the responder being up.
