CRL Distribution Point Checker

Read the CRL distribution points a certificate publishes and check they resolve, with a clear statement of what CRL data can and cannot tell you.

Passive public check

a2z.tools reads publicly visible information from the address you enter. It is a read-only request - nothing is submitted, changed or probed.

Domain Opens one TLS handshake, reads the certificate, and fetches the CRL endpoints it names.

What a CRL is

A Certificate Revocation List is a signed file published by a certificate authority listing the serial numbers of certificates it has revoked before their expiry. A certificate points at where its issuer publishes that list, in the CRL Distribution Points extension.

This tool reads that extension, fetches each HTTP distribution point, and checks that what comes back is actually a CRL.

It checks the list is published, not whether you are on it

Determining whether this specific certificate is revoked means downloading the entire list - frequently several megabytes - parsing the DER, verifying the issuer's signature over it, and searching for this serial number. Doing that badly produces confident wrong answers about a working certificate, which is a worse outcome than not doing it.

So the tool establishes what a passive check reliably can: the endpoint exists, it answers, and what it returns is a DER-encoded list rather than an error page. If you need the definitive answer:

curl -s -o crl.der <distribution-point-url>
        openssl crl -inform DER -in crl.der -text -noout | grep -i <serial>

The error-page-with-a-200 case

A specific failure this catches: a distribution point that returns HTTP 200 with an HTML error page or a redirect body instead of a CRL. A client fetching it gets a success status and then fails to parse the result, which is considerably more confusing to debug than a clean 404. The tool checks the first byte for the DER SEQUENCE tag, which distinguishes the two immediately.

Browsers mostly do not fetch CRLs

Worth understanding before you weigh a finding here. CRLs can be very large, and fetching one on every connection would be slow enough to be unacceptable, so browsers largely stopped. They rely instead on aggregated lists compiled by the vendor and shipped with the browser - Mozilla's CRLite and Chrome's CRLSets - which cover the revocations that matter most and cost nothing at connection time.

Non-browser clients are different. Many API clients, mobile SDKs, Java applications and enterprise middleware do check CRLs, and for them an unreachable distribution point is a hard failure. If your certificate serves an API rather than a website, this check matters considerably more.

Missing CRL points are not necessarily wrong

Some modern certificates publish no CRL distribution point at all, particularly short-lived ones where the validity period is shorter than revocation would usefully propagate. The tool reports that as informational with the reasoning, rather than as a fault.

Frequently asked questions

Does this tell me if my certificate is revoked?

No. It confirms the revocation list is published and fetchable. Checking whether a specific serial is on it means downloading and parsing a potentially very large signed file, and the page gives you the openssl commands for that.

My certificate has no CRL distribution point. Is that bad?

Often not. Short-lived certificates frequently omit it because they expire faster than revocation would propagate. It matters more if non-browser clients consume your certificate, since many of them do check.

Why does it flag a CRL endpoint that returned HTTP 200?

Because what came back was not a CRL. A DER-encoded list starts with a SEQUENCE tag; an HTML error page does not. A 200 with the wrong body is harder to debug than an honest 404, which is why it is called out.

Do browsers use CRLs at all?

Rarely directly. They use aggregated lists shipped with the browser - CRLite in Firefox, CRLSets in Chrome. Other client types still fetch CRLs the traditional way.

References

Related tools

What this tool can and cannot tell you. It reports the configuration a site exposes to an ordinary visitor. It does not log in, submit anything, or test for vulnerabilities, so a passing result means the public configuration looked correct at the moment of the check - not that the site is secure.

Security guidance here follows current published sources - OWASP, MDN, the relevant RFCs, NIST, CISA, FIRST and MITRE - which are linked beside the specific claims they support.