CERTIFICATE REVOCATION LISTS
A CRL is a list of revoked certificates that have been issued and subsequently revoked by a given Certification Authority. Certificates may be revoked for a number of reasons including failure or compromise of a device that is using a given cert, compromise of the key pair used by a certificate, or errors within an issued certificate, such as an incorrect identity or the need to accommodate a name change. The mechanism used for certificate revocation depends on the Certification Authority. Most Certification Authorities support cert revocation from the management interface.
Figure 1
Cert Validation with CRL
Revoked certificates are represented in the CRL by their serial numbers. If a network device is attempting to verify the validity of a certificate, it will download and scan the current CRL for the serial number of the presented cert. The CRL is signed by the Certification Authority to ensure the authenticity of the document and may be distributed through a variety of protocols, such as http, ldap, tftp, or other services. CRLs are generally published on a periodic interval, or Certification Authorities may publish a new CRL any time a certificate they are responsible for is revoked. Like most documents created by a PKI, the CRL has an expiration time, date, and all components of a PKI that will verify that certificates should download a new copy of the CRL, when the old CRL expires. Cisco IOS Software based devices cache CRLs until they expire, than the router deletes the CRL from cache. A new, “fresh” CRL is downloaded when certificate is presented for verification again and the cached CRL has been deleted. Unfortunately, the router’s cached CRL causes one of the problems for using CRLs. If a newer version of the CRL that lists certificate under examination is present on the server, but the router is still using the CRL in its cache, which does not list the revoked cert, the certificate will pass its revocation check even though it should have been disallowed. The CRL may eventually grow to a cumbersome size in very large PKIs. Prior to its update PKI software, embedded in Cisco IOS Software, allocated roughly 64K of memory space for processing and caching CRLs, which was adequate under most circumstances for maintaining a local copy of the CRL. After the Cisco IOS PKI Software update, the Cisco IOS Software allocates memory until the local available memory is nearly consumed. If a PKI has revoked so many certificates that the CRL exceeds a cumbersome size, it is worthwhile to look into breaking the CRL into multiple files. This will save bandwidth and time when cryptography peers download a new copy of the CRL and will ensure that a Cisco IOS Software router will have sufficient buffer space to hold and scan the CRL for revoked certificates. The specific of dividing the CRL into a number of more manageable files is outside of this document’s scope; however, PKI documentation should offer design guidance for deploying the optimal CRL distribution scheme.
CRLs are practical for most PKI applications, but may not be appropriate for some uses. Some instances where CRLs are not adequate include:
- Large numbers of revoked certificates or multiple CRLs. CRLs in cache on devices can consume a large quantity of memory. Downloading large CRLs over low-speed links may use excessive bandwidth, which causes network congestion.
- Frequent CRL expiration. If CRLs expire frequently, the Certificate Distribution Point (CDP) will be heavily loaded, and frequent CRL download will burden network devices and bandwidth with non-production traffic.
- Immediate notification of cert revocation is required. Some high-security applications require more immediate notification of cert revocation. If CRL has a two day expiration interval, it may be up to 48 hours before a router downloads a new CRL. This leaves a long period of time before a router is notified that a certificate is no longer valid.
These are circumstances where CRL is an inadequate mechanism for cert revocation notification. In cases where CRLs are inappropriate for checking certificate status OCSP offers a better choice.
ONLINE CERTIFICATE STATUS PROTOCOL
OCSP addresses are some of the shortcomings of CRLs. They offer a real-time mechanism for certificate status checking. An end host can query the OCSP server when a cert is presented to find out if the certificate has been revoked. This resolves many of the issues that arise from the use of CRLs, but some other problems may appear from the use of OCSP. Some OCSP servers still use the CRL published by a Certification Authority to advise clients on the revocation status of a digital certificate, whereas other OCSP servers integrate tightly enough with the PKI to be able to query the certificate database directly for certificate revocation status. When crypto peers need to check the revocation status of certificates they transmit a query to the OCSP server with the serial number of the certificate in question. The OCSP server examines its copy or copies of the CRL to determine if the Certification Authority has listed the certificate as being revoked and replies with a message to the crypto peer that the certificate’s status is “revoked”, “good”, or “unknown”. This dialogue between the crypto peer and the OCSP server will consume less bandwidth than all, but the smallest of CRL downloads. It also consumes no memory on the crypto peer, as it will not have to cache the CRLs. In cases where an OCSP server relies on the CRL, the Certification Authority must only publish the CRL for the OCSP server’s use. This will allow CRL to be updated on a more frequent interval and to offer a more “real-time” certificate revocation status, without consuming large quantities of network bandwidth with frequent, large CRL downloads, to all the cryptographic peers in a network. If the OCSP server integrates directly with the PKI to have immediate access to certificate revocation information, cryptographic peers will receive an immediate response to certificate revocation status any time they query the OCSP server.
Cisco IOS Software Release 12.3(2)T added support for OCSP, so the command-line configuration was changed substantially to offer the capability of configuring multiple revocation checking mechanisms. If a PKI uses OCSP for revocation checking, the OCSP url will be contained in the PKI’s certificates. If the AAA revocation-checking location is not included in the certificates, the OCSP server’s url must be configured with the “ocsp url” statement. Cisco IOS Software Release 12.3(2)T also deprecated the “crl optional” and “crl best-effort”, replacing them with the “revocation-check” command. A trust point’s “revocation-check” configuration defines the order for consulting the various revocation mechanisms. A maximum of three options: “OCSP”, “CRL”, and “none” can be configured in preferential order. Configuration of “revocation-check ocsp none” or “revocation-check crl none” offers similar functionality to the previous “crl best-effort” command. In case the revocation check via CRL or OCSP times out, the router will accept the certificate if it has been presented during its validity period and it was issued by a trusted Certification Authority. “Revocation-check none” offers the similar functionality to “crl optional”, in which the CRL is not checked unless it has been manually loaded on a router. Cisco IOS Software Release 12.3(7)T added the capability to query multiple Certificate Distribution Points. Previous Cisco IOS Software releases queried only one CDP, regardless of the number of CDPs listed in a certificate. A capability to override the embedded CDPs with a configured CDP url was added in the Cisco IOS Software Release 12.3(7)T as well.