OpenSSL crl: Check Certificate Revocation Lists and Revoked Certificates

Overview

A TLS certificate can be:

• correctly signed;
• within its validity period;
• issued by a trusted CA;

and still no longer be trustworthy.

If the certificate’s private key has been compromised or the certificate was issued incorrectly, the certificate authority can revoke it before its normal expiration date.

One common way CAs publish that information is through a Certificate Revocation List, or CRL.

OpenSSL provides:

openssl crl

for inspecting and processing CRLs.

The command can:

• display revoked certificate serial numbers;
• show the CRL issuer;
• show when the CRL was last updated;
• show when the CRL expires;
• display the CRL number;
• calculate its issuer hash;
• calculate a fingerprint;
• verify the CRL’s digital signature;
• convert CRLs between DER and PEM;
• inspect CRL extensions;
• assist in building CRL-based certificate validation workflows.

The official OpenSSL crl documentation describes the command as a tool for processing CRLs in DER or PEM format.

This guide uses a practical system-administration scenario:

An administrator is troubleshooting an internal TLS certificate that suddenly fails validation. The issuing CA publishes a CRL, and we need to determine whether the certificate was revoked, whether the downloaded CRL is current, and whether the CRL itself is authentic.

We will use OpenSSL to:

1. find the certificate’s CRL Distribution Point;
2. download the CRL;
3. determine whether it is DER or PEM;
4. inspect the CRL;
5. check its lastUpdate and nextUpdate;
6. verify the CRL issuer;
7. verify the CRL’s digital signature;
8. find the certificate serial number;
9. search the CRL for that serial number;
10. validate the certificate with openssl verify -crl_check;
11. convert DER and PEM CRLs;
12. prepare CRLs for hashed CApath directories;
13. troubleshoot expired, invalid, and mismatched CRLs.

What is a Certificate Revocation List?

A Certificate Revocation List is a CA-signed list of certificates that have been revoked before their normal expiration dates.

Conceptually:

Certificate Authority
        |
        +---- Certificate 1001 → Valid
        |
        +---- Certificate 1002 → Revoked
        |
        +---- Certificate 1003 → Valid
        |
        +---- Publishes CRL
                    |
                    +---- Serial 1002

A CRL can contain:

• issuer identity;
• publication time;
• next scheduled update;
• CRL number;
• revoked certificate serial numbers;
• revocation timestamps;
• revocation reasons;
• CRL extensions;
• a digital signature from the issuing CA.

The CA signs the CRL so clients can determine whether the revocation information itself is authentic.

Why certificates are revoked

Certificates may be revoked for reasons such as:

• private-key compromise;
• CA compromise;
• affiliation change;
• certificate superseded;
• service decommissioned;
• privilege withdrawn;
• certificate hold.

For example, if a server’s private key is accidentally published, waiting for the certificate to expire naturally may be unacceptable.

The CA can revoke the certificate and publish its serial number in a new CRL.

OpenSSL crl versus openssl verify

These commands serve different purposes.

openssl crl

Use:

openssl crl

to inspect and process the CRL itself.

For example:

openssl crl \
  -in issuing-ca.crl \
  -text \
  -noout

openssl verify

Use:

openssl verify

to determine whether a certificate is valid according to trust and revocation rules.

For example:

openssl verify \
  -CAfile ca-chain.pem \
  -CRLfile issuing-ca.crl \
  -crl_check \
  server.crt

The typical workflow is:

openssl crl
     ↓
Inspect the revocation data
openssl verify
     ↓
Apply that revocation data to a certificate

For a broader chain-validation guide, see OpenSSL verify.

OpenSSL version compatibility

This article covers:

• OpenSSL 3.0;
• OpenSSL 3.1;
• OpenSSL 3.2;
• OpenSSL 3.3;
• OpenSSL 3.4;
• OpenSSL 3.5 LTS;
• OpenSSL 4.0.

Check the installed version:

openssl version

For detailed build information:

openssl version -a

The core CRL commands remain consistent:

openssl crl -in ca.crl -text -noout
openssl crl -in ca.crl -issuer -noout
openssl crl -in ca.crl -lastupdate -nextupdate -noout
openssl crl -in ca.crl -verify -CAfile ca.crt -noout
openssl crl -in ca.crl -outform DER -out ca.der.crl

OpenSSL 3.0

OpenSSL 3.0 supports the normal CRL inspection, conversion, hashing, fingerprint, and verification workflow.

It includes provider options such as:

