LDAPWiki: Certificate Revocation List

Overview[1]#

A certificate Revocation List or CRL is list of revoked Certificates and is used for checking Certificate Revocation when performing Certificate Validation

A Certificate Authority should revoke a Certificate, for example, if it has been compromised in some way—much the way a credit card company might revoke your credit card if you report that it's been stolen.

Downloading and Updating CRLs#

You can download the latest CRL from a Certificate Authority to your browser. To download a CRL, you typically go to a URL (specified by the Certificate Authority or by your system administrator) and click a link.

The browser uses the CRLs it has available to check the validity of certificates issued by the corresponding CAs. If a certificate is listed as revoked, the browser won't accept it as evidence of identity.

A Certificate Authority typically publishes an updated Certificate Revocation List at regular intervals. Every Certificate Revocation List includes a date, specified in the Next Update field, by which the Certificate Authority will publish the next update of that Certificate Revocation List. If the date in the Next Update field is earlier than the current date, you should obtain the most recent version of the Certificate Revocation List.

Although the absence of the most recent Certificate Revocation List does not by itself invalidate a Certificate, the browser may not handle such Certificates correctly.

In some situations, you may want to Server and client applications that use public-key certificates as tokens of identification need access to information about the validity of a certificate; because one of the factors that determines the validity of a certificate is its revocation status, these applications need to know whether the certificate being validated has been revoked. In that regard, the Certificate Authority has a responsibility to do the following:

Revoke the certificate if any of the certificate assertions becomes false--for example, if the subject's key gets compromised or the status of the subject's role or right changes. (See "Reasons for Revoking a Certificate".)
Make the revoked certificate available to parties or applications that need to verify its validity status.

One of the standard methods for conveying the revocation status of certificates is by publishing a list of revoked certificates. This list is known as the certificate revocation list (CRL). The CRL is a publicly available list of certificates that have been revoked.

A Certificate Revocation List is issued and digitally signed by the Certificate Authority that issued the certificates listed in the CRL. The Certificate Authority's function includes creating the CRLs periodically and distributing them to other applications. For example, the CA may publish the CRL to a global directory which other applications may use for checking the revocation status of a certificate or from which other applications can retrieve the CRL.

Risks of validation by CRL#

To allow caching of a CRL at the users location, every CRL contains informations of its period of validity. That means a CRL can be issued every 5 minutes and have a period of validity of somewhat like an hour. As one can imagine this caching is directly linked to the risk that a revoked certificate is used. The longer a client is allowed to use (cache) an old CRL, the higher is the risk of using a revoked certificate.

The way of distributing a CRL (via HTTP or LDAP) imposes the problem of network traffic. CRLs of large Trust Centers can reach big size (around 0,5 MB). Every client trusting a server of one of this large Trust Centers should download the complete CRL. This is not only a significant delay in accessing these websites for the user but also generates a very high network traffic. The solution to this maybe to allow caching of these CRLs for a longer time, but as mentioned before this imposes a higher risk of using revoked certificates.

The paper Towards Short-Lived Certificates identifies following four drawbacks in CRL.[2]

A study on real-world CRLs indicated that more than 30% of revocations occur within the first two days after certificates are issued. For CAs, there is a tradeoff between their CRL publishing frequency and operational costs. For CAs that update CRL with longer intervals, there is a risk of not blocking recently revoked certificates in time.
Since CRLs themselves can grow to be megabytes in size, clients often employ caching strategies, otherwise large transfers will be incurred every time a CRL is downloaded. This introduces cache consistency issues where a client uses an out-of-date CRL to determine revocation status.
Browsers have historically been forgiving to revocation failures (a.k.a “fail open”) so as not to prevent access to popular web sites in case their CAs are unreachable. In practice, they either ignore CRL by default, or do not show clear indications when revocation fails. Unfortunately, this lets a network attacker defeat revocation by simply corrupting revocation requests between the user and the CA.
It should also be noted that the location of the CRL (indicated by the CRL distribution point extension) is a noncritical component of a certificate description, according to RFC 5280. This means that for certificates without this extension, it is up to to the verifier to determine the CRL distribution point itself. If it cannot CRLs may be ignored.

More Information#

There might be more information for this subject on one of the following:

[#1] - using certs help - based on information obtained 2013-04-10
[#2] - Towards Short-Lived Certificates - based on information obtained 2016-05-11