Understanding Windows PKI Certificate Revocation

One of the most important aspects in the design of a public key infrastructure (PKI) is certificate revocation or, more specifically, automated revocation checking. Certificate revocation ensures that the PKI system adds a certificate's serial number to a blacklist, called the certificate revocation list (CRL), when a PKI user's private key is compromised. Certificate revocation also guarantees that the PKI system efficiently distributes the revocation information to all PKI clients and PKI-enabled applications. If your PKI systems need to handle confidential or valuable information or transactions, you'll need to understand the process of revoking a certificate, Windows PKI-enabled application revocation checking support, and automated revocation-checking solutions. Let's begin by taking a closer look at CRLs.

Certificate Revocation Lists
The International Telecommunications Union Telecommunication Standardization Sector (ITU-T) X.509 standard and Internet Engineering Task Force (IETF) Request for Comments (RFC) 2459 define a CRL, which contains a timestamped list of revoked certificates that the Certification Authority (CA) signs and makes available to PKI users in a public repository. A CRL identifies each revoked certificate by its certificate serial number. The X.509 standard defines two primary types of CRLs: complete CRLs and delta CRLs.

Complete CRLs. In their most basic form, CRLs are known as complete CRLs (aka base CRLs or full CRLs). Complete CRLs tend to be huge because the revocation information accumulates over time. Although Windows CRLs support versioning, each new CRL version automatically inherits all revocation information from the preceding version. So, a CRL will grow in size until certificates start expiring. Also, with each new CRL version, the client must download the complete CRL, which isn't an efficient use of network bandwidth. As a result, many administrators configure longer CRL lifetimes to reduce the number of CRL versions. But long CRL lifetimes reduce the revocation information's timeliness because new revocation information isn't immediately available.

In Windows Server 2003, you can use delta CRLs, which I explain below, to get around the complete CRL deficiencies. To limit the size of complete CRLs in a Windows 2000 PKI environment, you can do one of three things:

Both Windows 2003 and Win2K publish CRLs at regular intervals. With both OSs, a CA administrator can also force the publication of a new CRL. To configure complete CRL publication intervals, open the Microsoft Management Console (MMC) Certification Authority snap-in, right-click the Revoked Certificates container, and select Properties from the menu to display the Revoked Certificates container's Properties dialog box, which Figure 1 shows. You can force the publication of the CRL by right-clicking the Revoked Certificates container in the Certification Authority snap-in and selecting the All TasksPublish menu option. This action opens the Publish CRL dialog box, which will ask you to specify which type of CRL you want to manually publish: a new CRL (i.e., a complete CRL) or a delta CRL.

To view a CRL's contents and format, select the View CRLs tab in the Revoked Certificates container's Properties dialog box. When you click View CRL or View Delta CRL from the View CRLs tab, you'll see the built-in CRL viewer, which Figure 2 shows. The General tab shows the layout of a complete CRL that a Windows 2003 or Win2K CA issued. Notice the presence of some typical CRL extensions, including Effective date, Next update, CA Version, CRL Number, Next CRL Publish, Freshest CRL, and Published CRL Locations. Click the Revocation List tab in the same dialog box to view a list of the revoked certificates on a CRL.

Delta CRLs. Windows 2003 resolves bandwidth and revocation information timeliness problems by introducing delta CRLs. RFC 3280 and RFC 2459 define delta CRLs, which are relatively small CRLs that contain only revocation changes made since the CA created the most recent complete CRL. Because delta CRLs are small, PKI clients can download them on a more frequent basis than complete CRLs, and the CA can provide more accurate revocation information to its clients. Only Windows XP Professional Edition and later Windows clients can check a certificate's validity against a delta CRL.

As with complete CRLs, Windows clients cache delta CRLs. If a complete CRL expires, the client retrieves a new complete CRL from the CRL Distribution Point (CDP) specified in the certificate (more on CDPs later). If the complete CRL is valid but the cached delta CRL is expired, a Windows client retrieves only the delta CRL from the CDP mentioned in the certificate.

Similar to the steps you take to manage complete CRLs, you configure delta CRL settings and view delta CRLs' content and formatting in the CA's Revoked Certificates container's Properties dialog box, which Figure 1 shows. Likewise, you follow the same procedure to manually force delta CRL publication as you use to manually force complete CRL publication.

Figure 3 shows the layout of a delta CRL that a Windows 2003 CA issued as it appears in the built-in CRL viewer. Notice the presence of the Delta CRL Indicator extension, which shows that this CRL is a delta CRL, not a complete CRL. The value in the Delta CRL Indicator extension is the number of the complete CRL that the delta CRL must be associated with. As with a complete CRL, a list of the revoked certificates on a delta CRL is available from the Revocation List tab.

Revoking a Certificate
A Windows CA administrator can revoke a certificate from the Certification Authority snap-in or from the command line. From the Certification Authority snap-in, open the Issued Certificates container, right-click the certificate you want to revoke, then select the All TasksRevoke Certificate menu option. To revoke a certificate from the command line, type the following command on the machine hosting your CA:

certutil –revoke  