-provider
-provider-path
-propquery

OpenSSL 3.3 and later

Starting with OpenSSL 3.3, a failed:

openssl crl -verify

returns exit code:

1

This is important for automation.

A script can reliably treat an invalid CRL signature as failure.

OpenSSL 3.5 LTS

OpenSSL 3.5 is the primary documentation target for this series.

It additionally documents:

-provparam

for provider parameters.

OpenSSL 4.0

The principal CRL workflow remains available in OpenSSL 4.0.

Scripts built around:

-text
-verify
-issuer
-lastupdate
-nextupdate
-crlnumber
-hash
-fingerprint

remain applicable.

Real-world scenario

Assume a server certificate:

app01.crt

is unexpectedly rejected by an application.

The first question is:

Has this certificate been revoked?

We need to determine:

1. which CA issued it;
2. where that CA publishes its CRL;
3. whether the CRL is current;
4. whether the CRL signature is valid;
5. whether the certificate’s serial number appears in it.

The relevant files will eventually be:

app01.crt
issuing-ca.crt
root-ca.crt
issuing-ca.crl

All names in this article are generic examples.

Step 1: Inspect the certificate

Run:

openssl x509 \
  -in app01.crt \
  -noout \
  -subject \
  -issuer \
  -serial \
  -dates

Example:

subject=CN=app01.example.internal
issuer=CN=Example Issuing CA
serial=4A18D27C102F

Record the serial number:

4A18D27C102F

The CRL records revoked certificates primarily by serial number.

Step 2: Find the CRL Distribution Point

Display the certificate:

openssl x509 \
  -in app01.crt \
  -noout \
  -text

Search for:

X509v3 CRL Distribution Points

On Linux:

openssl x509 \
  -in app01.crt \
  -noout \
  -text |
grep -A 5 "CRL Distribution Points"

Example:

X509v3 CRL Distribution Points:
    Full Name:
      URI:https://pki.example.net/crl/issuing-ca.crl

The CRL Distribution Point tells relying parties where the CA publishes revocation information.

Do not use a real internal URL in public documentation or screenshots.

Step 3: Download the CRL

Using curl:

curl \
  -fLO \
  https://pki.example.net/crl/issuing-ca.crl

Or explicitly specify the output filename:

curl \
  -fL \
  https://pki.example.net/crl/issuing-ca.crl \
  -o issuing-ca.crl

Check the downloaded file:

ls -lh issuing-ca.crl

Do not assume the file is PEM simply because its extension is:

.crl

Many CAs distribute CRLs as binary DER.

Step 4: Determine whether the CRL is DER or PEM

Check:

file issuing-ca.crl

A PEM CRL begins with:

-----BEGIN X509 CRL-----

Check:

head issuing-ca.crl

If the file appears binary, it is probably DER.

With OpenSSL 3.x, input format detection is generally flexible, but explicitly specifying the format is useful in documentation and troubleshooting.

For PEM:

openssl crl \
  -inform PEM \
  -in issuing-ca.crl \
  -noout \
  -issuer

For DER:

openssl crl \
  -inform DER \
  -in issuing-ca.crl \
  -noout \
  -issuer

Step 5: Display the CRL issuer

Run:

openssl crl \
  -in issuing-ca.crl \
  -noout \
  -issuer

Example:

issuer=CN=Example Issuing CA

Compare that with the certificate issuer:

openssl x509 \
  -in app01.crt \
  -noout \
  -issuer

These should correspond to the CA whose revocation information applies to the certificate.

A CRL from a different CA is not useful simply because it is cryptographically valid.

Step 6: Check CRL freshness

Run:

openssl crl \
  -in issuing-ca.crl \
  -noout \
  -lastupdate \
  -nextupdate

Example:

lastUpdate=Aug 20 05:00:00 2026 GMT
nextUpdate=Aug 27 05:00:00 2026 GMT

These fields are critical.

lastUpdate

This tells you when the CRL was issued.

nextUpdate

This tells relying parties when a newer CRL is expected.

If the current time is later than:

nextUpdate

the CRL should generally be considered stale for certificate-validation purposes.

A certificate may not appear revoked in an old CRL even though it was revoked after that CRL was published.

Step 7: Use ISO 8601 dates

OpenSSL supports:

-dateopt

for changing displayed date format.

For easier scripting:

openssl crl \
  -in issuing-ca.crl \
  -noout \
  -dateopt iso_8601 \
  -lastupdate \
  -nextupdate

