What is a CRL?
Certificates carry an expiry date, but sometimes one must stop being trusted sooner: its private key leaked, the employee who held it left, or the server it identified was retired. The issuing CA then revokes the certificate and adds its serial number to a certificate revocation list. The CA signs the list so clients can be sure it is genuine, and publishes it at a URL named in each certificate's CRL distribution point (CDP) extension. A client checking a certificate downloads the list and looks for that certificate's serial number.
What a CRL contains
A CRL from an internal issuing CA, viewed with openssl crl -in issuing.crl -noout -text, looks like this (trimmed):
Issuer: O=Example Corp, CN=Example Corp Issuing CA 01
Last Update: Oct 23 14:20:52 2026 GMT
Next Update: Oct 30 14:20:52 2026 GMT
Serial Number: 614C79A4E38DD04767DCE86B6095686D649D0BBD
Revocation Date: Oct 23 14:20:52 2026 GMT
X509v3 CRL Reason Code: Key Compromise
Each entry records a serial number, a revocation date and usually a reason code. The standard reasons in RFC 5280 include key compromise, CA compromise, affiliation changed, superseded, cessation of operation and certificate hold. The Next Update field says when a fresh list will appear, and clients may cache the current one until then. A revoked certificate stays on the list at least until its original expiry date passes.
Certificate holds, delta CRLs and offline roots
Revocation is permanent, with one exception. A certificate hold is a temporary suspension, for example while a missing smart card is found, and the CA can later release it. Publicly trusted TLS CAs are not allowed to use holds. To keep downloads small, some CAs also publish delta CRLs that contain only the revocations since the last full list. An offline root CA publishes a CRL too, so administrators must power it on to re-sign that list before its Next Update time. If a CRL lapses, systems that require current revocation data, such as smart card logon or VPN authentication, can start rejecting valid certificates.
Strengths and weaknesses
- Latency: a new revocation reaches clients only when they fetch the next list, which can take hours or days.
- Size: a CA that revokes many certificates produces a large list, slow to download on constrained devices.
- Offline checking: once downloaded, a CRL can be checked without contacting the CA again.
- Privacy: every client downloads the same list, so the CA cannot tell which certificate a client is checking.
CRL vs. OCSP
A CRL is a published list that clients download and search. OCSP, the Online Certificate Status Protocol, is a real-time query: the client sends one serial number to the CA's responder and gets back a signed status of good, revoked or unknown. OCSP is fresher and smaller per check, but it tells the CA which sites users visit and usually fails open when the responder is unreachable. Public web practice has moved back toward CRLs: the CA/Browser Forum now requires CRLs from public TLS CAs while making OCSP optional, and browsers increasingly rely on revocation data their vendors compile from CRLs and push to them.
CRL on the CompTIA Security+ exam
CRLs are listed in SY0-801 objective 1.3, where certificate revocation is one of the PKI tasks you are expected to explain. "A signed list of revoked certificate serial numbers" or "clients download the list of revoked certificates" points to a CRL. A revocation that is slow to reach clients points to the CRL publication interval, with OCSP as the real-time alternative. "Temporarily suspend a certificate" points to a certificate hold. Distractors include OCSP stapling, in which the server delivers an OCSP response, and certificate expiration, which ends trust on schedule rather than early.