CRL-Decoder: Zertifikatssperrliste (Certificate Revocation List)

What a CRL is

A certificate revocation list is a CA's signed list of the certificates it has revoked before their expiry date — because a private key leaked, a domain changed hands, or the certificate was issued by mistake. Its format is the CertificateList of RFC 5280 §5: the issuer's name, thisUpdate and nextUpdate times, a list of revoked certificates — each a serial number, a revocation date and optional entry extensions such as the reason code — then CRL-wide extensions and the CA's signature over all of it.

Certificates say where their CRL lives in the CRL distribution points extension; clients download it from there over plain HTTP, which is safe because the list is signed. Since browsers dropped online OCSP checks and Let's Encrypt ended its OCSP service in 2025, CRLs are again the main revocation channel of the web PKI — Chrome and Firefox aggregate them into their own compact formats (CRLite in Firefox), and the CA/Browser Forum requires every publicly trusted CA to publish them.

What the decoder checks

The list is decoded with a strict DER reader in one pass, so even shards with hundreds of thousands of entries open in a moment. On top of the raw fields the decoder reports:

• Freshness. A CRL is valid from thisUpdate until nextUpdate; after that clients treat it as no revocation information at all. The decoder compares both with your clock and says how many days remain or have passed. A CRL without nextUpdate is flagged — public CAs must set it.
• The signature. Add the issuing CA's certificate and the signature is verified over the exact tbsCertList bytes, with RSA, ECDSA, EdDSA or DSA as the CRL declares. The decoder also checks that the issuer's key usage allows cRLSign and that the CRL's authority key identifier matches the certificate's subject key identifier — after a CA key rollover that is how clients pick the right key. Certificates pasted together with the CRL are considered as the issuer too.
• Scope. The issuing distribution point extension can restrict a CRL to end-entity certificates, CA certificates or certain revocation reasons, or make it an indirect CRL; a delta CRL lists only changes since a base CRL number. All of this decides whether "not listed" actually means "not revoked", so the decoder states the scope plainly.
• Structure. Duplicate or negative serial numbers, critical extensions nobody understands (clients must then reject the whole list), a signature algorithm that differs between the outer and inner fields, version 1 lists with extensions, revocation dates in the future, and removeFromCRL outside a delta CRL.

Is my certificate on it?

There are two ways to ask. Paste certificates into the lookup field and each one is matched by issuer and serial number: revoked (with the date and reason), not listed, or not covered by this CRL at all — a different CA, or outside the CRL's scope, in which case the answer must come from another list. Or type a serial number into the search above the entries: hex in any case, with or without colons, as OpenSSL and browsers print it. The table shows every entry with its revocation date, reason and, where a key compromise happened earlier than the revocation, the invalidity date.

To find the right CRL for a certificate in the first place, look at its CRL distribution points in the certificate decoder and download the file from that address; this page does not download anything itself.

What runs where

Decoding, the signature check, the freshness and scope checks and the lookups all run in your browser. The page fetches nothing and sends nothing: not the CRL, not the certificates you add. Share links carry the CRL and the certificates in the URL fragment, which browsers do not send to servers — though most CRLs are too large for a link, and the Share button says so. Revocation through OCSP works differently: there the CA answers for one certificate at a time.