CRL Distribution Point Checker Guide: Read a Certificate's Revocation Address
A certificate is a promise with an expiry date, but expiry is not the only way a certificate stops being trustworthy. A certificate can also be revoked before it expires, for example when its private key is suspected to be compromised or when the certificate was issued in error. Revocation is how the issuer says, in effect, do not trust this certificate any more, even though its dates have not run out. The problem is that a browser or a system has to find out about the revocation somehow, and that is where the CRL distribution point comes in. A CRL, or Certificate Revocation List, is a signed list of revoked certificates published by the issuer, and the distribution point is the address where that list can be found. The certificate itself carries that address, so anyone checking the certificate knows where to look.
The CRL Distribution Point Checker tool extracts and checks CRL distribution points from pasted text. That scope deserves to be stated plainly, because it shapes everything else in this guide. The tool works on the text you paste, and it checks the format and structure of the distribution points it finds. It does not perform a live lookup, it does not download the revocation list, and it cannot tell you whether a particular certificate has actually been revoked. A well-formed address is not proof that a list exists at that address, and a list that exists is not proof that a given certificate appears on it. What the tool gives you is a first, necessary gate: are the distribution points in this pasted text readable, complete, and correctly shaped, or is there a fault that would stop any later check from working at all.
To understand what the tool is reading, it helps to know where distribution points live inside a certificate. A certificate contains a set of extensions, which are extra fields beyond the basic subject and issuer names. One of those extensions is called CRL Distribution Points, and it holds one or more addresses, usually web addresses starting with http, or directory addresses. Each address points to a CRL file, typically ending in .crl, published by the issuer or by a party the issuer names. When software validates a certificate, it may fetch the CRL from one of those addresses and search it for the certificate's serial number. If the address is mistyped, truncated, or missing its scheme, that fetch cannot happen, and the revocation check fails in a quiet way that is easy to mistake for a pass.
A pasted certificate is often long, and copying it introduces its own hazards. Line breaks can split an address in the middle, a trailing space can creep in after a file name, and a word processor can replace a straight character with a lookalike. The checker helps here because it reads the pasted text as a whole and pulls out the distribution points it can recognise, rather than asking you to find them by eye in a wall of encoded text. That is a genuine convenience, but it is not a substitute for care at the source: if you paste only part of a certificate, the tool can only check the part it received, and a distribution point in the missing part will simply not appear. Always paste the complete block you intend to check, and if the result shows fewer points than you expected, the first suspect should be an incomplete paste, not a fault in the certificate.
A worked example you can follow
Take a sample pasted block that contains two distribution points. The first reads http://crl.example-ca.com/root.crl and the second reads http://crl2.example-ca.com/root.crl. Start by counting: 2 points in total. Next, check each address piece by piece. The first address has a scheme, http, followed by a host name, crl.example-ca.com, followed by a path, /root.crl. That is 3 parts, all present, so the first point is well-formed. The second address has the same 3 parts, with a different host, crl2.example-ca.com, and the same file name, so it is also well-formed. Two points out of 2 pass, which is 2 divided by 2, or 100 percent of the points in the sample.
Now consider the timing side, because a revocation list is only useful while it is fresh. Suppose a sample CRL was issued on 1 May and its next update is dated 8 May. The validity window is 8 minus 1, which is 7 days. If you were checking on 5 May, the list would have 8 minus 5, or 3 days, of life left, which is a comfortable margin. If you were checking on 9 May, the list would be 9 minus 8, or 1 day, past its next update, and a careful checker would treat it as stale and look for a newer list rather than trusting the old one. This arithmetic matters because a distribution point that leads to a stale list is almost as unhelpful as a broken address: the address works, but the information behind it is out of date.
Take a second, broken sample. It contains 3 distribution points, but the third reads crl.example-ca.com/root.crl with no scheme at the front. Count again: 3 points found, but only 2 are complete, so 2 divided by 3 is about 67 percent well-formed, and 1 point, or about 33 percent, is faulty. The fix is small: add the missing http:// to the front of the third address, giving http://crl.example-ca.com/root.crl, and then re-check the whole block. The re-check matters because editing one line can disturb the next, especially when lines are close together. A result of 3 out of 3, or 100 percent, after the fix is the point at which the format side of the job is done, and the separate job of confirming the live list can begin.
Mistakes to avoid
The first mistake is treating a format pass as a revocation verdict. A distribution point can be perfectly well-formed while the list behind it is unreachable, stale, or simply does not contain the certificate you care about. The format check clears the address for use; it does not answer the revocation question. The second mistake is pasting only part of a certificate and concluding that the missing points do not exist. Count the points the tool reports and compare that count with the count you expected, and investigate any gap before drawing conclusions. The third mistake is pasting private keys or other secrets along with the certificate text. A certificate itself is public information, but a private key must never be pasted into any checker, because anything pasted into a web page should be treated as potentially retained. If a paste includes a private key block by accident, stop, remove it, and treat that key as exposed. The fourth mistake is assuming one distribution point is enough and ignoring the rest. Issuers often publish more than one point for resilience, and checking all of them, rather than the first one that looks right, is what makes the result trustworthy.
The SSL Certificate Checker tool is a useful companion when you want to think about a certificate more broadly, and the Security DNS Checker tool helps when a certificate problem turns out to be part of a wider site-security review. For background on how certificates fit into a handover check, see The Pre-Handover Check: Headers, TLS, and DNS in One Routine.
Checking the result before you act on it
Treat a clean format result as permission to move to the next check, not as the end of the work. After the points pass, confirm them in their real context: that the addresses belong to the issuer you expect, that the lists behind them are current, and that the certificate in question is checked against a fresh list. Keep a note of how many points were found, how many passed, and the date of the check, because revocation status is a moving target and a result from last month says nothing about today. A distribution point that is well-formed, current, and checked against a fresh list is a small piece of infrastructure doing its job properly, and each of those three qualities catches a different kind of failure.