Basics: Checking the revocation status of certificates

If a valid, unexpired certificate is to be withdrawn from circulation, it must be revoked. For this purpose, the certification authorities maintain corresponding revocation lists in which the digital fingerprints of the revoked certificates are listed. They must be queried during the validity check.

Sometimes it is necessary for a certificate issued by a certification authority to be withdrawn from circulation even before its expiration date. To make this possible, a certification authority keeps a revocation list. This is a signed file with a relatively short expiration date, which is used in combination with the certificate to check its validity.

Certificate Revocation Lists (CRL)

In order to check whether the certificates issued by a PKI are still released for use, this information must be made available to the communication partners. If a certificate is revoked or blocked due to theft, for example, its serial number is stored in a Certificate Revocation List (CRL).

The following reasons can be given for revoking certificates:

Code	Designation	Description
0	Unspecified	This is the default setting and indicates that there is no specific reason for the revocation.
1	Key Compromise	The private key of a certificate was stolen or otherwise known to unauthorized third parties.
2	CA Compromise	The private key of the certification authority was stolen or otherwise known to unauthorized third parties.
3	Affiliation Changed	If the content of the certificate (e.g. the name of the user) has changed, a new certificate must be issued.
4	Superseded	The revoked certificate was replaced with a new certificate.
5	Cessation of Operation	The operation of the service belonging to the certificate was discontinued, for example, because there is a new service under a different name.
6	Certificate Hold	The certificate is revoked temporarily. This revocation type is the only one where the revocation can be subsequently undone.
8	Remove from CRL	If a certificate was revoked with reason "Certificate Hold" and delta revocation lists are used, the revoked certificate is kept in the delta revocation list with this code until the entry in the main revocation list is removed.
-1	Unrevoke	If a certificate has been revoked with reason "Certificate Hold", this code can be used to unblock it via command line. Likewise, in the auditEvent 4870 the undoing of a certificate revocation is marked with this code.

The continuous availability of the CRL is clearly more important than that of the CA itself: If the revocation status of a certificate must be checked by a computer and a valid CRL is not available at that time, the check fails. This is extremely critical, especially due to the very short validity periods of the CRL (usually a few days).

Up to three fields are available for determining the validity period of a CRL:

Designation (English)	Description
This update	This field contains the date on which the revocation list was signed, and thus its validity period begins. Microsoft certification authorities set the value ten minutes before the current time to compensate for differences in the system time (clock skew) of the various participants.
Next update	This field contains the date on which the revocation list becomes invalid and must be replaced by a new revocation list. Microsoft certification authorities set the value ten minutes into the future to compensate for differences in the system time of the various participants.
Next Publishing Date	This optional field contains the date on which a new revocation list should be issued by the certification authority. Clients that still have the old revocation list in their cache can continue to use it until the effective expiration date ("Next Update"), but have the option of already downloading a new revocation list (this function is called pre-fetching). The use of this field when issuing revocation lists is also called CRL overlapping.

The "Next Publishing Date" extension to the certificate revocation list is proprietary to the Microsoft Certification Authority. For this reason, it is marked as non-critical because it is not interpreted correctly by all applications.

The location from which the current CRL can be obtained (e.g. a web server) is announced via the CDP (Certificate Distribution Point) attribute within the certificates.

A clear disadvantage of using CRLs is that they can become very large over time if many certificates are revoked. A CRL should have the shortest possible validity period (often only a few days) for reasons of up-to-dateness and thus ultimately security.

The CRLs must be downloaded by all systems and applications performing revocation list validation each time they are updated, which can result in network utilization and corresponding wait times for certificate validation as the CRL grows.

The Microsoft Certification Authority removes the serial numbers of expired certificates from the issued revocation lists after their expiration in order to keep their size as small as possible.

The Microsoft Certification Authority Keeps all unexpired certificate revocation lists in the certification authority database. Thus, issuing certificate revocation lists too frequently can affect the size of the certification authority database.

This problem can be partially circumvented with delta CRLs. These files are generated at shorter intervals in addition to a regular CRL (the base CRL) and contain only the changes since the last publication of the base CRL. However, due to the short duration of delta CRLs, one must also plan for a significantly reduced response time in the event of a failure of the certification authority, so that the use of delta CRLs can only be recommended if appropriate personnel coverage and suitable emergency measures are defined.

A general problem with CRLs is that they must be kept in constant access. Typically, clients do cache a CRL, but shorter validity periods due to delta CRLs in particular also increase the number of times this cache is renewed. If a client cannot download a current CRL because the CDP is not available at that time and the copy in the cache has expired, the certificate to be checked is classified as untrusted.

Because of this problem, some browser manufacturers have now even gone so far as to no longer have their products check the revocation status of digital certificates on the Internet if the CRLs cannot be retrieved. However, this is not an option in a highly security-critical corporate environment.

Online Certificate Status Protocol (OCSP)

An alternative to revocation lists is the Online Certificate Status Protocol (OCSP).

Instead of downloading a (supposedly large) CRL, a client queries the revocation status for each certificate to be checked from a so-called online responder and receives a signed response indicating whether the certificate has been revoked or not.

For a detailed description see article "Basics of online responders (Online Certificate Status Protocol, OCSP)„.

Basics: Checking the revocation status of certificates

Certificate Revocation Lists (CRL)

Online Certificate Status Protocol (OCSP)

Related links:

External sources

13 thoughts on “Grundlagen: Überprüfung des Sperrstatus von Zertifikaten”