OCSP Checker
Query the CA's OCSP responder for live revocation status.
Enter a value above to run OCSP Checker
e.g. example.com
Quick answer
OCSP Checker queries a certificate's issuing CA for its live revocation status (good, revoked, or unknown) and reports whether the server staples OCSP into the handshake. Note that as of 2025 Let's Encrypt certificates no longer carry OCSP URLs and use CRLs instead, so a missing responder is normal.
OCSP Checker asks a certificate's issuing CA whether that certificate has been revoked, using the Online Certificate Status Protocol. You give it a hostname and port; it fetches the served certificate, reads the OCSP responder URL from the certificate, and queries that responder for a live good, revoked, or unknown answer. It also reports whether the server staples an OCSP response into its TLS handshake, which is the faster, more private way to deliver the same status.
Revocation is what happens when a certificate must be invalidated before it expires, usually because the private key was compromised or the certificate was mis-issued. Historically clients checked this with OCSP. That landscape is changing: in 2025 Let's Encrypt, the largest CA, stopped including OCSP URLs in its certificates and moved to CRLs, so a Let's Encrypt certificate with no OCSP responder is now completely normal rather than a fault. This tool reflects that reality.
How OCSP works
The certificate carries an Authority Information Access field naming its CA's OCSP responder. A client sends that responder the certificate's serial number, and the CA returns a signed statement: good, revoked, or unknown, with a validity window. The tool does this for the certificate the host serves, so you get the CA's current verdict on that exact certificate rather than a cached or assumed status.
OCSP stapling
Classic OCSP makes every visiting client contact the CA, which is slow and leaks which sites a user visits to the CA. OCSP stapling fixes both: the web server itself periodically fetches a fresh signed OCSP response and staples it into the TLS handshake, so clients get the revocation proof directly from the server with no extra round trip. The checker reports whether your server staples; enabling it improves handshake speed and privacy and is the recommended configuration.
The 2025 shift to CRLs
OCSP is being wound down across the industry. Let's Encrypt announced the end of its OCSP service and, in 2025, stopped putting OCSP URLs in newly issued certificates, relying on Certificate Revocation Lists (CRLs) that browsers aggregate instead. So if this tool shows no OCSP responder for a Let's Encrypt certificate, that is expected and correct, not a misconfiguration. Browsers increasingly consume revocation through their own aggregated CRL mechanisms (such as CRLite and Chrome's CRLSets) rather than live OCSP.
Reading the result
Good means the CA considers the certificate valid right now. Revoked means it has been invalidated and clients should reject it; investigate immediately, because a revoked certificate in production is a serious incident. Unknown means the responder has no record of that serial, which can indicate the wrong responder or a very new certificate. No OCSP URL at all is increasingly normal, especially for Let's Encrypt, and simply means revocation is published via CRLs instead.
Frequently asked questions
- My certificate has no OCSP URL, is something wrong?
- Not necessarily, and for Let's Encrypt it is expected. In 2025 Let's Encrypt stopped including OCSP responder URLs in its certificates and moved to CRLs, so a missing OCSP URL on such a certificate is normal. Revocation is still published, just through CRLs that browsers aggregate rather than through a live OCSP query.
- What is the difference between OCSP and a CRL?
- OCSP is a live, per-certificate query: you ask the CA about one serial and get a signed answer now. A CRL (Certificate Revocation List) is a periodically published list of all revoked serials that clients download and cache. The industry is shifting from live OCSP toward CRLs that browsers aggregate and distribute efficiently, which is why some certificates no longer carry OCSP URLs.
- What does OCSP stapling do and should I enable it?
- Stapling has your server fetch the signed OCSP response itself and attach it to the TLS handshake, so clients get revocation status without contacting the CA. It removes a round trip, improves handshake speed, and stops the CA from learning which clients visit you. Yes, enable it where your certificates still carry OCSP URLs; it is the recommended setup.
- What does a revoked result mean for my site?
- It means the CA has invalidated that certificate before its expiry, typically due to key compromise or mis-issuance, and compliant clients will refuse to trust it. Treat it as an incident: identify why it was revoked, rotate the key if it was exposed, and install a freshly issued certificate immediately, because visitors will see hard errors.
- Why did I get an unknown status?
- Unknown means the responder has no record for that certificate's serial. Common causes are querying a responder that belongs to a different CA, a certificate issued so recently the responder has not caught up, or a certificate that was never issued by that CA at all. Confirm you are checking the certificate the host actually serves and that its OCSP URL is the issuer's.
- Do browsers even check OCSP anymore?
- Increasingly they do not, at least not the classic live OCSP query. Chrome has long relied on its own aggregated CRLSets rather than live OCSP, and Firefox uses CRLite. Combined with CAs like Let's Encrypt dropping OCSP for CRLs, the trend is toward browser-aggregated revocation data. OCSP stapling remains useful where certificates still support it.