Revocation lists (CRL)

A CRL is an issuer-signed list of revoked certificates. This guide is for an operator publishing lists and an integrator using them locally. You need the issuing CA certificate, its SKI and access to the published endpoint. The client must maintain a current copy: offline operation still requires refreshing evidence.

VA role and per-CA configuration

The VA role stores configuration and metadata for the latest list published for a CA’s SKI. Generation requires a usable issuer key; do not assume an imported CA without a key has an available CRL.

The generator uses the key of the CA identified by the requested SKI. Do not interpret subject_key_id_signer as verified support for a different delegated CA: changing that field does not change the signer in this flow.

latest_crl contains version, validity start and end. Versions are kept as PEM in object storage at pki/va/crl/{subject_key_id}/{version}.crl; the public endpoint returns DER.

Periodic and automatic regeneration

The scheduled job requests another list when refresh_interval is reached or when the list approaches expiration within the configured watch period. This depends on working jobs, storage and signing; it does not guarantee renewal during a service failure.

With regenerate_on_revoke, the event handler requests a new CRL upon revocation or reactivation from CertificateHold to ACTIVE. This happens after the status change and has its own failure paths. Confirming revocation does not establish that the new CRL is already published or that all clients have downloaded it.

Compare CRL numbers and timestamps before and after a change. Monitor expired lists and generation failures; clients must apply policy when current evidence is unavailable.

CRL contents

Each entry contains serial number, revocation time and reason. The generator queries certificates in REVOKED state for the selected CA. A reactivated certificate disappears when the list is recalculated; an earlier downloaded copy retains its contents.

The list contains a critical Issuing Distribution Point (OID 2.5.29.28) with configured distribution URLs. Check that your client interprets this extension and that it matches the list’s scope. If rejected, investigate format and scope; ignoring a critical extension is not successful validation.

Public download endpoint

The VA service exposes GET /crl/{subject_key_id} without management authorization. Use the issuing CA’s SKI, not the end-entity certificate’s SKI or serial. First inspect the certificate’s CDP:

openssl x509 -in device.crt -noout -text

Replace the following URL with the CDP URL and review exposure in Deployment:

CRL_URL='http://pki.example.com/crl/REPLACE_WITH_ISSUER_SKI'

curl --fail --show-error --silent --max-time 15 \
  "$CRL_URL" -o ca.crl.der

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

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

openssl crl -in ca.crl.pem -noout -text
openssl crl -in ca.crl.pem -noout -verify -CAfile issuer.pem

You need OpenSSL 3.x and issuer.pem containing the direct issuer’s certificate. Require a valid signature, current timestamps and the expected issuer. For a root that issues directly:

openssl verify -CAfile roots.pem -CRLfile ca.crl.pem \
  -crl_check -purpose sslclient device.crt

roots.pem contains deliberately trusted roots. For intermediates, add -untrusted intermediates.pem before the device.crt argument. -crl_check checks the end-entity certificate’s revocation against the local list; it does not download other lists or establish the status of the whole chain. A complete chain check needs the corresponding CRLs and a policy requiring them.

The test should accept an allowed certificate absent from the list and reject it with certificate revoked after publishing and using the list containing its serial.

VA role management API

The following paths are relative to the VA service; confirm the public prefix in the Gateway. They are not the URLs of the public OCSP and CRL endpoints.

You need authentication and role read or update permissions. Consult your installation’s API reference and Access control. Read current configuration before updating and send the full object expected by the contract: the backend replaces crl_options; it does not merge omitted fields.

After a change, check saved configuration and the next list actually published. Updating the role alone does not establish regeneration or client acceptance.

From the interface

The CA view lets you inspect and download the available list. Compare version, issuer and timestamps with the copy downloaded from the public endpoint. Diagnose differences using PKI troubleshooting.

References

• RFC 5280: X.509 and CRL profile.
• OpenSSL: openssl-crl.
• OpenSSL: openssl-verify.