Skip to content

CRLs Revocation

Certificate Revocation with CRLs

Certificate Revocation Lists (CRLs) are a foundational mechanism in Public Key Infrastructure (PKI) for managing revoked certificates. A CRL is a signed list of certificate serial numbers that have been revoked by the Certificate Authority (CA) before their expiration date. CRLs enable clients and systems to verify whether a certificate is still valid, ensuring secure communication in environments where certificate lifecycles are dynamic (e.g., employee departures, compromised keys, or policy changes).

Generating a Certificate Revocation List (CRL)

A CRL is generated by the CA and signed using its private key. The process involves:

  1. Collecting revoked certificates: Track certificates marked for revocation (e.g., via manual intervention, automated tools, or policy triggers).
  2. Creating the CRL structure: Include revoked certificate serial numbers, revocation dates, and CA-specific extensions.
  3. Signing the CRL: Use the CA’s private key to sign the CRL, ensuring its authenticity and integrity.

Example: Generating a CRL with OpenSSL

# Generate a CRL using OpenSSL
openssl crl -in revoked_certs.pem -out revoked_certs.crl -signkey ca_private_key.pem -CA ca_certificate.pem
This command creates a CRL file (revoked_certs.crl) signed by the CA’s private key (ca_private_key.pem) and based on revoked certificate data (revoked_certs.pem).

Distributing CRLs

CRLs must be distributed to all systems that rely on them. Common distribution methods include:

  • HTTP/HTTPS endpoints: Host CRLs on a web server with URLs specified in the certificate’s CRL Distribution Points extension.
  • LDAP directories: Store CRLs in an LDAP server for centralized access.
  • DNS: Use DNS records (e.g., CRL TXT records) to point to CRL locations.
  • Automated tools: Integrate CRLs with certificate management platforms (e.g., HashiCorp Vault, Keycloak) for real-time updates.

Diagram: CRL Distribution Workflow

[CA] --> [CRL Generation] --> [Distribution Points (HTTP, LDAP, DNS)] --> [Clients/Systems]

Validating CRLs

Clients validate CRLs by checking their validity period, signature, and revocation status of a certificate. Key steps include:

  1. Fetching the CRL: Retrieve the CRL from its distribution point.
  2. Verifying the signature: Ensure the CRL is signed by a trusted CA using its public key.
  3. Checking the revocation date: Confirm the certificate’s serial number is listed in the CRL and the revocation date is within the current time window.

Example: Verifying a Certificate Against a CRL with OpenSSL

# Check if a certificate is revoked using a CRL
openssl crl -in revoked_certs.crl -noout -revoked -serial < certificate_serial_number
This command checks if a certificate with the specified serial number is listed in the CRL.

Managing CRLs in Practice

  • Frequency of updates: CRLs should be updated regularly (e.g., hourly or daily) to reflect revoked certificates. The nextUpdate field in the CRL specifies the next update time.
  • Caching and expiration: Clients may cache CRLs to reduce network load, but cached CRLs must be validated against the current date to avoid using outdated data.
  • Integration with PKI tools: Tools like Keycloak or HashiCorp Vault can automate CRL generation, distribution, and validation workflows.

Key takeaways

  • CRLs are essential for revoking certificates in PKI, ensuring revoked certificates are no longer trusted.
  • Generation involves collecting revoked certificates, structuring the list, and signing it with the CA’s private key.
  • Distribution relies on HTTP, LDAP, DNS, or automated tools to ensure clients can access the latest CRL.
  • Validation requires checking the CRL’s signature, validity period, and the certificate’s serial number against the revoked list.
  • Management involves regular updates, caching strategies, and integration with PKI tools to maintain security and efficiency.