Hubbry Logo
Certificate revocation listCertificate revocation listMain
Open search
Certificate revocation list
Community hub
Certificate revocation list
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Certificate revocation list
Certificate revocation list
Certificate revocation list
View on Wikipedia
from Wikipedia
Certificate revocation list
Filename extension
.crl
Internet media type
application/pkix-crl
Initial releaseMay 1999
Container forX.509 CRLs
StandardRFC 2585[1]
Websitehttps://www.iana.org/assignments/media-types/application/pkix-crl

In cryptography, a certificate revocation list (CRL) is "a list of digital certificates that have been revoked by the issuing certificate authority (CA) before their scheduled expiration date and should no longer be trusted".[2]

Publicly trusted CAs in the Web PKI are required (including by the CA/Browser forum[3]) to issue CRLs for their certificates, and they widely do.[4]

Browsers and other relying parties might use CRLs, or might use alternate certificate revocation technologies (such as OCSP)[5][6] or CRLSets (a dataset derived from CRLs[7]) to check certificate revocation status. Note that OCSP is falling out of favor due to privacy and performance concerns,[8][9][10] resulting in a return to CRLs.[11][12]

Subscribers and other parties can also use ARI.[13]

Revocation states

[edit]
CRL for a revoked cert of Verisign CA

There are two different states of revocation:[14]

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.

Reasons for revocation

[edit]

Reasons to revoke, hold, or unlist a certificate according to RFC 5280[15] are:

  • unspecified (0)
  • keyCompromise (1)
  • cACompromise (2)
  • affiliationChanged (3)
  • superseded (4)
  • cessationOfOperation (5)
  • certificateHold (6)
  • removeFromCRL (8)
  • privilegeWithdrawn (9)
  • aACompromise (10)

Note that value 7 is not used.

Publishing revocation lists

[edit]

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 spoofing or denial-of-service attacks, CRLs usually carry a digital signature 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 X.509/public key certificates, as this format is commonly used by PKI schemes.

Revocation versus expiration

[edit]

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 Microsoft was mistakenly issued to an unknown individual, who had successfully posed as Microsoft to the CA contracted to maintain the ActiveX 'publisher certificate' system (VeriSign).[16] 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".[17]

Problems with certificate revocation lists

