15.8 Certificate revocation

Some of the most important aspects in the design of a PKI are certificate revocation and, more particularly, automated revocation checking. Certificate revocation assures that a certificate’s serial number is added to a black- list (called the Certificate Revocation List [CRL]) when a PKI user’s private key is compromised. It also guarantees that the revocation information is distributed to PKI clients and PKI-enabled applications (PKA) in an efficient way. Automated revocation checking is critical for PKI systems that deal with confidential and/or valuable information or transactions. Next we examine in more detail the process of revoking a certificate, Windows PKA revocation checking support, and automated revocation checking solutions.

15.8.1 Revoking a certificate

A Windows CA administrator can revoke a certificate from the Certification Authority MMC snap-in or from the command line. In the CA MMC snap-in, open the Issued Certificates container and right-click the certificate you want to revoke; then select the All Tasks\Revoke Certificate menu option. To revoke a certificate from the command line, use the following certutil command:

Certutil –revoke <certificate serial number> <reason code>

A CA administrator may have different reasons to revoke a certificate: An employee may leave the organization, there may be a compromise or suspected compromise of a user’s private key, and so forth. When revoking a certificate, the CA administrator can select a revocation reason code (as illustrated in Figure 15.35). Valid revocation reason codes are unspecified, key compromise, CA compromise, change of affiliation, superseded, cease of operation, and certificate hold.

Figure 15.35: Certification revocation reason codes.

15.8.2 PKA revocation checking support

Not all Windows PKI-enabled applications (PKA) automatically perform revocation checking. Also, revocation checking sometimes depends on an application-specific configuration setting. Table 15.2 provides an overview of the most commonly used Windows PKA support revocation checking.

Table 15.2: PKA Revocation Checking Support

PKA	Revocation Checking Support
Internet Explorer (SSL-TLS)	Configuration option in Advanced tab of Internet Options: “Check for server certificate revocation (requires restart).”
Internet Explorer (Authenticode code signing)	Configuration option in Advanced tab of Internet Options: “Check for publisher’s certificate revocation.”
IIS (SSL-TLS)	IIS 5.0 and later have revocation checking enabled by default.
Outlook (S/MIME)	Enabled by default in Outlook 2002 and Outlook 2003. Can be enabled in Outlook SR1 using the registry hack outlined later.
IPsec	Not supported in Windows 2000. From Windows 2000 SP2 on, it can be enabled using the registry values outlined later.
EFS	Not supported in Windows 2000 EFS. Supported in Windows XP and Windows Server 2003 EFS when other users are added to the EFS settings of a file set up for EFS file sharing.
Smart Card Logon	The smart card logon authentication logic has revocation checking enabled by default.

To enable revocation checking for S/MIME in Outlook SR1, use the following registry hack: Create a REG_DWORD entry called “PolicyFlags” in the HKLM\SOFTWARE\Microsoft\Cryptography{7801ebd0-cf4b-11d0- 851f-0060979387ea} registry key and set it to value 00010000.

To enable revocation checking for IPsec in Windows 2000 SP2 and later platforms, use the following registry hack: Create a REG_DWORD entry called “StrongCrlCheck” in the HKLM\System\CurrentControlSet\Services\PolicyAgent\Oakley registry key and set it to value 1 or 2. This key’s values have the following meaning:

• 0: Disables CRL checking for certificate-based IPsec authentication.

• 1: Enables CRL checking and fails the validation process only if the CRL explicitly indicates that the certificate is revoked. All other failures, including when the CDP URL is unavailable, are ignored.

• 2: Enables CRL checking and fails certificate validation on any CRL check errors.

15.8.3 Automated revocation checking

In the PKI world, different models are available for automated revocation checking. Most of them, with the exception of Certificate Revocation Trees (CRTs) and the Online Certificate Status Protocol (OCSP), are based on Certificate Revocation Lists (CRLs). Examples are complete CRLs, Authority Revocation Lists (ARLs), CRL Distribution Points (CDPs), Enhanced CRLs, Delta CRLs, and Indirect CRLs. We will not discuss all of these methods, which are beyond the scope of this book. For a good overview of revocation checking methods, read the book Understanding Public-Key Infrastructure by Carlisle Adams and Steve Lloyd (Que, 1999).

