Flylib.com

Books Software

 
 
 

15.6 Certificate retrieval


15.6 Certificate retrieval

Certificate retrieval deals with the way certificates are retrieved from a repository by a PKI user . In Windows 2000 and Windows Server 2003, certificates can be retrieved manually from any location in which the CA publishes them: from AD, a Web site, or a file share.

Windows 2000, Windows XP, and Windows Server 2003 also provide automatic retrieval of CA certificates during certificate validation. CA certificate download locations are mentioned in the Authority Information Access (AIA) certificate extension.

An interesting way for PKI users to retrieve their personal certificates from AD and store them in their local certificate store is dragging them from the Active Directory User Object to the Personal container in the Certificates MMC snap-in.

Personal certificates issued by a stand-alone CA can be retrieved from the CA’s Web interface. If certificates are not downloaded from the CA’s Web site within 10 days, they are purged. This default behavior can be modified by editing the certdat.inc file. By modifying the “nPendingTimeoutDays” setting in the certdat.inc file (located in the c:\winnt\system32\ certsrv directory), you can set the amount of days before a certificate is purged from the stand-alone CA’s Web site.



15.7 Key and certificate update

To provide better security, cryptographic keys and certificates should be updated regularly. Windows supports both manual and automatic key and certificate updating.

In Windows Server 2003, automatic certificate update is available for both machine and user accounts. Machine and user certificates that are set up for automatic enrollment will also be automatically updated when the autoenrollment event occurs.

To update your proper user keys and certificates manually, you must use the Certificates MMC snap-in. You can choose to renew an existing certificate using the same keys or using a newly generated key pair.

The manual updating of the keys and certificates of a Windows Certification Authority requires a special procedure that is discussed in Chapter 16 when we discuss CA rollover.



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.

click to expand
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).

click to expand
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.

click to expand
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.

click to expand

click to expand
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)).

click to expand

click to expand
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.

click to expand
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.

click to expand
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.