CRL

When a system validates a certificate, it retrieves the CRL issued by the CA and checks whether the certificate’s serial number appears in the list of revoked certificates. If the serial number appears in the CRL, the certificate is considered revoked and should no longer be trusted.

Most certificates include a CRL distribution point (CDP) extension that specifies where the CRL can be retrieved. During validation, the system reads this location from the certificate and downloads the CRL from that endpoint.

Validating systems typically cache the CRL locally after it is retrieved. Each CRL contains thisUpdate and nextUpdate timestamps that indicate when the CRL was issued and when a newer CRL is expected. The validating system continues using the cached CRL until the nextUpdate time is reached, at which point it retrieves an updated CRL from the distribution point.

Some certificates do not include a CDP extension. In those cases, revocation information must be obtained through other configured mechanisms. To support these scenarios, your private CA provides different CRL publishing models.

CRLs are made available to relying parties through CRL Distribution Points (CDP). When configuring a CRL, administrators define the locations from which relying parties can retrieve the CRL.

Distribution points in DigiCert Private CA can use HTTP, HTTPS, or LDAP endpoints.

When DigiCert Private CA generates a CRL, the system produces a CRL blob (binary large object), which is the encoded CRL file that contains the revocation information for the CA.

This CRL blob is the artifact that the CA publishes to the configured CRL distribution points. Systems that validate certificates retrieve the CRL blob from those locations and use it to check whether a certificate’s serial number appears in the list of revoked certificates.

Each CRL blob includes thisUpdate and nextUpdate timestamps. These values indicate when the CRL was issued and when a newer CRL is expected. Validating systems typically cache the retrieved CRL blob and continue using it until the nextUpdate time is reached. At that point, they retrieve a newly generated CRL blob from the distribution point.

When configuring revocation lists, administrators can create revocation lists that include different types of certificates depending on their operational requirements.

Administrators can choose whether to publish a single CRL that includes all certificate types or separate revocation lists for end-entity certificates and CA certificates.

When configuring a CRL that includes both CA and end-entity certificates, administrators can choose how the revocation information is published.

Partitioned CRLs are typically used in environments where the number of revoked certificates is large and distributing a single CRL would result in large or slow downloads for relying parties.

When configuring a CRL, administrators define how their private CA generates and publishes revocation information.

CRLs can be generated automatically based on a configured schedule or generated manually when needed.

If CRL generation and publishing are enabled, DigiCert Private CA publishes the CRL automatically whenever it is generated. The regeneration schedule determines how often the CRL is generated, and the CRL validity period determines how long the CRL remains valid for relying parties.

The regeneration schedule should be configured so that a new CRL is generated before the previous CRL reaches its nextUpdate time. This ensures that relying parties can always retrieve a current CRL.

A CA can have multiple CRLs configured, but only one CRL can be designated as the active CRL for that CA.

The active CRL is the revocation list that the CA uses when publishing revocation information for certificates it issues.

Administrators can create additional CRLs for different operational requirements, but only the active CRL is used for normal revocation publication.