Example output may be easier for machines and administrators to parse than RFC 822-style timestamps.

This is useful for:

• monitoring;
• cron jobs;
• log ingestion;
• alerting;
• configuration management.

Step 8: Display the CRL number

Run:

openssl crl \
  -in issuing-ca.crl \
  -noout \
  -crlnumber

Example:

crlNumber=0x1064

A CRL Number extension gives CRLs a monotonically increasing sequence value.

For example:

CRL 100
CRL 101
CRL 102

A newer CRL from the same issuer should normally have a newer number.

This can help detect:

• stale CRLs;
• rollback to an older file;
• failed CRL publication;
• replication problems.

Not every CRL necessarily contains a CRL Number extension, but modern CA deployments commonly use it.

Step 9: Display the entire CRL

Run:

openssl crl \
  -in issuing-ca.crl \
  -text \
  -noout

The output may contain:

Certificate Revocation List (CRL):
    Version
    Signature Algorithm
    Issuer
    Last Update
    Next Update
    CRL extensions
    Revoked Certificates
    Signature

Each revoked certificate may include:

Serial Number
Revocation Date
CRL Entry Extensions

For example:

Serial Number: 4A18D27C102F
    Revocation Date: Aug 19 14:15:00 2026 GMT
    CRL Reason Code:
        Key Compromise

This gives you substantially more information than merely knowing that a certificate appears in the list.

Step 10: Find a certificate serial number

Display the certificate serial:

openssl x509 \
  -in app01.crt \
  -noout \
  -serial

Example:

serial=4A18D27C102F

Search the CRL text:

openssl crl \
  -in issuing-ca.crl \
  -text \
  -noout |
grep -i -A 4 '4A18D27C102F'

If the serial appears, the certificate is listed as revoked.

If it does not appear, that does not by itself establish that the certificate is currently valid.

You must also confirm:

• the CRL is current;
• the CRL was issued by the correct CA;
• the CRL signature is valid;
• the certificate chain is valid.

Step 11: Verify the CRL signature

The CRL itself is digitally signed.

Verify it against the issuing CA:

openssl crl \
  -in issuing-ca.crl \
  -verify \
  -CAfile issuing-ca.crt \
  -noout

A successful result indicates that OpenSSL could validate the CRL signature using the supplied trust material.

This helps establish that:

the CRL was signed by the expected CA

and:

the CRL was not modified after signing

Do not skip this check when manually downloading CRLs for troubleshooting.

Step 12: Verify the CA certificate first

Before relying on:

issuing-ca.crt

verify its chain.

For example:

openssl verify \
  -CAfile root-ca.crt \
  issuing-ca.crt

Expected:

issuing-ca.crt: OK

If the CA certificate itself cannot be trusted, using it to validate a CRL does not solve the trust problem.

For more chain-validation examples, see OpenSSL verify.

Step 13: Verify a certificate against the CRL

Now use:

openssl verify \
  -CAfile root-ca.crt \
  -untrusted issuing-ca.crt \
  -CRLfile issuing-ca.crl \
  -crl_check \
  app01.crt

For a valid certificate:

app01.crt: OK

If revoked:

error 23 at 0 depth lookup: certificate revoked

This is preferable to manually searching CRL text when you want an authoritative OpenSSL validation result.

The verification engine checks the relevant certificate against the supplied CRL.

Step 14: Understand -crl_check versus -crl_check_all

Use:

-crl_check

to check the end-entity certificate.

For example:

openssl verify \
  -CAfile root-ca.crt \
  -untrusted issuing-ca.crt \
  -CRLfile issuing-ca.crl \
  -crl_check \
  app01.crt

Use:

-crl_check_all

to require CRL checks for every applicable certificate in the chain:

openssl verify \
  -CAfile root-ca.crt \
  -untrusted issuing-ca.crt \
  -CRLfile crl-bundle.pem \
  -crl_check_all \
  app01.crt

The second workflow requires CRLs for the relevant intermediate certificates as well.

If the required CRL cannot be found, verification can fail even though none of the certificates have actually been revoked.

Step 15: Convert a DER CRL to PEM

This is one of the most common openssl crl tasks.

Run:

openssl crl \
  -inform DER \
  -in issuing-ca.crl \
  -outform PEM \
  -out issuing-ca.pem.crl

Inspect:

head issuing-ca.pem.crl

Expected:

-----BEGIN X509 CRL-----

Check:

