How curl Handles Certificate Revocation Lists

This article explains how the curl command-line tool handles Certificate Revocation Lists (CRLs) to verify the validity of SSL/TLS certificates. While curl does not automatically download CRLs during a handshake, it possesses native support for enforcing revocation checks when provided with a local CRL file, relying on its underlying SSL/TLS library to perform the validation.

Default curl Behavior

By default, curl performs standard SSL/TLS verification. It checks if the server’s certificate is expired, matches the requested hostname, and is signed by a trusted Certificate Authority (CA) found in the local CA bundle.

However, curl does not automatically fetch or check CRLs or use Online Certificate Status Protocol (OCSP) queries by default. If a certificate has been revoked by a CA before its natural expiration date, curl will still trust it unless explicitly instructed to perform a revocation check.

Native CRL Verification using --crlfile

To enforce CRL verification, curl provides a native command-line option: --crlfile.

When you use this option, you must manually provide a path to a PEM-formatted CRL file. curl passes this file directly to the underlying SSL/TLS backend (such as OpenSSL, GnuTLS, or mbedTLS) to validate the target server’s certificate.

Command Syntax

To check a server’s certificate against a local CRL file, use the following syntax:

curl --crlfile /path/to/revoked_certs.crl https://example.com

How the Verification Process Works

1. CRL Loading: curl reads the local CRL file specified by the user.
2. Handshake Initiation: curl initiates the TLS handshake with the destination server.
3. Serial Number Comparison: The underlying TLS library extracts the serial number from the server’s certificate (and intermediate certificates, if applicable).
4. Revocation Check: The library compares these serial numbers against the revoked serial numbers listed inside the PEM-formatted CRL file.
5. Connection Verdict:
   • If the certificate’s serial number is not in the CRL, the connection succeeds.
   • If the certificate’s serial number is listed in the CRL, the TLS handshake fails immediately.

Handling Verification Failures

If curl detects a revoked certificate using the provided CRL file, it terminates the connection and returns a specific exit code to ensure security:

• Error Message: curl: (60) SSL certificate problem: CA certificate is invalid or not trusted (or a similar TLS-backend-specific revocation error).
• Exit Code: 60 (CURLE_PEER_FAILED_VERIFICATION), indicating that the peer’s certificate could not be verified.

Important Limitations

When using curl with CRLs, keep the following native limitations in mind:

• No Automatic Updates: curl cannot download or update the CRL file automatically from the CA’s CRL Distribution Point (CDP). System administrators must write custom scripts (e.g., using wget or curl itself) to regularly fetch updated CRLs from the CA and save them locally.

• PEM Format Requirement: The CRL file supplied to --crlfile must be in PEM format. If the CA provides the CRL in DER format, it must be converted using a tool like OpenSSL before curl can use it:

  openssl crl -inform DER -in input.crl -outform PEM -out revoked_certs.crl

• TLS Backend Dependency: The exact behavior of the CRL check can vary slightly depending on the SSL/TLS library curl was compiled with (e.g., OpenSSL vs. Secure Transport on macOS).