Certificate revocation list

<h2 id="revocation-states">Revocation states</h2>

There are two different states of revocation defined in RFC 5280:

Revoked
A certificate is irreversibly revoked if, for example, it is discovered that the certificate authority (CA) had improperly issued a certificate, or if a private-key is thought to have been compromised. Certificates may also be revoked for failure of the identified entity to adhere to policy requirements, such as publication of false documents, misrepresentation of software behaviour, or violation of any other policy specified by the CA operator or its customer. The most common reason for revocation is the user no longer being in sole possession of the private key (e.g., the token containing the private key has been lost or stolen).
Hold
This reversible status can be used to note the temporary invalidity of the certificate (e.g., if the user is unsure if the private key has been lost). If, in this example, the private key was found and nobody had access to it, the status could be reinstated, and the certificate is valid again, thus removing the certificate from future CRLs.
<h2 id="reasons-for-revocation">Reasons for revocation</h2>
Reasons to revoke, hold, or unlist a certificate according to RFC 5280<a class="footnote-ref" id="fnref:11" href="#fn:11">11</a> are:

<ul><li>unspecified (0)</li>
<li>keyCompromise (1)</li>
<li>cACompromise (2)</li>
<li>affiliationChanged (3)</li>
<li>superseded (4)</li>
<li>cessationOfOperation (5)</li>
<li>certificateHold (6)</li>
<li>removeFromCRL (8)</li>
<li>privilegeWithdrawn (9)</li>
<li>aACompromise (10)</li></ul>
Note that value 7 is not used.

<h2 id="publishing-revocation-lists">Publishing revocation lists</h2>
A CRL is generated and published periodically, often at a defined interval. A CRL can also be published immediately after a certificate has been revoked. A CRL is issued by a CRL issuer, which is typically the CA which also issued the corresponding certificates, but could alternatively be some other trusted authority. All CRLs have a lifetime during which they are valid; this timeframe is often 24 hours or less. During a CRL's validity period, it may be consulted by a PKI-enabled application to verify a certificate prior to use.
To prevent <a href="/facts/Spoofing_attack/hyBGUakY">spoofing</a> or <a href="/facts/Denial-of-service_attack/6nkoK02J">denial-of-service attacks</a>, CRLs usually carry a <a href="/facts/Digital_signature/tY7e2pnW">digital signature</a> associated with the CA by which they are published. To validate a specific CRL prior to relying on it, the certificate of its corresponding CA is needed.
The certificates for which a CRL should be maintained are often <a href="/facts/X.509/rs0JuYDd">X.509</a>/<a href="/facts/Public_key_certificate/J7aYI4Bx">public key certificates</a>, as this format is commonly used by PKI schemes.

<h2 id="revocation-versus-expiration">Revocation versus expiration</h2>
Expiration dates are not a substitute for a CRL. While all expired certificates are considered invalid, not all unexpired certificates should be valid. CRLs or other certificate validation techniques are a necessary part of any properly operated PKI, as mistakes in certificate vetting and key management are expected to occur in real world operations.
In a noteworthy example, a certificate for <a href="/facts/Microsoft/nGIDDXdx">Microsoft</a> was mistakenly issued to an unknown individual, who had successfully posed as Microsoft to the CA contracted to maintain the <a href="/facts/ActiveX/xJb7t7Eh">ActiveX</a> 'publisher certificate' system (<a href="/facts/VeriSign/B57fYEGl">VeriSign</a>).<a class="footnote-ref" id="fnref:12" href="#fn:12">12</a> Microsoft saw the need to patch their cryptography subsystem so it would check the status of certificates before trusting them. As a short-term fix, a patch was issued for the relevant Microsoft software (most importantly Windows) specifically listing the two certificates in question as "revoked".<a class="footnote-ref" id="fnref:13" href="#fn:13">13</a>