openssl crl \
  -in issuing-ca.pem.crl \
  -noout \
  -issuer \
  -lastupdate \
  -nextupdate

Your existing OpenSSL verify guide uses this same DER-to-PEM conversion when demonstrating certificate revocation checking.

Step 16: Convert a PEM CRL to DER

Run:

openssl crl \
  -in issuing-ca.pem.crl \
  -outform DER \
  -out issuing-ca.der.crl

The resulting file is binary.

Check:

file issuing-ca.der.crl

DER is commonly used for:

• CRL distribution over HTTP;
• Windows environments;
• network appliances;
• enterprise PKI applications.

PEM is often more convenient for:

• shell workflows;
• text-based configuration;
• troubleshooting.

The cryptographic content is the same; the external encoding differs.

Step 17: Calculate the CRL fingerprint

Run:

openssl crl \
  -in issuing-ca.crl \
  -noout \
  -fingerprint

The fingerprint can help compare two CRL files.

For example:

openssl crl \
  -in crl-from-server-a.pem \
  -noout \
  -fingerprint

and:

openssl crl \
  -in crl-from-server-b.pem \
  -noout \
  -fingerprint

If the fingerprints differ, the CRL files are not identical.

This is useful when troubleshooting:

• CDN publication;
• web-server replication;
• multiple CRL Distribution Points;
• load-balanced CA infrastructure.

Step 18: Calculate the CRL issuer hash

Run:

openssl crl \
  -in issuing-ca.crl \
  -noout \
  -hash

Example:

6d41c539

This hash is based on the CRL issuer name.

OpenSSL can use it to locate CRLs in a hashed certificate directory.

A CRL link uses a name similar to:

6d41c539.r0

The:

r

distinguishes CRLs from certificate hash links.

This ties directly into:

openssl rehash

See OpenSSL rehash for the complete hashed-directory workflow.

Step 19: Understand -hash_old

OpenSSL also provides:

openssl crl \
  -in issuing-ca.crl \
  -noout \
  -hash_old

This calculates the older issuer-name hash algorithm used before OpenSSL 1.0.0.

Because this MisterPKI series covers OpenSSL 3.0 and newer, most administrators do not need this option.

Use it only when interoperating with legacy software that explicitly requires old-style certificate-directory hashes.

Step 20: Put a CRL into a hashed CA directory

Assume:

/opt/example-app/trust

already contains trusted CA certificates.

Copy the CRL:

sudo cp \
  issuing-ca.pem.crl \
  /opt/example-app/trust/issuing-ca.crl

Then run:

sudo openssl rehash \
  -v \
  /opt/example-app/trust

You may see:

6d41c539.r0 -> issuing-ca.crl

Now OpenSSL can locate the CRL by issuer hash when the application uses that directory as a CApath.

For a complete explanation, see OpenSSL rehash: Create a Hashed CA Certificate Directory.

Step 21: Verify using CApath and CRLs

After rehashing:

openssl verify \
  -CApath /opt/example-app/trust \
  -crl_check \
  app01.crt

For this to work, the directory must contain:

• the required trust certificates;
• the appropriate CRL;
• correct hash links.

If the CRL is stale or missing, verification may fail.

Step 22: Display only revoked certificates

For small CRLs:

openssl crl \
  -in issuing-ca.crl \
  -text \
  -noout

is sufficient.

For a large CRL, filter:

openssl crl \
  -in issuing-ca.crl \
  -text \
  -noout |
grep -E 'Serial Number|Revocation Date'

Example:

Serial Number: 1004
    Revocation Date: Aug 14 12:00:00 2026 GMT
Serial Number: 1027
    Revocation Date: Aug 17 18:00:00 2026 GMT

If CRL Reason extensions exist, include more lines:

openssl crl \
  -in issuing-ca.crl \
  -text \
  -noout |
grep -A 5 'Serial Number'

Step 23: Search for a serial number safely in a script

Get the serial automatically:

serial="$(
  openssl x509 \
    -in app01.crt \
    -noout \
    -serial |
  cut -d= -f2
)"

Search:

if openssl crl \
  -in issuing-ca.crl \
  -text \
  -noout |
  grep -qi "$serial"
then
    echo "Certificate serial appears in CRL"
else
    echo "Certificate serial not found in CRL"
fi

This is useful for diagnostics, but for actual certificate-validation automation prefer:

openssl verify -crl_check

because the verification engine also considers issuer relationships and CRL validity.

Step 24: Generate a CRL with openssl ca

