Skip to content
AZ Tools

CRL Decoder (X.509)

Decodes an X.509 certificate revocation list — DER or PEM — and shows what a client would see in it. The overview gives the version, the signature algorithm, the CRL number, the thisUpdate and nextUpdate window and whether the list is still current, plus whether it is a full list or a delta that only carries the changes since a base CRL. Below that come the issuer name, the authority key identifier that ties the list to a particular CA key, and the issuing distribution point that says which certificates this list is allowed to speak for. Each revocation is listed with its serial number, the date it was revoked, the reason code if the CA recorded one, and the invalidity date, which is the different and more interesting field: revocationDate is when the CA acted, invalidityDate is when the key is believed to have been compromised, and the gap between them is the window in which signatures should not be trusted. Paste the issuing CA's certificate and the list's signature is verified against its public key with WebCrypto — RSA and ECDSA are supported — so you can tell a genuine list from one that has been edited or served by the wrong authority; offering a certificate whose key could not possibly have signed it is reported as a mismatch rather than as an inconclusive check. Two cautions. A serial appearing here only means something if this is the right list for that certificate, which is what the issuer and the distribution point tell you. And a very large CRL — some are hundreds of thousands of entries — is counted in full but only the first five hundred rows are drawn, because rendering the rest would freeze the tab rather than tell you anything more.

How to use

  1. Drop the .crl file onto the box, or paste a PEM list. A .crl file is raw DER and does not open in a text editor.
  2. Check the window first: a list past its nextUpdate is stale, and most clients will refuse it rather than fall back to trusting everything.
  3. Read the CRL number and the scope. A delta CRL only lists what changed since the base number it names, so it is not the whole picture on its own.
  4. Look up your serial in the table, and read the reason next to it — certificateHold is a suspension that can be lifted, the rest are permanent.
  5. Paste the issuing CA certificate to verify the signature when the list came from anywhere you do not fully control.

Frequently asked questions

What is the difference between the revocation date and the invalidity date?
The revocation date is when the CA published the fact; the invalidity date, an optional entry extension, is when the certificate is believed to have actually become untrustworthy — usually when a key was compromised. They can be far apart, because a compromise is often discovered days after it happened. It matters when you are judging an old signature: a signature made before the invalidity date may still be acceptable, while one made after it is not, even though both predate the revocation itself.
The list says certificateHold. Is that certificate revoked or not?
It is suspended rather than revoked. certificateHold is the one reason code that can be undone: a later CRL can carry the same serial with reason removeFromCRL, which lifts the hold and puts the certificate back in service. Because of that, a client cannot cache a hold as permanent the way it can with keyCompromise. In practice most public CAs never use it, so seeing it usually means a private or enterprise PKI.
What is a delta CRL, and can I use one on its own?
No — a delta lists only the changes since a specific base CRL, named in its Delta CRL Indicator extension, and is meant to be applied on top of that base. It exists because a full list for a large CA can be enormous, and re-downloading it hourly is wasteful when only a handful of certificates change. If this tool shows a delta, the entries you see are the recent changes and not the complete set of revoked serials.
Does a missing serial mean the certificate is good?
Only if this is the right list, it is current, and the certificate was issued by this CA. A CRL speaks for a defined scope: the issuer name and, when present, the issuing distribution point limit which certificates it covers. A serial absent from an unrelated CA's list tells you nothing. It also has to be fresh — an expired list may simply predate the revocation you are looking for, which is exactly why clients reject stale ones instead of reading them anyway.
How is the signature checked, and what does a failure mean?
The list's signed portion is verified against the public key of the certificate you paste, using the browser's WebCrypto with the algorithm the list names — RSA PKCS#1 v1.5 or ECDSA. A pass means that CA key really did sign these bytes and nothing has been altered. A failure means either the list was modified or the certificate you supplied is not the issuer; if its key is of a kind that could not have produced this signature at all, that is reported as a mismatch rather than as an unsupported algorithm.
Is the file uploaded anywhere?
No. Both the list and any certificate you paste are read and parsed in the page itself, and the signature check runs on the browser's own WebCrypto implementation. Nothing is sent to a server and there is no server-side component to send it to. A revocation list is public information, but a private-PKI one may not be, which is the reason this runs entirely client-side.

Related tools