<h2 id="problems-with-certificate-revocation-lists">Problems with certificate revocation lists</h2>
Best practices require that wherever and however certificate status is maintained, it must be checked whenever one wants to rely on a certificate. Failing this, a revoked certificate may be incorrectly accepted as valid. This means that to use a PKI effectively, one must have access to current CRLs. This requirement of on-line validation negates one of the original major advantages of PKI over <a href="/facts/Symmetric_key_algorithm/5zfe0b76">symmetric cryptography</a> protocols, namely that the certificate is "self-authenticating". Symmetric systems such as <a href="/facts/Kerberos_(protocol)/RMXs3P1w">Kerberos</a> also depend on the existence of on-line services (a <a href="/facts/Key_distribution_center/lMhqrz8U">key distribution center</a> in the case of Kerberos).
The existence of a CRL implies the need for someone (or some organization) to enforce policy and revoke certificates deemed counter to operational policy. If a certificate is mistakenly revoked, significant problems can arise. As the certificate authority is tasked with enforcing the operational policy for issuing certificates, they typically are responsible for determining if and when revocation is appropriate by interpreting the operational policy.
The necessity of consulting a CRL (or other certificate status service) prior to accepting a certificate raises a potential <a href="/facts/Denial-of-service_attack/6nkoK02J">denial-of-service attack</a> against the PKI. If acceptance of a certificate fails in the absence of an available valid CRL, then no operations depending upon certificate acceptance can take place. This issue exists for Kerberos systems as well, where failure to retrieve a current authentication token will prevent system access.
An alternative to using CRLs is the certificate validation protocol known as <a href="/facts/Online_Certificate_Status_Protocol/0SuMER8c">Online Certificate Status Protocol</a> (OCSP). OCSP has the primary benefit of requiring less network bandwidth, enabling real-time and near real-time status checks for high volume or high-value operations.
As of Firefox 28, Mozilla has announced they are deprecating CRL in favour of OCSP.<a class="footnote-ref" id="fnref:14" href="#fn:14">14</a>
CRL files may grow quite large over time e.g. in US government, for certain institution multiple megabytes. Therefore, incremental CRLs have been designed<a class="footnote-ref" id="fnref:15" href="#fn:15">15</a> sometimes referred to as "delta CRLs". However, only a few clients implement them.<a class="footnote-ref" id="fnref:16" href="#fn:16">16</a>

<h2 id="authority-revocation-lists">Authority revocation lists </h2>
An authority revocation list (ARL) is a form of CRL containing revoked certificates issued to <a href="/facts/Certificate_authority/WAo8vMTN">certificate authorities</a>, contrary to CRLs which contain revoked end-entity certificates.<a class="footnote-ref" id="fnref:17" href="#fn:17">17</a><a class="footnote-ref" id="fnref:18" href="#fn:18">18</a>

<h2 id="see-also">See also</h2>
<ul><li><a href="/facts/Trusted_third_party/VdPm949G">Trusted third party</a></li>
<li><a href="/facts/Web_of_trust/H2cy9v6s">Web of trust</a></li>
<li><a href="/facts/Certificate_authority/WAo8vMTN">Certificate authority</a></li>
<li><a href="/facts/Online_Certificate_Status_Protocol/0SuMER8c">Online Certificate Status Protocol</a></li></ul>

<h2 id="references">References</h2>