An important distinction:

openssl crl

is primarily for processing an existing CRL.

To generate one from an OpenSSL CA database, use:

openssl ca \
  -config openssl-ca.cnf \
  -gencrl \
  -out issuing-ca.crl

Then inspect it with:

openssl crl \
  -in issuing-ca.crl \
  -text \
  -noout

This gives a clean division of responsibilities:

openssl ca
     ↓
Generate / manage CRL data
openssl crl
     ↓
Inspect / convert / verify CRL
openssl verify
     ↓
Apply CRL during certificate validation

For the CA-side workflow, see OpenSSL ca.

Step 25: Revoke a certificate and publish a new CRL

With an OpenSSL CA, revoke:

openssl ca \
  -config openssl-ca.cnf \
  -revoke app01.crt \
  -crl_reason keyCompromise

Generate a fresh CRL:

openssl ca \
  -config openssl-ca.cnf \
  -gencrl \
  -out issuing-ca.crl

Inspect it:

openssl crl \
  -in issuing-ca.crl \
  -text \
  -noout

Then confirm:

openssl verify \
  -CAfile ca-chain.pem \
  -CRLfile issuing-ca.crl \
  -crl_check \
  app01.crt

The result should indicate that the certificate is revoked.

This demonstrates the full lifecycle:

Valid certificate
      ↓
Private key compromised
      ↓
CA revokes certificate
      ↓
CA database updated
      ↓
New CRL generated
      ↓
CRL published
      ↓
Client downloads CRL
      ↓
Certificate rejected

Step 26: Package a CRL with certificates in PKCS#7

OpenSSL also provides:

openssl crl2pkcs7

for creating a PKCS#7 structure containing certificates and optionally a CRL.

For example:

openssl crl2pkcs7 \
  -in issuing-ca.crl \
  -certfile issuing-ca.crt \
  -certfile root-ca.crt \
  -outform DER \
  -out ca-material.p7b

This is useful when an application expects PKCS#7/P7B packaging.

For the complete workflow, see OpenSSL crl2pkcs7.

Step 27: Test automation with -verify

For OpenSSL 3.3 and later:

if openssl crl \
  -in issuing-ca.crl \
  -verify \
  -CAfile issuing-ca.crt \
  -noout
then
    echo "CRL signature valid"
else
    echo "CRL signature invalid" >&2
    exit 1
fi

Since OpenSSL 3.3, verification failure returns status:

1

which makes this suitable for scripts.

If your automation must support OpenSSL 3.0 through 3.2, test the exact behavior on those versions rather than assuming the later exit-code semantics.

Step 28: Use -badsig for testing

OpenSSL provides:

-badsig

to intentionally corrupt a CRL signature before writing it.

For example:

openssl crl \
  -in issuing-ca.crl \
  -badsig \
  -out invalid-signature.crl

Then test verification:

openssl crl \
  -in invalid-signature.crl \
  -verify \
  -CAfile issuing-ca.crt \
  -noout

This should fail.

This feature is useful for:

• automated tests;
• monitoring validation;
• application interoperability testing;
• verifying that a system actually rejects invalid CRLs.

Do not confuse the resulting CRL with real production revocation data.

Use obvious filenames such as:

TEST-invalid-signature.crl

and keep test data away from production distribution points.

Step 29: Understand delta CRLs

A base CRL contains the main revocation list.

A delta CRL can contain changes since a previous base CRL.

Conceptually:

Base CRL
  |
  +---- Revoked A
  +---- Revoked B
Delta CRL
  |
  +---- Newly revoked C

OpenSSL provides:

-gendelta

for generating a comparison based on another CRL.

This is a specialized feature and should not be treated as a substitute for understanding your CA’s delta-CRL architecture.

For certificate verification, OpenSSL provides:

-use_deltas

through verification options.

Use delta CRLs only when the issuing PKI intentionally publishes and supports them.

Step 30: Understand CRL freshness versus certificate validity

Suppose:

Certificate expires:
September 30
CRL nextUpdate:
August 20

and today is August 25.

The certificate may still be within its normal validity window, but the CRL is stale.

You cannot safely conclude:

certificate is not revoked

from a CRL that is no longer current.

Certificate validity and revocation freshness are separate checks:

Not Before / Not After
        ↓
Is certificate time-valid?
CRL lastUpdate / nextUpdate
        ↓
Is revocation data current?

Both matter.

Step 31: CRL versus OCSP

CRLs are not the only revocation mechanism.

