What is a CRL file?
A CRL (Certificate Revocation List) file is a blacklist of X.509 digital certificates that a certificate authority (CA) revokes prior to their assigned revocation date. It contains information about the issue and the revocation date that lets the security administrators to block affected digital certificates. CRL doesn’t include expired certificates as its main purpose is to notify about the untrusted and invalid certificates.
Applications that can open CRL files include OpenSSL, Microsoft IIS Server, and Citrix NetScaler.
CRL File Format - More Information
CRL files contain information in the X.509 standard which also defines its semantics for sharing public key information. Other information contained inside a CRL file may include the time limit for which the certificates have been revoked, reason for the revocation, serial number of revoked certificate and timestamp.
Top Reasons for Certificates Getting Added to CRL
There could be several reasons for getting your website’s certificate revoked and being added to CRL. Some of them could be;
- Your certificate’s private key has been compromised
- Your certificate is not valid or mis-issued by the CA
- Organizational details associated with the certificate are changed and CA issues new certificate
- Any other unavoidable reason for which the certificate has been revoked
CRL vs. OCSP: The War Over Certificate Revocation
No discussion of CRL files would be complete without addressing the elephant in the room: CRL is becoming legacy technology. The Online Certificate Status Protocol (OCSP), introduced in 1999, was designed to address CRL’s fundamental limitations :
Feature CRL OCSP
| Feature | CRL | OCSP |
|---|---|---|
| Data delivery | Pull (client downloads entire list) | Pull (client queries specific certificate) |
| Data size | Entire list (potentially huge) | Single response (tiny) |
| Real-time status | Based on last update timestamp | Near real-time query |
| Privacy | No information disclosed about client | CA learns which certificates client is validating |
| Network load | Spikes on update schedules | Distributed, consistent load |
CRL’s biggest weakness is its “all or nothing” approach. To check one certificate, a client must download the complete revocation list for that entire CA—potentially thousands or millions of entries .
OCSP solves this by allowing clients to ask the CA directly: “Is this specific certificate still valid?” The response is a tiny, signed message indicating “good,” “revoked,” or “unknown” .
So why do CRL files still exist? Several reasons:
- OCSP has its own problems, particularly privacy concerns (the CA learns exactly which certificates you’re validating) and the “OCSP must-staple” adoption challenges
- Some environments still rely on CRLs, particularly air-gapped networks, legacy enterprise PKI deployments, and certain government/military systems
- CRLs serve as a backup mechanism when OCSP responders are unavailable
- Not all clients support OCSP, especially older or embedded systems
The current state of the industry is hybrid: most modern systems prefer OCSP but maintain CRL support as a fallback .
Key Characteristics of the CRDOWNLOAD File Format
| Characteristic | Description |
|---|---|
| Extension | .crl (primary), also .pem for PEM-encoded versions |
| Developer | ITU-T (X.509 standard) |
| Category | TSecurity / PKI |
| Container For | Revoked certificate serial numbers with metadata |
| Based On | ASN.1 (Abstract Syntax Notation One) |
| Standard | RFC 5280 (formerly RFC 2459, RFC 1422) |
The Future of CRL Files
The trajectory is clear: CRL files are gradually being supplanted by OCSP and, more recently, by OCSP stapling and emerging technologies like CRLite (used by Mozilla Firefox) that compress revocation information into Bloom filters for efficient distribution. However, reports of CRL’s death are greatly exaggerated. The format persists because:
- It’s universally understood — Every PKI-enabled application can handle CRLs
- It’s offline-friendly — No dependency on real-time responder availability
- It’s auditable — The complete revocation history is contained in a single, signed file
- It’s simple — No request/response protocol complexity
For the foreseeable future, CRL files will remain a critical part of the certificate ecosystem—even if their role shifts from primary revocation mechanism to trusted backup and audit trail.
FAQ
Q1: Can I open a CRL file in a normal text editor?
A: Only if it’s PEM-encoded. PEM files show readable header/footer lines with Base64 data in between. DER-encoded CRL files are binary and will appear as gibberish in text editors.
Q2: Are CRL files dangerous or potentially malicious?
A: No. CRL files are signed data structures, not executable code. They cannot infect your computer or run programs. However, as with any file, you should only download CRLs from trusted CAs.
Q3: Why does my browser never seem to download CRL files?
A: Modern browsers either use OCSP instead of CRLs, or they rely on the operating system’s certificate store which handles CRL downloads invisibly in the background.
Q4: What’s the difference between a CRL and an ARL?
A: ARL (Authority Revocation List) is a specialized CRL used for revoking CA certificates rather than end-entity certificates. ARL functionality is now typically integrated into standard CRLs or handled through trusted root store updates.
Q5: How long are CRL files valid for?
A: It varies by CA policy. Public CAs typically issue CRLs valid for 7 days. Enterprise CAs might use 24-hour validity. The exact expiration is always specified in the Next Update field inside the CRL file itself.
