August 24, 2026
A digital certificate revocation list check tells you whether a certificate authority (CA) has revoked a certificate before its scheduled expiration. You can perform this check by downloading the CRL from the distribution point listed in the certificate, searching it for the certificate's serial number, or by using OpenSSL's verify -crl_check command. Browsers and operating systems handle this automatically during TLS handshakes, but anyone managing a public key infrastructure (PKI) or validating document-signing certificates should understand the manual steps. This guide explains what a CRL is, why revocation checking matters, how to run a check with OpenSSL and other tools, and how CRL compares to OCSP — so you can decide which method fits your workflow. Always confirm specifics against the latest RFC 5280, CA policy, and vendor docs before relying on any check in production.
What Is a Certificate Revocation List (CRL)?
A certificate revocation list (CRL) is a signed, time-stamped document that a CA publishes to announce which digital certificates it has revoked before their expiration dates. Defined in RFC 5280, a CRL contains the issuer's name, the date the list was generated ("this update"), the date the next list is expected ("next update"), and a list of revoked certificate serial numbers — each paired with a revocation date and an optional reason code such as key compromise, CA compromise, or cessation of operation.
CAs revoke certificates for several reasons: the private key has been compromised, the certificate was issued in error, the subscriber has ceased operations, or the certificate is being superseded by a new one. Without a way to learn about these revocations, a relying party would continue to trust a certificate until it expires — even though the CA has already declared it untrustworthy.
A few practical details are worth noting:
- A base CRL lists every revoked certificate the CA knows about. A delta CRL lists only the changes since the last base CRL, which reduces bandwidth and parsing overhead.
- CRLs are signed by the issuing CA, so their integrity can be verified independently.
- Clients typically cache a CRL until its "next update" time, then download a fresh copy.
CRLs are one half of PKI's revocation story; OCSP provides the other half. Both answer the same question: is this certificate still trustworthy right now? For a broader overview of the entities that issue certificates and publish CRLs, see our certificate authority list for browsers and e-signatures.
Why You Need to Check Certificate Revocation Status
Checking revocation status is the difference between trusting a certificate because it looks valid and trusting it because it actually is valid. A certificate can pass a basic chain-of-trust check — correct issuer, valid dates, proper signature — and still be revoked. If you skip the revocation check, you are effectively treating every unexpired certificate as good, which defeats the purpose of having a revocation mechanism at all.
The most common scenarios where revocation checking matters include:
- Key compromise. If an attacker obtains a private key, the CA revokes the corresponding certificate so that relying parties stop accepting it. Without a revocation check, you would continue to trust signatures made with the stolen key.
- CA-issued-in-error. A CA may discover that it issued a certificate to the wrong entity or with incorrect attributes. Revocation is how it retroactively withdraws that certificate.
- Operational cessation. When a company shuts down or a domain changes hands, certificates tied to the old entity should be revoked so they cannot be reused.
- Document and e-signature validation. A digitally signed PDF carries an embedded certificate. If that certificate was revoked before signing (or between signing and verification), the signature's trustworthiness changes. If you want to dig deeper into the broader validation workflow, read our guide on how to verify a digital signature for business.
One subtlety: a revoked certificate is not the same as an expired one. Expiration is automatic and date-based; revocation is a deliberate CA action. That is why checking expiration alone is not enough. For the lifecycle context, see our article on whether digital certificates expire.
How to Check a Certificate Against the CRL
The exact steps depend on your tooling, but the workflow is consistent: find the CRL distribution point (CDP) in the certificate, download the CRL, and search for the certificate's serial number.
Step 1: Find the CRL distribution point. Every certificate that supports CRL checking carries a CRL Distribution Points extension with one or more URLs. Extract it with OpenSSL:
```
openssl x509 -in certificate.pem -noout -text | grep -A 4 "CRL Distribution"
```
Step 2: Download the CRL. Use curl or wget to fetch the CRL from the URL you found. CRLs are commonly distributed in DER format:
```
curl -o crl.der http://crl.example.com/intermediate.crl
```
Step 3: View the CRL contents. Convert and inspect the CRL to see its issuer, update times, and revoked serial numbers:
```
openssl crl -in crl.der -inform DER -text -noout
```
Step 4: Verify the certificate against the CRL. Combine the CA certificate and the CRL into a single file, then run OpenSSL's verify command with the -crl_check flag:
```
cat ca.crt crl.pem > ca-crl.pem
openssl verify -crl_check -CAfile ca-crl.pem certificate.pem
```
If the certificate's serial number appears in the CRL, OpenSSL reports a revocation error. If the CRL is expired (past its "next update" time) or unreachable, the check fails — which is the safe default.
Browser and OS-level checks. Mainstream browsers perform revocation checking automatically during TLS, though many now rely on OCSP or proprietary update mechanisms rather than downloading full CRLs. On Windows, certutil -dump crl.crl displays CRL contents, and double-clicking a .crl file opens the built-in viewer. If you want to verify a certificate before trusting it in a browser context, see our guide on how to check a digital certificate.
CRL vs OCSP: Choosing a Revocation Check Method
CRL and OCSP (Online Certificate Status Protocol, RFC 6960) both answer "is this certificate revoked?" CRL is a pull-based batch model: the client downloads a list and searches it locally. OCSP is a query-based real-time model: the client asks a responder for one certificate's status and gets back good, revoked, or unknown.
Most modern browsers favor OCSP (or OCSP stapling) for real-time web checks, while enterprise PKI teams often rely on CRL for internal CA deployments where network access to an OCSP responder is not guaranteed. The two are complementary, not mutually exclusive — many clients use both. If you are troubleshooting a signature that fails verification, the revocation method is one of the first things to check; our article on why a digital signature is invalid walks through the common causes.
For long-term signature validation — where you need to prove a signature was valid at the time of signing, years later — revocation data must be archived alongside the signature. Our guide on how to ensure long-term validation of digital signatures covers the LTV checklist for that scenario.
Nota Sign: When Your Signing Platform Tracks Certificate Status
A manual CRL or OCSP check answers one question at a time. In production signing, you want a platform that folds certificate-status awareness into the signing event, so the audit trail captures the certificate's standing. Nota Sign — FaDaDa's global e-signature platform — is built around that idea: every signed document carries a tamper-evident record tied to the certificate's validity.
Its market record is public — IDC's China e-signature rankings have put Nota Sign at number one for consecutive years. Since revocation and data-residency obligations vary by CA policy and jurisdiction, confirm specifics against your own requirements first. Plans price the workflow, not the people, so a growing signing volume won't inflate the bill. Ask Nota Sign to walk you through a production CRL/OCSP check — contact the Nota Sign team.