Another common protocol is:

OCSP

or Online Certificate Status Protocol.

CRL

The CA periodically publishes a list of revoked serial numbers.

Clients download the list.

OCSP

A client asks an OCSP responder about a particular certificate.

Conceptually:

CRL
"Give me the revocation list."
OCSP
"What is the status of certificate 1234?"

Which mechanism is used depends on:

• the CA;
• certificate extensions;
• application;
• operating system;
• browser behavior;
• PKI design.

OpenSSL provides:

openssl ocsp

for OCSP operations.

A certificate may contain both:

CRL Distribution Points

and:

Authority Information Access
    OCSP

Step 32: CRLs do not revoke by hostname

A CRL does not normally contain:

www.example.com

as its primary revocation identifier.

It contains certificate serial numbers.

That matters because a CA can issue multiple certificates containing the same hostname.

For example:

Certificate A
CN=app.example.internal
Serial=1001
Certificate B
CN=app.example.internal
Serial=1002

Revoking:

1001

does not automatically revoke:

1002

Always compare the exact certificate serial.

Step 33: Check the certificate and CRL issuers together

Certificate:

openssl x509 \
  -in app01.crt \
  -noout \
  -issuer

CRL:

openssl crl \
  -in issuing-ca.crl \
  -noout \
  -issuer

These values should correspond to the intended issuing CA.

If they do not, you may have downloaded:

• the wrong CRL;
• a CRL from another issuing CA;
• a root CA CRL instead of an intermediate CRL;
• an old CA hierarchy’s CRL.

Large PKIs often publish many CRLs.

Do not assume every CRL distributed under the same organizational domain applies to every certificate.

Step 34: Check Authority Key Identifier information

Display the CRL:

openssl crl \
  -in issuing-ca.crl \
  -text \
  -noout

Look for:

X509v3 Authority Key Identifier

Compare with the issuing CA certificate:

openssl x509 \
  -in issuing-ca.crt \
  -text \
  -noout

Look for:

X509v3 Subject Key Identifier

These extensions can help associate revocation data with the correct issuing authority, especially when CA names are reused.

Common OpenSSL CRL errors

Unable to load CRL

Try:

openssl crl \
  -in issuing-ca.crl \
  -noout \
  -issuer

If that fails, explicitly try DER:

openssl crl \
  -inform DER \
  -in issuing-ca.crl \
  -noout \
  -issuer

Possible causes include:

• wrong format;
• HTML error page downloaded instead of CRL;
• corrupted download;
• empty file;
• file is actually a certificate;
• file is actually PKCS#7.

Check:

file issuing-ca.crl

and:

head issuing-ca.crl

Downloaded CRL is actually HTML

This happens surprisingly often.

Check:

head issuing-ca.crl

You may see:

<html>

instead of CRL data.

Use:

curl -fL

so HTTP errors cause the download operation to fail:

curl \
  -fL \
  https://pki.example.net/crl/issuing-ca.crl \
  -o issuing-ca.crl

CRL signature verification failed

Confirm:

openssl crl \
  -in issuing-ca.crl \
  -noout \
  -issuer

Then inspect the CA:

openssl x509 \
  -in issuing-ca.crt \
  -noout \
  -subject

Possible causes include:

• wrong issuing CA certificate;
• damaged CRL;
• stale or mismatched CA hierarchy;
• indirect CRL architecture;
• alternate CRL-signing certificate.

Do not disable signature verification simply to make the process succeed.

unable to get certificate CRL

This can occur during:

openssl verify -crl_check

when OpenSSL cannot find a usable CRL for the certificate being checked.

Possible causes:

• CRL not provided;
• wrong CRL issuer;
• stale CRL;
• missing hash link in CApath;
• checking the entire chain without all required CRLs.

Inspect the target certificate’s CRL Distribution Points and verify that the correct CRL is available.

CRL has expired

Check:

openssl crl \
  -in issuing-ca.crl \
  -noout \
  -lastupdate \
  -nextupdate

Download the current CRL from the authoritative distribution point.

Do not extend or modify the CRL expiration yourself.

The CA must publish a newly signed CRL.

Certificate serial is not present but verification still fails

Revocation may not be the problem.

Check:

openssl verify \
  -show_chain \
  -CAfile root-ca.crt \
  -untrusted issuing-ca.crt \
  app01.crt

Possible problems include:

• expired certificate;
• incomplete chain;
• wrong trust anchor;
• hostname mismatch;
• unsupported purpose;
• policy failure;
• missing intermediate CA.