[edit]

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 symmetric cryptography protocols, namely that the certificate is "self-authenticating". Symmetric systems such as Kerberos also depend on the existence of on-line services (a key distribution center 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 denial-of-service attack 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 Online Certificate Status Protocol (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.[5]

CRL files may grow quite large over time e.g. in US government, for certain institution multiple megabytes. Therefore, incremental CRLs have been designed[18] sometimes referred to as "delta CRLs". However, only a few clients implement them.[19]

Authority revocation lists

[edit]

An authority revocation list (ARL) is a form of CRL containing revoked certificates issued to certificate authorities, contrary to CRLs which contain revoked end-entity certificates.[20][21]

See also

[edit]

References

[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Certificate revocation list

View on Grokipedia
from Grokipedia
A Certificate Revocation List (CRL) is a digitally signed, time-stamped list issued by a Certification Authority (CA) or designated CRL issuer, identifying public key certificates that have been revoked prior to their expiration date due to reasons such as key compromise, certificate holder change, or cessation of operation. This mechanism ensures that relying parties in a can verify the current validity of certificates and avoid trusting those that are no longer secure or authorized. CRLs are defined in the X.509 standard and encoded using Abstract Syntax Notation One (ASN.1), with a structure that includes mandatory fields such as the issuer's Distinguished Name, the issuance date (thisUpdate), the next update date (nextUpdate), and a sequence of revoked certificates each specified by serial number and revocation date. Optional extensions, introduced in version 2 CRLs, provide additional functionality, including a CRL number for versioning, authority key identifiers to link to the issuer's public key, and indicators for delta CRLs that reference a base list for efficient updates. Issued periodically—such as daily or weekly—or on demand, CRLs are distributed through public repositories accessible via protocols like HTTP, LDAP, or FTP, allowing certificate-using systems to cache and check them during path validation processes. In PKI ecosystems, CRLs play a critical role in maintaining trust by enabling real-time revocation status checks, complementing expiration dates as a proactive security measure against threats like private key breaches. While effective for batch revocation, CRLs can grow large over time, prompting alternatives like the (OCSP) for individual queries, though CRLs remain a foundational element in standards-compliant implementations.

Fundamentals

Definition and Purpose

A Certificate Revocation List (CRL) is a digitally signed, time-stamped list issued periodically by a (CA) or an authorized CRL issuer, containing the serial numbers and revocation dates of digital certificates that have been invalidated prior to their expiration. This mechanism identifies certificates that are no longer trusted for use in secure communications, ensuring that relying parties can detect and reject them during validation processes. CRLs are a fundamental element of the v2 standard, as profiled for use. The primary purpose of a CRL is to disseminate timely revocation information to relying parties, such as web browsers, email clients, and servers, allowing them to check whether a presented certificate remains valid by comparing its against the list. By preventing the acceptance of revoked certificates, CRLs mitigate risks associated with compromised private keys or other issues, thereby upholding the of and in digital transactions. This validation step is integral to maintaining trust without requiring real-time queries to the CA. CRLs originated as part of the X.509 standard, first published in 1988 as a component of directory services for in open systems. The standard has evolved through multiple editions, with RFC 5280 in 2008 providing a comprehensive profile of v3 certificates and v2 CRLs specifically for (PKI). Within PKI ecosystems, CRLs play a crucial role by integrating into certificate path validation procedures, where they complement expiration checks to verify the ongoing trustworthiness of certificates in chains used for digital signatures and protocols like TLS/SSL. This ensures that only unrevoked certificates contribute to secure sessions, supporting reliable identity assurance across distributed networks.

Structure of a CRL

A Certificate Revocation List (CRL) is defined using Abstract Syntax Notation One () in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, specifically as the CertificateList type. This structure consists of three primary components: the tbsCertList (the to-be-signed portion containing the core CRL data), the signatureAlgorithm (an AlgorithmIdentifier specifying the signing algorithm, such as RSA with SHA-256), and the signatureValue (a BIT STRING holding the computed over the DER-encoded tbsCertList using the issuer's private key). The signature ensures the and authenticity of the entire list, preventing tampering or forgery. The tbsCertList is a TBSCertList structure that encapsulates the CRL's metadata and revoked entries. It includes a version field, which is an optional [0] EXPLICIT INTEGER defaulting to 0 (version 1, or v1) for basic CRLs without extensions; if present and set to 1, it indicates version 2 (v2), enabling CRL-specific extensions. The signature field repeats the AlgorithmIdentifier from the outer structure for verification. The issuer is a mandatory Name field representing the X.500 Distinguished Name (DN) of the issuing Certificate Authority (CA), such as "CN=Example CA, O=Example Org". The thisUpdate field provides the issuance time using Time (UTCTime for dates before 2050 or GeneralizedTime otherwise), while the nextUpdate field, which is optional but required by the profile, specifies the expiration time of the CRL's validity period. The revokedCertificates field is an optional SEQUENCE OF RevokedCertificate, listing each revoked certificate in chronological order of revocation. Each RevokedCertificate entry contains a mandatory userCertificate (the CertificateSerialNumber of the revoked certificate) and revocationDate (the Time when revocation occurred). In v2 CRLs, entries may include optional crlEntryExtensions of type Extensions, such as the CRLReason extension (OID 2.5.29.21), which encodes the reason for revocation as an enumerated value (e.g., key compromise or cessation of operation). For v2 CRLs, the crlExtensions field ( [2] EXPLICIT Extensions) allows optional metadata, such as the authorityKeyIdentifier extension (OID 2.5.29.35), which identifies the CA's public key via a key identifier (typically the SHA-1 hash of the public key), and the cRLNumber extension (OID 2.5.29.20), a non-critical INTEGER providing a unique, monotonically increasing sequence number to order multiple CRLs from the same issuer. CRLs are typically encoded in Distinguished Encoding Rules (DER), a binary format that ensures canonical representation for signing and verification. For text-based distribution, (PEM) format is commonly used, which wraps the DER-encoded bytes in with headers like -----BEGIN X509 CRL----- and -----END X509 CRL-----.
FieldTypeDescriptionMandatory?
version[0] EXPLICIT INTEGERCRL version (0 for v1, 1 for v2)Optional (defaults to 0)
signatureAlgorithmIdentifierSigning algorithmYes
issuerNameCA's Distinguished NameYes
thisUpdateTimeIssuance timestampYes
nextUpdateTimeValidity expiration timestampYes (per profile)
revokedCertificatesSEQUENCE OF RevokedCertificateList of revoked certsOptional
crlExtensions[2] EXPLICIT Extensionsv2-specific extensionsOptional (v2 only)
RevokedCertificate FieldTypeDescriptionMandatory?
userCertificateCertificateSerialNumberRevoked certificate's Yes
revocationDateTimeRevocation timestampYes
crlEntryExtensionsExtensionsPer-entry extensions (e.g., CRLReason)Optional (v2 only)

Revocation Process

Reasons for Revocation

Certificate authorities (CAs) revoke certificates when they determine that the certificate should no longer be trusted, as outlined in the Internet Certificate and Certificate List (CRL) Profile. The specific reasons for revocation are standardized to ensure interoperability and clarity in (PKI) systems, allowing relying parties to understand the context of the invalidation. These reasons are encoded in CRL entries using numeric codes defined as an in , providing machine-readable classification. The standard revocation reasons, excluding the "unspecified" code which should be avoided when a more precise reason applies, include compromises, operational changes, and administrative actions. Key compromise occurs when the private key associated with the certificate is exposed or suspected of being compromised, potentially allowing unauthorized use. CA compromise happens if the issuing CA's security is breached, undermining the trustworthiness of certificates it has issued. Affiliation changed refers to situations where the subject's relationship or with the issuing alters, such as an employee departing a in an enterprise PKI setup. Superseded indicates the certificate has been replaced by a newer one before its expiration. Cessation of operation applies when the subject entity ceases to exist or operate, like a business shutdown. Certificate hold represents a temporary suspension rather than permanent . Privilege withdrawn is used when the subject's authorized privileges are revoked, such as loss of access rights. Finally, AA compromise addresses breaches in an attribute authority that manages additional certificate attributes. The "removeFromCRL" reason is a special case used exclusively in delta CRLs to indicate that a previously revoked certificate is no longer considered revoked. The following table summarizes the revocation reason codes as defined in RFC 5280:
Numeric ValueReason CodeDescription
0unspecifiedNo specific reason provided
1keyCompromisePrivate key compromised
2cACompromiseCA compromised
3affiliationChangedSubject’s affiliation changed
4supersededCertificate superseded
5cessationOfOperationSubject ceased operation
6certificateHoldCertificate on hold
8removeFromCRLRemove from CRL (delta CRLs only)
9privilegeWithdrawnPrivileges withdrawn
10aACompromiseAttribute authority compromised
Real-world examples illustrate these reasons. In the 2011 DigiNotar incident, a Dutch CA's systems were breached, leading to the fraudulent issuance of over 500 certificates, including for high-profile domains like ; this triggered mass revocations primarily under the CA compromise reason due to the root CA's security failure. In enterprise PKI environments, affiliation changes commonly prompt revocations, such as when an employee's certificate is invalidated upon termination to prevent unauthorized access to internal resources. Policy considerations emphasize timely action by CAs. According to the CA/Browser Forum's Baseline Requirements, CAs must revoke certificates within 24 hours upon confirmation of a private key to mitigate risks. For other reasons like CA , revocation timelines are similarly stringent, often requiring action within hours to maintain PKI integrity, though exact intervals vary by scenario and are guided by section 4.9.1.1 of the requirements.

Revocation States and Process

The for a certificate in a Certificate Revocation List (CRL) begins when the certificate owner or the issuing (CA) identifies an issue warranting invalidation, such as a security compromise or administrative change. The CA then updates its internal records to mark the certificate as and generates a new CRL entry containing the certificate's , the date of , and an optional reason code. This updated CRL is digitally signed by the CA to ensure and authenticity before issuance. Upon inclusion in a CRL, the certificate enters a revoked state, rendering it invalid for use in cryptographic operations from the specified revocation date onward. Revoked certificates remain listed on subsequent CRLs until after their original validity period has expired, at which point the entry is removed to prevent indefinite list growth. This ensures that relying parties, such as applications or systems verifying certificates, treat the certificate as untrustworthy if its serial number appears in a valid CRL. Revocations can be either permanent or temporary, depending on the reason assigned. Permanent revocations, indicated by codes such as key compromise ( 1) or cessation of operation ( 5), are irreversible and result in the certificate being permanently invalidated. In contrast, temporary revocations use the "certificateHold" reason ( 6), allowing the CA to reverse the action by issuing a subsequent CRL that omits the entry or explicitly marks it with a "removeFromCRL" ( 8), restoring the certificate's validity without reissuance. The timeline for revocation effectiveness is governed by the CRL's issuance details: the revocation takes effect from the "thisUpdate" field, which denotes the date the CRL was created, though the specific revocation date in the entry may precede this if the update was delayed. Relying parties enforce revocation by obtaining the most recent CRL—ensuring it is current relative to the "nextUpdate" field—and checking for the certificate's serial number; if found, the certificate is deemed revoked regardless of its expiration date. This process requires periodic CRL retrieval to maintain up-to-date status information.

Distribution and Management

Publishing and Formats

Certificate Authorities (CAs) issue Certificate Revocation Lists (CRLs) periodically to disseminate revocation status for certificates they have issued, with updates occurring on schedules defined by CA policy, such as daily or weekly intervals. The CRL includes a NextUpdate field specifying the date and time of the subsequent issuance, ensuring relying parties know when to fetch the next version. For environments requiring heightened security, policies may mandate updates as frequent as every 24 hours to minimize the window for undetected revocations. Delta CRLs, which capture only revocation changes since the prior base CRL, enable more frequent supplemental publications while reducing overall data volume. As of 2024, following the CA/Browser Forum's 2023 ballot, CRLs are required for revocation status in publicly trusted certificates, with OCSP becoming optional. CRLs are distributed via network-accessible endpoints, primarily HTTP or uniform resource identifiers (URIs), as indicated in the cRLDistributionPoints extension of the associated certificates. These URIs resolve to the CRL file, allowing automated retrieval by relying parties. The extension supports multiple distribution points for redundancy and protocol flexibility, though HTTP/ is predominant in practice. version 2 CRLs follow the structure profiled in RFC 5280 and must be encoded in Distinguished Encoding Rules (DER) binary format for standardized distribution. PEM (Privacy-Enhanced Mail) encoding provides a human-readable, text-based alternative by base64-encoding the DER bytes and enclosing them in header and footer markers (e.g., -----BEGIN X509 CRL-----), facilitating easier handling in scripts or logs. To address scalability in large deployments, CRL partitioning segments the list into multiple independent CRLs based on criteria like revocation reasons or issuer subsets, leveraging the issuingDistributionPoint extension to define each segment's scope and distribution details. Update frequency aligns with CA-specific policies balancing security needs and operational overhead; for instance, base CRLs are often published weekly, complemented by daily delta CRLs. A key best practice for versioning involves the mandatory cRLNumber extension, an integer that increments monotonically (typically by 1) with each issuance, enabling relying parties to identify and apply the most current CRL without redundant downloads.

Verification and Checking

During certificate validation, such as in a TLS handshake, a client retrieves the Certificate Revocation List (CRL) from the distribution point specified in the certificate's CRL Distribution Points extension. The client then verifies the CRL's signature using the issuing Certificate Authority's (CA) public key, obtained from a trusted certificate or a validated certification path, ensuring the signature algorithm matches the one in the CRL's signatureAlgorithm field. Next, the client confirms that the current time falls between the CRL's thisUpdate and nextUpdate fields to ensure validity; if so, it checks whether the presented certificate's serial number appears in the revokedCertificates sequence, matching the issuer name to the CRL's scope. If the serial number appears in the revokedCertificates sequence (with the revocation date ≤ the current validation time), the certificate is considered revoked. To optimize performance and reduce network load, clients cache valid CRLs until the nextUpdate time, treating them as current during that period. However, if a certificate's issuance date (notBefore) falls within the CRL's validity interval, the client must recheck or fetch an updated CRL to confirm the status at issuance, preventing acceptance of certificates revoked shortly after issuance. Cached CRLs can be stored in unsecured locations due to their signed nature, which provides tamper resistance, and delta CRLs may be used to update base CRLs efficiently without full redownloads. CRL verification is integrated into cryptographic libraries and applications for seamless use. In , the X509_CRL_verify function checks the CRL's signature against a provided public key, while broader certificate path validation via X509_verify_cert incorporates CRL checks if enabled through options like X509_V_FLAG_CRL_CHECK. Web browsers like employ CRLSets—a compact, aggregated format of revocation data from multiple CAs—for efficient local checking; these sets are fetched periodically (at most every few hours), verified against the issuing certificates, and include subsets of revocations to minimize size and enable fast lookups without real-time fetches. If a CRL is unavailable, invalid (e.g., failure or expired nextUpdate), or contains unrecognized critical extensions, the validation process treats the revocation status as undetermined after attempting all distribution points, potentially failing the entire certificate path unless application policy allows continuation. In such cases, systems may apply soft-fail policies to avoid blocking legitimate connections due to transient issues, returning an "unknown" status that depends on the relying party's tolerance.

Comparisons

CRL versus Expiration

Certificate expiration represents a fundamental mechanism in public key infrastructure (PKI) for managing the lifecycle of X.509 digital certificates, where each certificate includes a validity period defined by notBefore and notAfter fields that specify the exact start and end times of its operational validity. This period is encoded using UTCTime for dates up to 2049 or GeneralizedTime thereafter, ensuring the certificate is considered invalid automatically once the current time exceeds the notAfter date, without requiring any intervention from the issuing certification authority (CA). For publicly trusted certificates, such as those used in TLS, the CA/Browser Forum mandates a maximum validity period of 398 days for subscriber certificates issued after September 1, 2020, promoting regular rotation to limit exposure risks. In contrast to expiration, which provides a predictable, scheduled termination of trust, certificate revocation through a Certificate Revocation List (CRL) enables premature invalidation of a certificate before its notAfter date to address immediate security concerns. While expiration relies on the passage of time to enforce , CRLs offer dynamic control by listing revoked certificates with their serial numbers and dates in a signed, time-stamped structure that relying parties must actively check during validation. This distinction allows to handle unscheduled events—such as private key compromise—far more responsively than waiting for natural expiry, though it introduces the overhead of periodic CRL retrieval and processing. Expiration suits routine certificate management and rotation in stable environments, where the fixed validity period—capped at 398 days for enhanced —encourages proactive renewal without the need for real-time status monitoring post-notAfter. Revocation via CRL, however, is essential for incident response, such as when a certificate must be invalidated due to key loss or suspected , ensuring trust is withdrawn promptly rather than deferred until expiration. For instance, in enterprise PKI deployments, organizations use expiration for annual renewals of employee certificates, while employing CRLs for emergency revocations following breaches. A key implication of relying on expiration is the elimination of checks for outdated certificates, as any certificate beyond its notAfter date is inherently untrusted, thereby reducing computational and network overhead in validation workflows compared to ongoing CRL consultations for active periods. This passive approach complements CRLs by bounding the window of vulnerability, but underscores the need for in cases where threats emerge mid-lifecycle, such as those outlined in standard reasons like key compromise.

CRL versus OCSP and Alternatives

The (OCSP), defined in RFC 6960, enables real-time queries to a (CA) or designated responder to determine the revocation status of an individual digital certificate, returning responses such as "good," "revoked," or "unknown" without the need to download entire revocation lists. This on-demand approach contrasts with Certificate Revocation Lists (CRLs), which provide a batch, offline mechanism where relying parties proactively fetch and cache a comprehensive list of revoked certificates issued by a specific CA. CRLs offer scalability for environments with a large number of certificates, as a single list can cover many entries, reducing per-certificate overhead, but they consume significant bandwidth due to frequent downloads of potentially large files and may delay revocation awareness until the next update cycle. In comparison, OCSP minimizes data transfer by querying only the status of specific certificates but introduces latency from real-time network requests, raises concerns through query tracking that can reveal user browsing patterns to the CA, and creates a if the OCSP responder is unavailable. To mitigate some OCSP drawbacks, techniques like allow servers to include signed status responses in TLS handshakes, but this still relies on timely CA updates. Beyond OCSP, Certificate Transparency (CT) logs serve as an alternative for monitoring certificate issuance and detecting anomalies, such as unauthorized certificates that may warrant revocation, by maintaining publicly auditable, append-only logs of all issued certificates to enhance overall PKI accountability. Emerging trends toward short-lived certificates, with validity periods as brief as under 10 days, further reduce the need for traditional revocation mechanisms by limiting the window for compromise exploitation, following the CA/Browser Forum's April 2025 approval of a phased reduction to a maximum of 47 days by March 2029. Complementing this, RFC 9608 (2024) introduces a certificate extension signaling "no revocation available," permitting clients to skip status checks for short-lived certificates where revocation is impractical or unnecessary. In terms of adoption, major browsers and CAs are shifting back toward CRLs due to OCSP's reliability issues, exemplified by Let's Encrypt's phased ending of OCSP support starting May 7, 2025, with full discontinuation on August 6, 2025, citing risks and operational inefficiencies while relying on CRLs for dissemination. This move aligns with broader industry trends favoring CRLs' -preserving offline nature and wide compatibility, though hybrid approaches combining CRLs with short-lived certificates continue to evolve.
AspectCRLsOCSP
Access MethodOffline batch download of full listOn-demand online query for individual certificate
ScalabilityHigh for bulk checks; efficient for many certificatesLower bandwidth per query but scales poorly with high query volume
TimelinessPeriodic updates; potential delay in revocation propagationNear real-time but subject to network latency
PrivacyHigh; no per-certificate queriesLow; queries can track user activity
ReliabilityResilient to single-point failures; cacheableVulnerable to responder downtime

Variants and Extensions

Delta CRLs and Partitioning

Delta CRLs provide an optimization for distributing certificate revocation information by issuing incremental updates rather than complete lists each time. Defined in RFC 5280, a delta CRL is a signed that contains only the certificates revoked since the issuance of a referenced base CRL, which is a full, complete CRL covering all revocations within the same scope. These deltas are typically issued more frequently than base CRLs—for instance, a base CRL might be published weekly, with daily delta updates listing only the changes—to minimize bandwidth usage and download times for clients. The delta CRL includes entries added after revocation notifications and removes them only after the revoked certificates expire, ensuring consistency with the base CRL's scope and reasons for . Implementation of delta CRLs relies on specific extensions in the CRL structure. Each delta CRL must include a critical Delta CRL Indicator extension (OID: id-ce 27), which specifies the BaseCRLNumber—a positive identifying the base CRL it updates—allowing clients to link the delta to its corresponding base. Base and delta CRLs share a common CRL Number extension (OID: id-ce 20), a monotonically increasing that tracks the sequence across both types; clients use this to determine the most recent delta for a given base. To process revocation status, clients fetch a recent base CRL and then apply all applicable deltas by combining their entries, using the delta's thisUpdate and nextUpdate fields to form the effective CRL validity period. The Freshest CRL extension (OID: id-ce 46) in the base CRL can further assist by pointing to distribution points for delta CRLs, streamlining discovery. CRL partitioning addresses scalability challenges in large deployments by dividing a monolithic CRL into multiple smaller files, each covering a subset of revoked certificates based on predefined criteria. This technique leverages the CRL Distribution Points extension (OID: id-ce 31) in certificates, which specifies multiple locations for CRL retrieval, enabling CAs to segment lists by factors such as reason codes via the Issuing Distribution Point extension. For example, one partition might handle compromise-related revocations (e.g., keyCompromise or CACompromise), while another covers routine cases like affiliation changes, as recommended against broad reason-based segmentation but permitted for targeted partitioning. In practice, high-volume CAs often partition by serial number ranges or random assignment at issuance, embedding the relevant partition in the certificate's CDP extension; this allows revoked certificates to appear only in their assigned partition's CRL. Partitioning supports parallel fetching by clients, who retrieve only the necessary partitions for a given certificate, reducing overall load and processing time in environments with extensive revocation volumes. For instance, in public PKI systems, some CAs maintain CRLs exceeding 300,000 entries, as seen in DigiCert's global TLS CA partitions with up to 331,613 revocations. This approach is particularly beneficial for high-scale scenarios like IoT deployments, where millions of certificates may require frequent validation, enabling smaller, more manageable CRLs without full reliance on deltas. By combining partitioning with delta CRLs, CAs can further optimize updates, as smaller base partitions pair effectively with incremental deltas.

Authority Revocation Lists

Authority Revocation Lists (ARLs) are a specialized form of Certificate Revocation List (CRL) designed specifically to revoke certificates issued to Certificate Authorities (CAs), thereby invalidating all certificates in the downstream trust chain that rely on the revoked CA. Unlike standard CRLs, which target end-entity certificates, ARLs focus on authority certificates, such as those for intermediate or subordinate CAs, and are typically issued by a superior CA or a policy-making body overseeing the . This mechanism ensures that if a CA is compromised or otherwise untrustworthy, relying parties can detect and reject the entire hierarchy of certificates it has issued, maintaining the integrity of the . The purpose of ARLs is to provide a targeted revocation process for CA certificates, which is critical in hierarchical PKI environments where a single compromised authority could affect vast numbers of end-user certificates. For instance, following the 2011 DigiNotar breach, where the Dutch issued fraudulent certificates for high-profile domains, the incident underscored the need for swift of authority certificates to prevent widespread misuse, leading to enhanced scrutiny and revocation mechanisms in root CA programs. ARLs are distributed by top-level or root CAs and are often referenced in certificate policies under programs like the guidelines, ensuring that validation software checks them during certificate path processing. They are published periodically, similar to CRLs, and include details such as the revoked CA's , revocation date and time, and reason code, all digitally signed by the issuing authority. Structurally, ARLs conform to the Version 2 CRL profile, utilizing extensions like the Issuing Distribution Point to indicate their scope is limited to authority revocations, which helps relying parties efficiently process them without conflating with end-entity lists. A key difference from standard CRLs is their emphasis on the issuer Distinguished Name (DN) or CA identifier rather than individual end-entity serial numbers, as the revocation applies broadly to the authority's entire issuance scope. Due to their high-impact nature—potentially invalidating millions of certificates—ARLs are issued infrequently and remain small in size, making them rarer than typical CRLs but essential for high-assurance PKIs. In practice, ARLs are integrated into validation processes by tools and libraries compliant with PKIX standards, where they are retrieved via LDAP or HTTP distribution points specified in the superior CA's certificate. Examples of ARL usage appear in enterprise and PKIs, such as those managed by service providers, where intermediate CA revocations are tracked to enforce policy compliance. Root CA policies, including those audited under WebTrust for CAs, mandate the maintenance and publication of ARLs to support trust ecosystem integrity, with updates triggered by incidents like security breaches or key compromises.

Challenges and Developments

Limitations of CRLs

Certificate Revocation Lists (CRLs) face significant challenges due to their growing file sizes, which can exceed 10 MB in modern deployments. For instance, analyses of CRLs from major certificate authorities in 2024 revealed that certain lists, such as those from , reached approximately 11.9 MB uncompressed. These large sizes stem from the accumulation of revoked certificate entries over time, particularly for high-volume CAs issuing millions of certificates. Downloading such files imposes considerable bandwidth demands on clients, leading to delays that can range from seconds to minutes depending on network conditions and file compression. Microsoft guidelines recommend capping CRL sizes at 10 MB to mitigate these issues, yet real-world examples often surpass this threshold, exacerbating performance bottlenecks in resource-constrained environments. Compounding scalability are the infrequent update schedules of CRLs, which create substantial revocation windows during which compromised certificates may remain valid. CRLs are typically published on schedules ranging from daily to weekly intervals, with defaults often set to one week in systems like Microsoft Active Directory Certificate Services. This periodicity means that after a certificate is revoked, there can be a delay of hours to days before the updated CRL is available and propagated to relying parties, leaving a temporal gap vulnerable to misuse. Caching mechanisms further extend this window, as clients retain CRLs until their validity period expires, potentially accepting revoked certificates in the interim. Reliability issues arise primarily from dependencies on network availability for fetching CRLs, which can result in the inadvertent acceptance of revoked certificates. If a client cannot reach the CRL distribution point due to network failures, timeouts, or connectivity problems, many implementations default to accepting the certificate to avoid disrupting , a behavior known as "soft fail." This creates a single point of failure at the distribution infrastructure, where outages can cascade to widespread validation errors across all certificates issued by the affected CA. Additionally, CRLs lack replay protection within their validity period; once issued and signed, an outdated but still valid CRL cannot be distinguished from a current one in transit, allowing potential interception and reuse without detection. Privacy and security concerns further undermine CRL efficacy, as the full lists publicly disclose all revoked certificates, potentially exposing sensitive about compromised entities. Downloading a complete CRL reveals the serial numbers and revocation reasons for every affected certificate, enabling adversaries to infer patterns of incidents or target specific organizations. This transparency contrasts with more selective querying methods and can lead to unintended leakage in -sensitive contexts. Moreover, CRL distribution points are susceptible to denial-of-service attacks; flooding these endpoints with requests can prevent legitimate fetches, effectively disabling checks system-wide and allowing revoked certificates to persist in use. Adoption barriers persist due to the overhead associated with CRL processing, prompting many clients, particularly web browsers, to skip or limit checks. Pre-2020 browser implementations, such as those in and , often disabled online revocation checks by default to reduce latency and bandwidth usage, relying instead on embedded revocation sets that cover only high-risk certificates. This selective approach increases overall risk, as full CRL validation is bypassed in favor of performance, leaving lower-profile s undetected. The computational and network costs of handling large, frequent downloads have historically deterred comprehensive enforcement, contributing to inconsistent security across ecosystems. In 2025, discontinued support for the (OCSP), fully transitioning to Certificate Revocation Lists (CRLs) as the primary mechanism for disseminating revocation information. This shift began with the removal of OCSP URLs from certificates on May 7, 2025, followed by the shutdown of OCSP responders on August 6, 2025, motivated by OCSP's privacy risks and operational costs. The CA/Browser Forum's Ballot SC081v3, passed in April 2025, established a phased reduction in public TLS certificate validity periods, targeting a maximum of 47 days by March 2029, building on prior limits of 398 days and accelerating the trend toward lifetimes under 90 days to minimize needs. This evolution is supported by RFC 9608, published in June 2024, which introduces the noRevAvail certificate extension to explicitly signal that a certification authority provides no data, enabling relying parties to skip checks for short-lived certificates where is impractical. Certificate revocations reached significant scale in , with analyses identifying over 4.5 million revoked certificates across major public key infrastructures from to early , including bursts tied to incidents like 's revocation of more than 83,000 certificates in August due to domain validation failures. Such mass events have accelerated adoption of delta CRLs and partitioning techniques to manage distribution efficiency, as evidenced by CRL sizes growing to over 11 MB for authorities like , containing hundreds of thousands of entries in ecosystems. Looking ahead, CRL distribution over is gaining traction to enhance security against interception and tampering, despite traditional preferences for HTTP to avoid validation loops, with implementations like Microsoft's Entra supporting both protocols as of 2025. Integration with post-quantum (PKI) is emerging, with providing post-quantum cryptography capabilities, including support for algorithms like , in builds as of May 2025 to protect against harvest-now-decrypt-later attacks. In August 2025, rolled out CRLite in , enabling fast, privacy-preserving, and comprehensive certificate revocation checking using downloaded CRL snapshots, without online queries. Additionally, blockchain-based approaches offer potential for decentralized CRL distribution, improving availability and tamper-resistance through smart contracts and accumulators, with recent developments in vehicular networks and IoT environments showing prototypes for real-time, immutable revocation lists in 2024.

References

  1. https://www.ietf.org/rfc/rfc5280.txt
  2. https://csrc.nist.gov/glossary/term/certificate_revocation_list
  3. https://www.itu.int/itu-t/recommendations/rec.aspx?rec=X.509
  4. https://datatracker.ietf.org/doc/html/rfc5280#section-5.1
  5. https://datatracker.ietf.org/doc/html/rfc5280#section-5.1.1
  6. https://datatracker.ietf.org/doc/html/rfc5280#section-5.1.1.3
  7. https://datatracker.ietf.org/doc/html/rfc5280#section-5.1.2.1
  8. https://datatracker.ietf.org/doc/html/rfc5280#section-5.1.2.2
  9. https://datatracker.ietf.org/doc/html/rfc5280#section-5.1.2.3
  10. https://datatracker.ietf.org/doc/html/rfc5280#section-5.1.2.4
  11. https://datatracker.ietf.org/doc/html/rfc5280#section-5.1.2.5
  12. https://datatracker.ietf.org/doc/html/rfc5280#section-5.1.2.6
  13. https://datatracker.ietf.org/doc/html/rfc5280#section-5.3.1
  14. https://datatracker.ietf.org/doc/html/rfc5280#section-5.1.2.7
  15. https://datatracker.ietf.org/doc/html/rfc5280#section-5.2.1
  16. https://datatracker.ietf.org/doc/html/rfc5280#section-5.2.3
  17. https://datatracker.ietf.org/doc/html/rfc5280#appendix-C.4
  18. https://datatracker.ietf.org/doc/html/rfc5280
  19. https://datatracker.ietf.org/doc/html/rfc5280#section-6.3.2
  20. https://datatracker.ietf.org/doc/html/rfc5280#appendix-A.2
  21. https://cabforum.org/baseline-requirements/
  22. https://datatracker.ietf.org/doc/html/rfc5280#section-3.3
  23. https://datatracker.ietf.org/doc/html/rfc5280#section-5.3
  24. https://datatracker.ietf.org/doc/html/rfc5280#section-6.3.3
  25. https://cabforum.org/2023/07/14/ballot-sc063v4-make-ocsp-optional-require-crls-and-incentivize-automation/
  26. https://www.chromium.org/Home/chromium-security/crlsets/
  27. https://www.rfc-editor.org/rfc/rfc5280.html#section-4.1.2.5
  28. https://www.rfc-editor.org/rfc/rfc5280.html#section-3.3
  29. https://www.rfc-editor.org/rfc/rfc5280.html#section-5.1.2.6
  30. https://www.rfc-editor.org/rfc/rfc5280.html#section-6.3.2
  31. https://www.rfc-editor.org/rfc/rfc5280.html#section-6.1.3
  32. https://datatracker.ietf.org/doc/html/rfc6960
  33. https://sectigostore.com/blog/ocsp-vs-crl-whats-the-difference/
  34. https://www.encryptionconsulting.com/ocsp-vs-crl/
  35. https://emudhra.com/en-us/blog/ocsp-vs-crl
  36. https://www.oxyplug.com/optimization/crl-ocsp-certificate-revocation-methods/
  37. https://www.digicert.com/faq/certificate-transparency/what-is-certificate-transparency
  38. https://certificate.transparency.dev/howctworks/
  39. https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/
  40. https://datatracker.ietf.org/doc/rfc9608/
  41. https://letsencrypt.org/2024/12/05/ending-ocsp
  42. https://smallstep.com/blog/ocsp-vs-crl-explained/
  43. https://datatracker.ietf.org/doc/html/rfc5280#section-5.2.4
  44. https://datatracker.ietf.org/doc/html/rfc5280#section-5.2.6
  45. https://datatracker.ietf.org/doc/html/rfc5280#section-5.2.5
  46. https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.13
  47. https://www.sysadmins.lv/blog-en/ad-cs-partitioned-crls-introduction-part1.aspx
  48. https://chasersystems.com/blog/an-analysis-of-certificate-revocation-list-sizes/
  49. https://www.giac.org/paper/gsec/657/certificate-revocation-public-key-infrastructures/101508
  50. https://www.ibm.com/docs/en/ibm-mq/9.2.x?topic=SSFKSJ_9.2.0/com.ibm.mq.sec.doc/q013370_.html
  51. https://blog.mozilla.org/security/2011/09/02/diginotar-removal-follow-up/
  52. https://anf.es/en/certificate-revocation-list/
  53. https://www.keyfactor.com/blog/what-is-a-certificate-revocation-list-crl-vs-ocsp/
  54. https://learn.microsoft.com/en-us/security/trusted-root/program-requirements
  55. https://www.cisco.com/c/en/us/support/docs/security/identity-services-engine/216528-configure-microsoft-ca-server-to-publish.html
  56. https://learn.microsoft.com/en-us/entra/identity/authentication/concept-certificate-based-authentication-certificate-revocation-list
  57. https://blog.cloudflare.com/high-reliability-ocsp-stapling/
  58. https://security.stackexchange.com/questions/242953/crl-over-https-is-it-really-a-bad-practice
  59. https://ics.uci.edu/~gtsudik/paps/nt07.pdf
  60. https://www.gradenegger.eu/en/google-chrome-does-not-check-revocation-status-of-certificates/
  61. https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/defective-by-design-certificate-revocation-behavior-in-modern-browsers/
  62. https://letsencrypt.org/2025/08/06/ocsp-service-has-reached-end-of-life
  63. https://zirngibl.github.io/files/sosnowski2024certificates.pdf
  64. https://thehackernews.com/2024/07/digicert-to-revoke-83000-ssl.html
  65. https://techcommunity.microsoft.com/blog/microsoft-security-blog/post-quantum-cryptography-comes-to-windows-insiders-and-linux/4413803
  66. https://hacks.mozilla.org/2025/08/crlite-fast-private-and-comprehensive-certificate-revocation-checking-in-firefox/
  67. https://dl.acm.org/doi/10.1145/3688225.3688228
  68. https://ieeexplore.ieee.org/document/9376112
Add your contribution
Related Hubs
User Avatar
No comments yet.