Embedded CRL Trust: A Practical Guide

TL;DR

Embedded Certificate Revocation Lists (CRLs) can be trusted if correctly implemented and maintained. However, they have limitations regarding update frequency. This guide explains how to verify an embedded CRL’s validity and the risks involved.

1. Understanding Embedded CRLs

An embedded CRL is a list of revoked certificates included directly within the application or device itself. Unlike checking against a publicly accessible CRL server, the revocation status is determined locally. This can be useful in environments with limited or no internet connectivity.

2. Verifying the CRL Signature

The most crucial step is verifying that the embedded CRL has been signed by a trusted Certificate Authority (CA). If the signature is invalid, the CRL cannot be trusted.

1. Obtain the CA certificate: You’ll need the public key of the CA that signed the CRL. This might be provided with the application or available from the CA’s website.
2. Use a tool to verify: OpenSSL is commonly used for this purpose. The command will vary depending on your operating system and OpenSSL version, but generally looks like this:

   openssl verify -CAfile ca_certificate.pem crl.pem

   Replace ca_certificate.pem with the path to your CA certificate file and crl.pem with the path to your embedded CRL file.

3. Check the output: A successful verification will display “OK”. Any errors indicate a problem with the signature or the CA certificate.

3. Checking the CRL Validity Period

CRLs have a validity period (This valid from… until…). Ensure that the current date and time fall within this range. An expired CRL is considered invalid.

You can view the CRL’s details using OpenSSL:

openssl crl -in crl.pem -text

Look for the Validity section in the output to confirm the dates.

4. Examining Revoked Certificates

Inspect the list of revoked certificates within the CRL. Confirm that any certificates you expect to be revoked are actually present on the list.

1. Serial Number: Each certificate has a unique serial number.
2. Revocation Date: The date when the certificate was revoked.

5. Update Frequency – A Critical Limitation

Embedded CRLs are static. If a certificate is revoked after the CRL was created, the application won’t be aware of the revocation until the CRL is updated.

1. Regular Updates: If possible, implement a mechanism to update the embedded CRL periodically (e.g., during software updates).
2. Short Validity Periods: Use relatively short validity periods for the CRL itself to minimize the risk of using outdated information.

6. Risks and Considerations

• CRL Size: Large CRLs can increase application size and memory usage.
• Maintenance Overhead: Updating embedded CRLs requires careful planning and execution.
• Offline Revocation: If the application cannot access any revocation information (even an embedded CRL), it must assume all certificates are valid, which is a security risk.

7. Alternatives

Consider these alternatives if frequent updates or online validation are required:

• OCSP Stapling: The server provides the revocation status along with the certificate.
• Online CRL Checking: Regularly check against a publicly accessible CRL server (requires internet connectivity).