Inspect and Verify Certificate Revocation Lists with OpenSSL

You will finish with a repeatable way to inspect a certificate revocation list (CRL), convert it between PEM and DER, and verify that its signature matches the issuing certificate. These are read and conversion operations: they do not revoke a certificate or create a CRL.

This guide uses the OpenSSL 3 command syntax. The installed manpage on this machine is for OpenSSL 3.0.13, while the executable currently on PATH reports OpenSSL 3.6.1. The core options below are present in both. Allow about ten minutes if you already have a CRL and its issuer certificate. No root access is needed unless the files are in a protected directory.

Checkpoint: identify the input

1. Check the executable and its option summary before touching a file.

   openssl version
   openssl crl -help

The openssl crl subcommand processes CRLs in PEM or DER format. PEM is the text-wrapped form, usually recognisable by -----BEGIN X509 CRL-----. DER is the binary encoding. The input format is unspecified by default, so use -inform PEM or -inform DER when you want a command that documents the expected format instead of relying on detection.

Keep the issuer certificate available if you intend to verify the signature. A CRL's signature proves that the issuer signed that CRL; it does not, by itself, prove that the CRL is current or that your application will use it.

Checkpoint: read a CRL without rewriting it

1. Print the human-readable fields from a CRL and suppress the encoded copy.

   openssl crl \
     -in /path/to/crl.pem \
     -inform PEM \
     -text \
     -noout

Look for the issuer, Last Update, Next Update, the CRL number and any revoked certificate entries. An empty revoked-certificate section is valid: it means the CRL currently lists no revoked certificates, not that the CRL is absent.

For a quick check, ask for only the fields you need. These options write concise values and can be combined:

openssl crl -in /path/to/crl.pem -issuer -lastupdate -nextupdate
openssl crl -in /path/to/crl.pem -crlnumber -fingerprint
openssl crl -in /path/to/crl.pem -hash -hash_old

The issuer-name hash is useful when investigating a hashed CRL directory. -hash_old uses the older algorithm retained for compatibility with OpenSSL versions before 1.0.0. Do not mistake either value for a security fingerprint.

Convert PEM and DER deliberately

1. Convert a PEM CRL to DER, writing to a new output path.

   openssl crl \
     -in /path/to/crl.pem \
     -inform PEM \
     -outform DER \
     -out /path/to/crl.der

2. Convert it back when a consumer requires PEM.

   openssl crl \
     -in /path/to/crl.der \
     -inform DER \
     -outform PEM \
     -out /path/to/crl-roundtrip.pem

The default output format is PEM, and output goes to standard output when -out is omitted. That default is convenient for inspection but easy to miss in a script. Name the output explicitly, and use a new filename until you have checked the result. OpenSSL will write to an existing output path, so a typo can replace useful evidence or a live input file.

Confirm the converted file parses before handing it to another program:

openssl crl -in /path/to/crl.der -inform DER -text -noout
openssl crl -in /path/to/crl-roundtrip.pem -inform PEM -noout

Verify the CRL signature

1. Verify the CRL with the issuer certificate or a trust source you have chosen.

   openssl crl \
     -in /path/to/crl.pem \
     -inform PEM \
     -noout \
     -verify \
     -CAfile /path/to/issuer-ca.pem

A successful run ends with verify OK and exit status zero. Check the status in a shell script rather than matching the text:

if openssl crl -in /path/to/crl.pem -noout -verify -CAfile /path/to/issuer-ca.pem; then
  printf '%s\n' 'CRL signature verified'
else
  printf '%s\n' 'CRL signature verification failed' >&2
  exit 1
fi

Since OpenSSL 3.3, the official documentation records that -verify exits with status 1 when verification fails. That makes the status check useful for current OpenSSL 3 installations, including the 3.6.1 executable checked for this guide.

You can use -CApath for a directory of trusted certificates or -CAstore for a store URI. Supplying any of these trust options implicitly enables verification. Be precise about the trust material: pointing at an unrelated system bundle may produce a failure that says more about your chosen trust source than about the CRL.

Dates are a separate check

Signature verification is not freshness verification. Compare the displayed Last Update and Next Update values with the time at which your service will use the CRL. The display format can be selected with -dateopt rfc_822 or -dateopt iso_8601; the default is RFC 822-style output.

openssl crl -in /path/to/crl.pem -lastupdate -nextupdate -dateopt iso_8601

Do not silently treat an expired CRL as current. If a service is failing because of a stale CRL, the recovery is to obtain and install the correct newer CRL through that service's documented process. This command only inspects the file.

Useful diagnostics and safe boundaries

• If parsing fails, make the encoding explicit with -inform PEM or -inform DER, then check that you have a CRL rather than a certificate. The -text option is for display, not repair.

• If verification fails, confirm the issuer certificate, the CRL issuer name and the selected -CAfile, -CApath or -CAstore. Do not weaken the check by removing trusted input until you understand the failure.

• -badsig deliberately corrupts the signature before writing the CRL. It is a test fixture option only. Never use it with a production path, and write its output to an isolated temporary file.

• -gendelta compares the main CRL with another CRL. Treat the comparison as diagnostic output, not as a replacement CRL, and keep the original files unchanged.

• The command does not create a CRL. OpenSSL's own documentation points to the CA workflow for CRL generation; use the CA process that owns the issuer key and its audit trail.

Done means

• The CRL parses with its declared PEM or DER input format.

• The issuer, CRL number and update dates have been checked.

• Signature verification returns exit status zero with the intended issuer trust material.

• Any converted file is written to a separate path and parsed successfully.