When revoking a certificate, the CA administrator can specify a revocation reason code, as Web Figure 1 (http://www.winnetmag.com/windowssecurity, InstantDoc ID 41572) shows. Valid revocation reason codes are Unspecified, Key Compromise, CA Compromise, Change of Affiliation, Superseded, Cease of Operation, and Certificate Hold.

PKI-Enabled Application Revocation Checking Support
Not all Windows PKI-enabled applications automatically perform revocation checking. Also, revocation checking is sometimes dependent on an application-specific configuration setting. Table 1 provides an overview of how the most commonly used Windows PKI-enabled applications support revocation checking.

To enable revocation checking for Secure MIME (S/MIME) in Microsoft Outlook 2000 Service Release 1 (SR1), open the registry on the client, navigate to the HKEY_LOCAL_MACHINESOFTWAREMicrosoftCryptography{7801ebd0-cf4b-11d0-851f-0060979387ea} registry subkey, create a new entry called PolicyFlags (of type REG_DWORD), and set its value to 00010000. To enable revocation checking for IP Security (IPSec) in Win2K Service Pack 2 (SP2) and later, open the registry, navigate to the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesPolicyAgentOakley registry subkey, create a new entry called StrongCrlCheck (of type REG_DWORD), and set its value to 1 or 2. This registry entry's values have the following meanings:

Automated Revocation Checking
In the PKI world, different models are available for automated revocation checking. Most, with the exception of certificate revocation trees and the Online Certificate Status Protocol (OCSP), are based on complete CRLs, authority revocation lists, CDPs, enhanced CRLs, delta CRLs, and indirect CRLs. I don't have room to discuss all these methods, but for a good overview of automated revocation- checking methods, see Carlisle Adams and Steve Lloyd, Understanding Public-key Infrastructure: Concepts, Standards, and Deployment Considerations (Que Publishing, 1999).

As I mentioned earlier, Win2K PKI supports complete CRLs and CDPs. Windows 2003 PKI adds support for delta CRLs. Windows 2003 and Win2K also support specific Netscape revocation extensions.

A revocation requirement often mentioned in the IT industry is support for OCSP. As RFC 2560 defines, OCSP offers real-time certificate revocation information to all PKI users. Neither Windows 2003 nor Win2K supports OCSP out of the box. However, you can add support by using third-party software from vendors such as Alacris or Valicert (a division of Tumbleweed Communications). CDPs and delta CRLs offer a native Windows alternative to using OCSP.

CRL Distribution Points
CDPs offer a convenient way to automate revocation checking. Each certificate that a Windows 2003 or Win2K CA generates can include one or more CDPs. The CA stores CDPs in an X.509 certificate extension that it generates. A CDP can be an HTTP URL, a Lightweight Directory Access Protocol (LDAP) URL, or a file share. After the CA issues a certificate, you can't modify that certificate's CDPs. Figure 4 illustrates how CDPs work. The Certificate Server issues the certificate (shown in the figure connected by a dotted line) to the PKI clients and issues the CRLs (shown connected by a dashed line) to the CDPs. The certificate's CDPs point to the different CDP locations from which the client can download the CRLs.

A Windows PKI-enabled application that doesn't find a local copy of the complete CRL or delta CRL will check the certificate's CDPs for an up-to-date complete CRL or delta CRL. If a complete CRL or delta CRL is available from the CDPs, the application will download the CRL and cache it locally for the lifetime of the CRL. If the certificate doesn't contain any CDPs, the application will query the certificate's issuing CA for a complete CRL or delta CRL.

For CDPs to function correctly, not only is certificate and PKI-enabled application support required, but the CA must also support them. The CA must have an exit module that can publish the complete CRLs and delta CRLs to the appropriate file system, Web, or Active Directory (AD) CDP. By default, every Windows 2003 and Win2K CA includes an exit module that can handle CRL publication. Neither Windows 2003 nor Win2K can automatically publish complete CRLs or delta CRLs to HTTP CDPs—however, you can publish these types of CRLs manually.

Besides automated revocation checking, CDPs also can increase complete CRL and delta CRL availability. Each certificate can contain multiple CDPs so that if one CDP is unavailable, the PKI logic will try another CDP.

To configure the contents of a certificate's CDP fields, open the Certification Authority snap-in, right-click a Windows CA object, select Properties from the menu, then click the Extensions tab, which Figure 5 shows. To add a new CDP to the certificates that the CA issues, click Add. Table 2 describes the CDP-specific flags located at the bottom of the Extensions tab. You can configure the CDP field of a CA's proper certificate by using a capolicy.inf configuration file.

A convenient way to test CDPs embedded in a Windows X.509 certificate extension is to use the URL Retrieval Tool, which Web Figure 2 shows and which comes with the Windows 2003 version of the Certutil command-line tool. To access the URL Retrieval Tool, type

certutil -URL 

To retrieve complete CRLs and delta CRLs, select the CRLs (from CDP) option in the Retrieve section, then click Retrieve. Double-clicking one of the rows in the upper part of the URL Retrieval Tool opens the CRL viewer for the selected CRL. You can also use the URL Retrieval Tool to retrieve CA certificates mentioned in a certificate's Authority Information Access (AIA) field.

Netscape Revocation Extensions
Netscape uses a proprietary online certificate revocation checking method. The company embeds a custom extension, netscape-revocation-url, in all its certificates. Netscape-revocation-url points to a Web page that checks the certificate revocation. To send the revocation-checking request to the Web page, Netscape uses the HTTP GET method with a URL that concatenates netscape-revocation-url and the serial number of the certificate that needs to be checked. The response that comes back from the Web server is a document with Content-Type application/x-Netscape-revocation. The document contains one digit (either 1 if the certificate isn't valid or 0 if the certificate is valid). To enable a Windows 2003 or Win2K CA to issue certificates containing this extension, you must use the Certutil tool. From the command line, type

certutil -setreg Policyrevocationtype +AspEnable

You must also restart the CA service to make this change effective.

A Crucial PKI Service
Certificate revocation checking is a crucial PKI service, and reliable revocation checking is an important part of a trustworthy PKI service. Make sure you address revocation checking when you design your PKI environment. Both Windows 2003 and Win2K let you automate the certificate-revocation process, and Windows 2003 PKI includes some important enhancements in the revocation-checking space, so use them.