A CRL is only one component of certificate validation.

CRL number is missing

Not every CRL is required to contain a CRL Number extension.

If:

openssl crl \
  -in issuing-ca.crl \
  -noout \
  -crlnumber

does not show one, inspect the complete CRL:

openssl crl \
  -in issuing-ca.crl \
  -text \
  -noout

Use issuer, update times, signature, and authoritative distribution source to assess the CRL.

Important openssl crl options

For the complete option list, see the official OpenSSL 3.5 crl documentation.

Useful OpenSSL CRL commands

Display CRL details:

openssl crl \
  -in issuing-ca.crl \
  -text \
  -noout

Display issuer:

openssl crl \
  -in issuing-ca.crl \
  -issuer \
  -noout

Check update times:

openssl crl \
  -in issuing-ca.crl \
  -lastupdate \
  -nextupdate \
  -noout

Use ISO timestamps:

openssl crl \
  -in issuing-ca.crl \
  -dateopt iso_8601 \
  -lastupdate \
  -nextupdate \
  -noout

Display CRL number:

openssl crl \
  -in issuing-ca.crl \
  -crlnumber \
  -noout

Display fingerprint:

openssl crl \
  -in issuing-ca.crl \
  -fingerprint \
  -noout

Display issuer hash:

openssl crl \
  -in issuing-ca.crl \
  -hash \
  -noout

Verify CRL signature:

openssl crl \
  -in issuing-ca.crl \
  -verify \
  -CAfile issuing-ca.crt \
  -noout

Convert DER to PEM:

openssl crl \
  -inform DER \
  -in issuing-ca.der.crl \
  -outform PEM \
  -out issuing-ca.pem.crl

Convert PEM to DER:

openssl crl \
  -in issuing-ca.pem.crl \
  -outform DER \
  -out issuing-ca.der.crl

Check a certificate against the CRL:

openssl verify \
  -CAfile root-ca.crt \
  -untrusted issuing-ca.crt \
  -CRLfile issuing-ca.crl \
  -crl_check \
  app01.crt

Frequently asked questions

What does openssl crl do?

openssl crl processes Certificate Revocation Lists.

It can inspect, verify, fingerprint, hash, and convert CRLs between PEM and DER formats.

How do I view a CRL with OpenSSL?

Run:

openssl crl \
  -in ca.crl \
  -text \
  -noout

How do I check whether a CRL is expired?

Run:

openssl crl \
  -in ca.crl \
  -lastupdate \
  -nextupdate \
  -noout

If the current time is later than nextUpdate, obtain a newer CRL.

How do I find revoked certificate serial numbers?

Run:

openssl crl \
  -in ca.crl \
  -text \
  -noout

Look for:

Revoked Certificates

and:

Serial Number

How do I check whether one certificate is revoked?

Get the serial:

openssl x509 \
  -in certificate.crt \
  -serial \
  -noout

Then validate it using:

openssl verify \
  -CAfile ca-chain.pem \
  -CRLfile ca.crl \
  -crl_check \
  certificate.crt

How do I convert a CRL from DER to PEM?

Run:

openssl crl \
  -inform DER \
  -in ca.crl \
  -outform PEM \
  -out ca.pem.crl

How do I convert a CRL from PEM to DER?

Run:

openssl crl \
  -in ca.pem.crl \
  -outform DER \
  -out ca.der.crl

How do I verify a CRL signature?

Run:

openssl crl \
  -in ca.crl \
  -verify \
  -CAfile issuing-ca.crt \
  -noout

What does nextUpdate mean?

It indicates when the CA expects a newer CRL to be available.

A CRL beyond its nextUpdate time is stale for normal revocation checking.

What is a CRL number?

The CRL Number extension identifies the CRL in an increasing sequence published by the CA.

It can help distinguish older CRLs from newer ones.

Does openssl crl generate CRLs?

The command primarily processes existing CRLs.

For an OpenSSL CA, generate a CRL with:

openssl ca \
  -config openssl-ca.cnf \
  -gencrl \
  -out ca.crl

Then use openssl crl to inspect it.

What is the difference between crl and crl2pkcs7?

openssl crl processes a CRL.

openssl crl2pkcs7 packages certificates and optionally a CRL into a PKCS#7 structure.

Does OpenSSL crl work with OpenSSL 4.0?

Yes.

The primary CRL inspection, conversion, hash, fingerprint, and signature-verification functionality remains available in OpenSSL 4.0.