<ol>
<li id="fn:1">"What is Certificate Revocation List (CRL)? - Definition from WhatIs.com". TechTarget. Retrieved October 26, 2017. <a href="http://searchsecurity.techtarget.com/definition/Certificate-Revocation-List" target="_blank">http://searchsecurity.techtarget.com/definition/Certificate-Revocation-List</a> <a href="#fnref:1" class="footnote-back-ref">↩</a></li>
<li id="fn:2">"Baseline Requirements". CAB Forum. 4 September 2013. Archived from the original on 2024-07-11. Retrieved 2024-07-10. <a href="https://cabforum.org/baseline-requirements-documents/" target="_blank">https://cabforum.org/baseline-requirements-documents/</a> <a href="#fnref:2" class="footnote-back-ref">↩</a></li>
<li id="fn:3">Korzhitskii, Nikita; Carlsson, Niklas (2021). Revocation Statuses on the Internet. Passive and Active Measurement Conference. arXiv:2102.04288. <a href="/wiki/ArXiv_(identifier)" target="_blank">/wiki/ArXiv_(identifier)</a> <a href="#fnref:3" class="footnote-back-ref">↩</a></li>
<li id="fn:4">"As of Firefox 28, Firefox will not fetch CRLs during EV certificate validation". groups.google.com. <a href="https://groups.google.com/d/msg/mozilla.dev.security.policy/85MV81ch2Zo/fmqckeHESKUJ" target="_blank">https://groups.google.com/d/msg/mozilla.dev.security.policy/85MV81ch2Zo/fmqckeHESKUJ</a> <a href="#fnref:4" class="footnote-back-ref">↩</a></li>
<li id="fn:5">Santesson, Stefan; Myers, Michael; Ankney, Rich; Malpani, Ambarish; Galperin, Slava; Adams, Carlisle (June 2013). "RFC 6960: X.509 Internet Public Key Infrastructure: Online Certificate Status Protocol - OCSP". Internet Engineering Task Force (IETF). Archived from the original on 2018-12-15. Retrieved 2021-11-24. In lieu of, or as a supplement to, checking against a periodic CRL, it may be necessary to obtain timely information regarding the revocation status of certificates. ... OCSP may be used to satisfy some of the operational requirements of providing more timely revocation information than is possible with CRLs and may also be used to obtain additional status information. <a href="https://datatracker.ietf.org/doc/html/rfc6960#section-2" target="_blank">https://datatracker.ietf.org/doc/html/rfc6960#section-2</a> <a href="#fnref:5" class="footnote-back-ref">↩</a></li>
<li id="fn:6">"CRLSets". <a href="https://www.chromium.org/Home/chromium-security/crlsets/" target="_blank">https://www.chromium.org/Home/chromium-security/crlsets/</a> <a href="#fnref:6" class="footnote-back-ref">↩</a></li>
<li id="fn:7">"Intent to End OCSP Service - Let's Encrypt". 23 July 2024. <a href="https://letsencrypt.org/2024/07/23/replacing-ocsp-with-crls/" target="_blank">https://letsencrypt.org/2024/07/23/replacing-ocsp-with-crls/</a> <a href="#fnref:7" class="footnote-back-ref">↩</a></li>
<li id="fn:8">"Some consequences of widespread use of OCSP for HTTPS". <a href="https://utcc.utoronto.ca/~cks/space/blog/web/OCSPConsequences" target="_blank">https://utcc.utoronto.ca/~cks/space/blog/web/OCSPConsequences</a> <a href="#fnref:8" class="footnote-back-ref">↩</a></li>
<li id="fn:9">"No, don't enable revocation checking". <a href="https://www.imperialviolet.org/2014/04/19/revchecking.html" target="_blank">https://www.imperialviolet.org/2014/04/19/revchecking.html</a> <a href="#fnref:9" class="footnote-back-ref">↩</a></li>
<li id="fn:10">Gable, Aaron (26 February 2025). "Automated Certificate Management Environment (ACME) Renewal Information (ARI) Extension". <a href="https://datatracker.ietf.org/doc/draft-ietf-acme-ari/" target="_blank">https://datatracker.ietf.org/doc/draft-ietf-acme-ari/</a> <a href="#fnref:10" class="footnote-back-ref">↩</a></li>
<li id="fn:11">Boeyen, Sharon; Santesson, Stefan; Polk, Tim; Housley, Russ; Farrell, Stephen; Cooper, David (May 2008). "RFC 5280". tools.ietf.org. IETF: 69. section 5.3.1, Reason Code. Retrieved 2019-05-09. <a href="https://tools.ietf.org/html/rfc5280#section-5.3.1" target="_blank">https://tools.ietf.org/html/rfc5280#section-5.3.1</a> <a href="#fnref:11" class="footnote-back-ref">↩</a></li>
<li id="fn:12">Robert Lemos. "Microsoft warns of hijacked certificates - CNET News". News.cnet.com. Retrieved 2019-05-09. <a href="http://news.cnet.com/2100-1001-254586.html" target="_blank">http://news.cnet.com/2100-1001-254586.html</a> <a href="#fnref:12" class="footnote-back-ref">↩</a></li>
<li id="fn:13">"Microsoft Security Bulletin MS01-017 : Erroneous VeriSign-Issued Digital Certificates Pose Spoofing Hazard". Technet.microsoft.com. 2018-07-20. Retrieved 2019-05-09. <a href="https://technet.microsoft.com/en-us/library/security/ms01-017.aspx" target="_blank">https://technet.microsoft.com/en-us/library/security/ms01-017.aspx</a> <a href="#fnref:13" class="footnote-back-ref">↩</a></li>
<li id="fn:14">"As of Firefox 28, Firefox will not fetch CRLs during EV certificate validation". groups.google.com. <a href="https://groups.google.com/d/msg/mozilla.dev.security.policy/85MV81ch2Zo/fmqckeHESKUJ" target="_blank">https://groups.google.com/d/msg/mozilla.dev.security.policy/85MV81ch2Zo/fmqckeHESKUJ</a> <a href="#fnref:14" class="footnote-back-ref">↩</a></li>
<li id="fn:15">Boeyen, Sharon; Santesson, Stefan; Polk, Tim; Housley, Russ; Farrell, Stephen; Cooper, David (May 2008). "RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile". Tools.ietf.org. Retrieved 2019-05-09. <a href="http://tools.ietf.org/html/rfc5280#section-5.2.4" target="_blank">http://tools.ietf.org/html/rfc5280#section-5.2.4</a> <a href="#fnref:15" class="footnote-back-ref">↩</a></li>
<li id="fn:16">Archiveddocs (2018-03-20). "Configure CRL and Delta CRL Overlap Periods". Microsoft Docs. Retrieved 2020-06-25. <a href="https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-r2-and-2008/cc731104(v=ws.11)" target="_blank">https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-r2-and-2008/cc731104(v=ws.11)</a> <a href="#fnref:16" class="footnote-back-ref">↩</a></li>
<li id="fn:17">IBM (2021-02-04). "Setting up LDAP servers". IBM Knowledge Center. Retrieved 2021-02-18. <a href="https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_8.0.0/com.ibm.mq.sec.doc/q013380_.htm" target="_blank">https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_8.0.0/com.ibm.mq.sec.doc/q013380_.htm</a> <a href="#fnref:17" class="footnote-back-ref">↩</a></li>
<li id="fn:18">IBM. "Creating a distribution point ARL". IBM Knowledge Center. Retrieved 2021-02-18. <a href="https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.ikya100/arldp.htm" target="_blank">https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.ikya100/arldp.htm</a> <a href="#fnref:18" class="footnote-back-ref">↩</a></li>
</ol>

Certificate revocation list open-in-new

Certificate revocation list