Check Certificate Revocation Lists - paste a certificate or enter a CRL URL
Fetching and parsing CRL...
Issuer
Revoked
Next Update
Serial Number
Revoked Date
No revoked certificates
This CRL contains no revoked certificates.
About CRL Checker
Our free CRL Checker queries Certificate Revocation Lists to verify if a certificate has been revoked. Enter a certificate's PEM text or URL to check its revocation status against the issuing CA's CRL distribution point.
How to Use
1Paste the certificate PEM text or enter a CRL distribution URL.
2Click "Check CRL" to query the revocation list.
3View the revocation status and reason if revoked.
A Certificate Revocation List is a signed file, published by the authority that issued your certificate, naming every certificate it has withdrawn. It is large, it is downloaded whole, and it is the mechanism most major authorities now rely on.
1Read the distribution points out of your certificate. The CRL Distribution Points extension names the addresses to fetch. Only entries given as a URI are used, so a list expressed by LDAP or directory name is skipped.
2Fetch each list, following redirects, with a fifteen second timeout per address.
3Parse it as a DER-encoded CRL and read the issuing authority, when the list was last updated, and when it expires.
4List every withdrawn certificate as its serial number in hexadecimal, with the date and time it was revoked.
The list is parsed, not authenticated: the signature is not checked against the issuer's key, so read this as a view of what the authority has published rather than as proof that the publisher was who it claims to be.
Tips & Best Practices
•CRLs can be delayed — for real-time checks, use OCSP instead
•Check CRL if you suspect a certificate was compromised
•Monitor CRL distribution points for availability issues
Frequently Asked Questions
A Certificate Revocation List is a signed file published by the authority that issued your certificate, naming every certificate it has withdrawn before that certificate's own expiry date. It exists because a certificate normally cannot be taken back: once issued it is valid until it runs out, so the only way to withdraw one early is for the authority to publish a list saying so. Clients download the list and check your certificate's serial against it, which is why a missing intermediate and a stale list both surface as trust errors.
That the serial number you are checking does not appear in the list, which is the result you want. It is only meaningful under two conditions: that the list is current, and that it is the right list for that certificate. Check the next update timestamp is still in the future, and check the issuer matches, because serial numbers are unique per authority rather than globally. A list that has stopped being updated produces a confident wrong answer here rather than an obvious failure.
Typically every few hours to a day for a busy authority, and far less often for a quiet one. The authority states when it intends to publish the next list in the next update field, and that is the authoritative answer rather than any general expectation. A list past its next update is a failure at the authority, not a finding about your certificate: every certificate issued under that authority becomes indeterminate, because an absent serial no longer proves anything about a list that stopped changing.
It means the authority has not withdrawn that certificate, which is the answer you want — but only if the list is current and the serial is the right one. Serial numbers are unique per authority, not globally, so a serial read from a different chain will not match even though the certificate is fine. Confirm the issuer and subject alongside it, and check that the list's next update is still in the future. A stale list produces a confident wrong answer rather than an obvious failure.
Because the goal here is to show you what the authority has published and let you reason about it, not to make a trust decision on your behalf. Checking the signature means fetching the issuer's certificate and validating a chain up to a trust anchor, which is exactly what a browser does and exactly what makes the result meaningful. Doing it properly would also make this page a trust oracle. Use this to read the list; use your browser, or a validator, when you need a verdict you can rely on.
The next update timestamp is the authority's promise that a fresher list will exist by then. When it has passed, the publisher has failed to keep it updated, and every certificate in that issuer's chain becomes indeterminate: you can no longer conclude that an absent serial is unrevoked, because the absence might just mean the list stopped changing. This happens after CA incidents and during migrations. Treat a list that is weeks past its next update as an outage at the authority, not as a result about your certificate.
Because the certificate does not name any. Plenty of certificates are issued without a CRL distribution point at all, in which case there is genuinely no list to fetch for them. Two other possibilities: the extension is present but written in directory form rather than as a URI, in which case it is skipped rather than guessed at; or the certificate is self-signed or from a private authority that maintains revocation internally. Check the issuer before concluding the authority has no revocation policy.
Neither, and they solve the same problem differently. OCSP asks one question and gets one answer, which is fast but requires reaching a responder that must scale to every visitor. A CRL is published once and then downloaded whole, which is efficient for an authority but expensive for a client, since a busy authority's list can run to tens of megabytes. That size is the practical reason OCSP was designed the way it was, and also why the industry has drifted back toward CRLs now that caching and partitioned lists have improved.