Practical certificate revocation workflow

Start with:

app01.crt

Find the certificate serial

openssl x509 \
  -in app01.crt \
  -serial \
  -issuer \
  -noout

Find the CRL Distribution Point

openssl x509 \
  -in app01.crt \
  -text \
  -noout |
grep -A 5 "CRL Distribution Points"

Download the CRL

curl \
  -fL \
  https://pki.example.net/crl/issuing-ca.crl \
  -o issuing-ca.crl

Inspect the CRL

openssl crl \
  -in issuing-ca.crl \
  -issuer \
  -lastupdate \
  -nextupdate \
  -crlnumber \
  -noout

Verify the CRL signature

openssl crl \
  -in issuing-ca.crl \
  -verify \
  -CAfile issuing-ca.crt \
  -noout

Check the certificate

openssl verify \
  -CAfile root-ca.crt \
  -untrusted issuing-ca.crt \
  -CRLfile issuing-ca.crl \
  -crl_check \
  app01.crt

The overall workflow is:

Certificate
     ↓
Find issuer
     ↓
Find CRL Distribution Point
     ↓
Download CRL
     ↓
Check issuer
     ↓
Check freshness
     ↓
Verify CRL signature
     ↓
Check certificate against CRL

Security considerations

CRL checking is a security control, so avoid shortcuts that defeat the purpose.

Do not:

• trust an arbitrary CRL solely because it downloaded successfully;
• use a stale CRL indefinitely;
• ignore an invalid CRL signature;
• assume a certificate is valid merely because its serial is not in one old CRL;
• use a CRL from the wrong issuing CA;
• disable revocation checks simply because an application fails.

When validating manually, confirm:

Correct issuer
Current lastUpdate/nextUpdate
Valid CRL signature
Correct certificate serial
Valid certificate chain

Privacy considerations

CRLs are generally public PKI objects, but they may still reveal information about an environment.

Output can expose:

• CA names;
• revoked certificate serial numbers;
• revocation dates;
• private OIDs;
• internal PKI hierarchy;
• internal distribution URLs.

Certificate output may additionally expose:

• hostnames;
• email addresses;
• organization names.

Before publishing terminal output or screenshots, replace internal values with generic examples.

This article uses:

app01.example.internal
pki.example.net
Example Issuing CA
Example Root CA

rather than real infrastructure.

Related OpenSSL guides

• Browse the complete OpenSSL Commands Guide.
• Validate certificates and revocation with OpenSSL verify.
• Generate and revoke certificates with OpenSSL ca.
• Prepare hashed CA and CRL directories with OpenSSL rehash.
• Package CRLs and certificates with OpenSSL crl2pkcs7.
• Inspect PKCS#7 bundles with the PKCS#7 guide.
• Decode a PEM CRL using the MisterPKI SSL Tools.
• Inspect low-level certificate and CRL encoding with OpenSSL asn1parse.

External references

• OpenSSL 3.5 crl documentation
• OpenSSL 3.0 crl documentation
• OpenSSL 4.0 crl documentation
• OpenSSL verify documentation
• OpenSSL verification options
• OpenSSL ca documentation
• OpenSSL crl2pkcs7 documentation

Conclusion

The openssl crl command is one of the most useful OpenSSL tools for troubleshooting certificate revocation.

The commands worth remembering are:

openssl crl -in ca.crl -text -noout

to inspect the CRL;

openssl crl \
  -in ca.crl \
  -lastupdate \
  -nextupdate \
  -noout

to check whether it is current;

openssl crl \
  -in ca.crl \
  -verify \
  -CAfile issuing-ca.crt \
  -noout

to verify its signature;

and:

openssl verify \
  -CAfile ca-chain.pem \
  -CRLfile ca.crl \
  -crl_check \
  certificate.crt

to determine whether a certificate passes revocation validation.

The practical sequence is:

Find CRL
   ↓
Inspect issuer
   ↓
Check freshness
   ↓
Verify signature
   ↓
Find certificate serial
   ↓
Perform CRL-aware certificate validation

Remember that openssl crl handles the CRL itself, while openssl verify applies that revocation information to certificate validation.

If you operate an OpenSSL CA, use:

openssl ca -gencrl

to generate the CRL and:

openssl crl

to inspect, convert, and verify the result.

Used together, openssl ca, openssl crl, and openssl verify provide a complete lab-scale workflow for certificate issuance, revocation, publication, and validation.