Windows 2000 PKI supports complete CRLs and CRL Distribution Points (CDPs). Windows Server 2003 PKI adds support for Delta CRLs. Windows 2000 and Windows Server 2003 also support specific Netscape revocation extensions.

Both Windows 2000 and Windows Server 2003 publish CRLs at regular time intervals. In both environments a CA administrator can also force the publication of a new CRL (or delta CRL in Windows Server 2003). How to configure the CRL publication intervals and how to force CRL publication is explained next.

An often-heard revocation requirement is support for the Online Certificate Status Protocol (OCSP). OCSP offers real-time certificate revocation information to PKI users. The OCSP protocol is defined in RFC 2560. Neither Windows 2000 nor Windows Server 2003 support OCSP out of the box. Support can be added using third-party software from vendors such as Alacris (more information is available at http://www.alacris.com).

CRL distribution points

CRL distribution points (CDPs) offer a very convenient way to automate revocation checking. Each certificate generated by a Windows 2000 or Windows Server 2003 CA can include one or more CDP pointers. They are stored in the CRL Distribution Points X.509 certificate extension. A CDP can be a URL (HTTP or LDAP URL) or a file share. Once a certificate has been issued, its CDP pointers cannot be modified. The way CDPs work is illustrated in Figure 15.36.

Figure 15.36: Certificate revocation list distribution points (CDPs) operation.

A Windows PKA that is CDP-enabled will—if it does not find a local copy of the CRL or delta CRL—check the certificate’s CDPs for an up-to- date CRL or delta CRL. If a CRL or delta CRL is available from the CDPs, it will download it and cache it locally for the lifetime of the CRL or delta CRL. If a certificate does not contain any CDPs, the PKA will query the certificate’s issuing CA for a CRL or delta CRL.

In order for CDPs to function correctly, not only is certificate and PKA support required, but the CA should also support them. The CA must have an exit module that can publish the CRLs or delta CRL to the appropriate file system, Web, or Active Directory CDP. By default, every Windows 2000 and Windows Server 2003 CA includes an exit module that can handle CDP publication. None of them can automatically publish CRLs or delta CRL to HTTP CDPs—you can, however, do this manually. Exit modules were explained in Chapter 13.

Besides automated revocation checking, CDPs can also increase CRL or delta CRL availability. Each certificate can contain different CDPs: If one CDP is unavailable, the PKI logic will try another CDP.

The content of the CDP fields of the certificates a CA issues can be configured in the properties of a Windows CA object from the Extension tab (as illustrated in Figure 15.37). To add a new CDP, use the Add pushbutton. The Extensions tab also contains a set of CDP-specific flags (at the bottom of the dialog box) that are explained in Table 15.3. The CA certificate’s proper CDP field can be configured using a capolicy.inf configuration file (as was mentioned in Chapter 14).

Figure 15.37: Configuring CDPs.

Table 15.3: CDPs Flags

CDP Flag	Meaning
Publish CRLs to this location	Used by the CA to determine whether to publish base CRLs to this CDP URL (not available for HTTP CDPs).
Include in all CRLs	Not used during revocation checking: Specifies where to publish in AD when manually publishing using certutil -dspublish.
Include in CRLs	Clients use this during revocation checking to find delta CRL locations from base CRLs.
Include in CDP extension of issued certificates	Clients use this during revocation checking to find base CRL locations.
Publish delta CRLs to this location	Used by the CA to determine whether to publish delta CRLs to this CDP URL (not available for HTTP CDPs).

Complete CRLs

A CRL contains a time-stamped list of revoked certificates, which is signed by a CA and made available to PKI users in a public repository. In a CRL, each revoked certificate is identified by its certificate serial number. CRLs are defined in the ITU-T X.509 standard and RFC 2459.

CRLs in their most basic format are known as complete CRLs. They are also referred to as base CRLs or full CRLs. A Windows 2000 and Windows Server 2003 CA generates a complete CRL at predefined intervals. Complete CRLs tend to be huge because revocation information accumulates in each of them. Windows CRLs support versioning, but a new version automatically inherits all revocation information from the preceding version, so a CRL becomes no smaller until a certificate expires. Also, each new CRL version causes the client to download the complete CRL, which is not an efficient use of network bandwidth. As a result, many administrators configure longer CRL lifetimes, but long CRL lifetimes reduce the revocation information’s timeliness because new revocation information is not immediately available.

Testing a certificate’s CDPs A very convenient way to test the CDPs embedded in a Windows X.509 certificate is the URL retrieval tool. This tool comes with the Windows Server 2003 version of the certutil.exe command line tool. To bring up the URL retrieval tool type “certutil -URL <certificate_file_name>” at the command line. This action brings up the dialog box illustrated in Figure 15.38. To retrieve the CRLs and delta CRLs, check the Retrieve CRLs radio button, then click Retrieve. Double-clicking one of the rows in the upper part of the tool brings up the CRL viewer for the selected CRL. The tool can also be used to retrieve the CA certificates mentioned in a certificates AIA field.

Figure 15.38: The URL retrieval tool.

To limit the size of the complete CRLs in a Windows 2000 PKI environment, you can do one of these three things:

1. Define multiple CAs. If you define multiple CAs, with each CA having its own CRL, the size of those individual CRLs will be much smaller than the size of the CRL generated when you would have created just a single CA.

2. Generate certificates with a short lifetime. Windows 2000 CRLs are self-cleaning, which means that expired certificates are automatically removed from the CRL.

3. Generate a new CA key pair. Every time the CA key pair is renewed, a new CRL will be generated. The new CRL will be signed using the newly generated private key.

In Windows Server 2003, you can use delta CRLs to get around the complete CRL deficiencies. Delta CRLs are explained in the next section.

The complete CRL publication intervals can be configured from the properties of the Revoked Certificates container in the CA MMC snap-in (as Figure 15.39(a) shows). You can force a CRL publication by right- clicking the Revoked Certificates container and selecting All Tasks\Publish. This action brings up the Publish CRL dialog box requesting which type of CRL you want to manually publish: a new CRL (or complete CRL) or a delta CRL only.

Figure 15.39: Configuring (a) CRL publication intervals and (b) viewing CRLs.

To look at the content and formatting of a CRL, go to the View CRLs tab of the Revoked Certificates container properties (as illustrated in Figure15.39(b)).

Figure 15.40(a) shows the layout of a complete CRL issued by a Windows Server 2003 CA as it shows up in the built-in CRL viewer. Notice the presence of some typical CRL extensions: Effective date, Next update, CA Version, CRL Number, Next CRL Publish, Freshest CRL, and Published CRL Locations. A list of the revoked certificates on a CRL is available from the Revocation List tab (Figure 15.40(b)).

Figure 15.40: CRL (a) layout and (b) content.

Delta CRLs

Windows Server 2003 resolves the complete CRL problems (bandwidth impact and revocation information up-to-dateness) by introducing delta CRLs. As Figure 15.41 illustrates, delta CRLs are relatively small CRLs that contain only the revocation changes that have occurred since the most recent base CRL. Because delta CRLs are small, PKI clients can download them more regularly, and the CA can provide more accurate revocation information to its clients. Only Windows XP Professional and later Windows clients can check a certificate’s validity against a delta CRL. Again, delta CRLs are not a Microsoft invention; they are defined in RFCs 2459 and 3280.

Figure 15.41: Delta CRL operation.

As for complete CRLs, Windows clients also cache delta CRLs. If a base CRL expires, the client retrieves a new base CRL from the CDP that is specified in the certificate. If the base 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.

As for CRLs, you configure delta CRL settings and view delta CRLs’ content and formatting in the CA’s Revoked Certificates container’s properties (illustrated in Figure 15.39). The procedure that is used for manual CRL publication also applies to manual delta CRL publication.

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

Figure 15.42: Delta CRL layout.

Netscape revocation extensions

Netscape is using a proprietary online certificate revocation checking method. They embed a custom extension, the netscape-revocation-url, in all their certificates. The netscape-revocation-url points to a Web page where the certificate revocation can be checked. To send the revocation checking request to the Web page, Netscape is using the HTTP GET method with a URL that is the concatenation of the netscape-revocationurl 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. It contains a single digit that is 1 if the certificate is not valid or 0 if the certificate is valid.

To enable a Windows 2000 or Windows Server 2003 to issue certificates containing this extension, use the certutil tool: certutil -setreg Policy\revocationtype +AspEnable. You also have to restart the CA service to make this change effective.