On This Page

Introduction
Components Used for Certificate Status Checking
The Effect of CA Certificate Renewal
Certificate Status Checking
Certificate Status Checking Details
Appendix A – Certificate and Certificate Chain Status Codes
Appendix B – Example CRL Dump
Appendix C – CRL Return Codes
Appendix D – CryptoAPI Policy Settings
Appendix E – Status Checking in a Single-Tier CA Topology
Appendix F – Status Checking for a Hierarchical CA
Appendix G – Status Checking for Cross-Certification
Appendix H – Status Checking for a Bridge CA
Related Links

Introduction

For certificate status to be determined, public key infrastructure (PKI) certificate revocation information must be made available to individuals, computers, network devices, and applications attempting to verify the validity of certificates. Traditionally, a PKI uses a distributed method of verification so that the clients do not have to contact the Certification Authority (CA) directly to validate the credentials presented. Instead, clients connect to alternate resources, such as Web servers or Lightweight Directory Access Protocol (LDAP) directories, where the CA has published its revocation information. Without checking certificates for revocation, the possibility exists that an application or user will accept credentials that have been revoked by a CA administrator.

Certificates are issued with a planned lifetime, which is defined through a validity start time and an explicit expiration date. For example, a certificate may be issued with a validity of one day, thirty years, or even longer. Once issued, a certificate becomes valid when its validity time has been reached, and it is considered valid until its expiration date. However, various circumstances may cause a certificate to become invalid prior to the expiration of the validity period. Such circumstances include change of name (for example, requiring to change the subject of a certificate due to an employee’s change of name), change of association between subject and CA (for example, when an employee terminates employment with an organization), and compromise or suspected compromise of the corresponding private key. Under such circumstances, the issuing CA needs to revoke the certificate.

There are several mechanisms to represent revocation information. RFC 3280 defines one such method. This method involves each CA periodically issuing a signed data structure called a certificate revocation list (CRL). A CRL is a list identifying revoked certificates, which is signed by a CA and made freely available at a public distribution point. The CRL has a limited validity period, and updated versions of the CRL are published when the previous CRL’s validity period expires. Each revoked certificate is identified in a CRL by its certificate serial number. When certificate-enabled software uses a certificate (for example, for verifying a remote user's digital signature), the software should not only check the certificate signature and time validity, but it should also acquire a suitably recent certificate status to ensure that the certificate being presented is not revoked. Normally, a CA will automatically issue a new CRL on either a configured, regular periodic basis (for example, daily or weekly), or the CRL can be published manually by a CA administrator.

Microsoft^® Windows^® clients support the following types of CRLs.

• Base CRLs.  Confirms the status of all certificates that have been issued by a given CA.

• Delta CRLs.  Contains only certificates that have changed status since the issuance of the last base CRL.

• Partitioned CRLs.  Windows clients that are currently supported within the Microsoft lifecycle can support partitioned CRLs through the use of the Issuing Distribution Point (IDP) extension. A Windows client only supports the onlyContainsUserCerts and onlyContainsCACerts fields to recognize CRLs that only contain user certificates or only contain CA certificates.

Note  Microsoft CAs do not support the IDP extension for Windows Server 2003 Certificate Services. A Windows Server 2003 CA will only issue base or delta CRLs.

The base and delta CRLs are published at distribution points. The base or delta CRLs can be published to distribution points like Web servers or directory services like Active Directory^® or Active Directory Application Mode (ADAM) using LDAP.

Scope and Audience

This white paper is intended to help organizational system architects and administrators understand how certificate chaining and revocation work in Windows 2000, Windows XP, and the Windows Server 2003 family. This understanding will enable administrators to troubleshoot problems related to certificate chaining and revocation. For more information about PKI and Certificate Services, see
http://www.microsoft.com/pki

Note  This white paper assumes that you have applied MS04-011 to all Windows 2000 Professional and Windows 2000 Server computers. The MS04-011 update changes the Windows 2000 certificate chaining engine to match the functionality of the Windows XP SP2 and Windows Server 2003 Certificate Chaining engines.

Terms Used in This White Paper

Authority Information Access (AIA)  A certificate extension that contains information useful for verifying the trust status of a certificate. This information potentially includes Uniform Resource Locations (URLs) where the issuing CA’s certificate can be retrieved, as well as a location of an Online Certificate Status Protocol (OCSP) responder configured to provide status for the certificate in question. The AIA extension can potentially contain HTTP, LDAP, or file URLs.

Authority Key Identifier (AKI)  A certificate extension used by the certificate chaining engine to determine what certificate was used to sign a presented certificate. The AKI can contain the issuer name, serial number, public key information, or no information at all. By matching the information in a certificate’s AKI extension to a CA certificate’s Subject Key Identifier (SKI) extension, a certificate chain can be built.

Certificate Chaining  A process that builds one or more certificate paths. The certificate paths may or may not trace up to a self-signed or root certificate.

CRL Distribution Point (CDP)  A certificate extension that indicates where the certificate revocation list for a CA can be retrieved. It can contain none, one, or many HTTP, file, or LDAP URLs.

Certificate Revocation List (CRL)  A digitally signed list issued by a Certification Authority (CA) that contains a list of certificates issued by the CA that have been revoked. For each individual revoked certificate, the listing includes the serial number of the certificate, the date that the certificate was revoked, and the revocation reason. Applications can perform CRL checking to determine a presented certificate’s revocation status.

Certificate Trust List (CTL)  A method of restricting certificates chaining to a designated CA for limited time periods or usages. CTLs are used more prevalently in a Windows 2000 network. In a Windows Server 2003 network, cross-certification is the preferred method for restricting certificate usage between organizations. For more information, see the “Planning and Implementing Cross-Certification and Qualified Subordination Using Windows Server 2003” white paper referenced in Related Links.

Certificate Trust Validation  A process that determines if a certificate chains to a root CA certificate that is trusted by the actual security context.

Issuing Distribution Point (IDP)  Allows the implementation of partitioned CRLs. The IDP extension indicates if the CRL is limited to revocations for end-entity certificates or for CA certificates. In some Microsoft documentation, the IDP is also referred to as the Issuer Distribution Point.

Online Certificate Status Protocol (OCSP)  A protocol that allows real-time validation of a certificate’s status by having the CryptoAPI make a call to an OCSP responder and the OCSP responder providing an immediate validation of the revocation status for the presented certificate. Typically, an OCSP responder responds with the revocation status check request based on the CRLs or other forms of revocation status it retrieves from the CAs.

Public Key Infrastructure (PKI)  Provides an organization with the ability to securely exchange data using public key cryptography. A PKI consists of Certification Authorities (CAs) that issue digital X.509 version 3 certificates and directories that can store the certificates (including Active Directory in Windows 2000 and Windows Server 2003). The PKI provides validation of certificate-based credentials and ensures that the credentials are not revoked, corrupted, or modified.

Subject Key Identifier (SKI)  A certificate extension that contains a hash of the CA’s certificate public key. This hash is placed in the Authority Key Identifier (AKI) extension of all issued certificates to facilitate chain-building.

Components Used for Certificate Status Checking

The following sections outline the components used by the Windows operating system when performing certificate status checking. These components include:

• CryptoAPI

• Certificates

• Certificate Stores

• Root Store Trust

• NTAuth Store

• Certificate Revocation Lists

• CRL Distribution Point Extensions

• Cross-certification

CryptoAPI

CryptoAPI provides services that enable application developers to add security to applications. It includes functionality for encoding to and decoding from ASN.1, encrypting and decrypting data, and for authentication using digital certificates.

The certificate processing functionality of CryptoAPI is implemented in crypt32.dll and cryptnet.dll. Both libraries provide a rich set of application programming interfaces (APIs). For a programmer’s reference to CryptoAPI, see the Microsoft Developer Network article on Cryptography Functions in Related Links.

Since cryptography functionality in Windows is constantly improved, CryptoAPI is available in a number of different versions. The versions differ slightly in their certificate status checking functionality. Some support features like delta CRLs and others do not, as shown in Table 1.

Table 1.  Certificate Status Checking Functionality of CryptoAPI

Windows Version	Crypt32.dll version	Cryptnet.dll version	Types of CRLs Supported
Windows 2000	5.131.2173.1	5.131.2157.1	Base CRLs only
Windows 2000 with MS04-011	5.131.2195.6824	5.131.2195.6824	Base and delta CRLs
Windows XP	5.131.2600.0	5.131.2600.0	Base and delta CRLs
Windows XP SP1	5.131.2600.1106	5.131.2600.1106	Base and delta CRLs
Windows XP SP2	5.131.2600.2180	5.131.2600.2180	Base and delta CRLs
Windows Server 2003	5.131.3790.0	5.131.3790.0	Base and delta CRLs
Windows Server 2003 SP1	5.131.3790.1824	5.131.3790.1824	Base and delta CRLs

As shown in Table 1, the Windows 2000 hotfix MS04-011 updates the CryptoAPI on Windows 2000 computers. This update to the CryptoAPI is a major update for Windows 2000, as it back-ports the certificate path processing functionality of Windows XP and Windows Server 2003 to Windows 2000.

The update ensures consistent certificate path processing for Windows 2000, Windows XP, and Windows Server 2003 computers on your network. The update specifically changed the following aspects of certificate path processing for Windows 2000 computers.

• HTTPS and LDAPS URLs are no longer supported as distribution point references. HTTPS and LDAPS URLs use certificates that may or may not be revoked. The revocation checking process can result in revocation loops when HTTPS or LDAPS URLs are used. To determine if the certificate is revoked, the CRL must be retrieved. However, the CRL cannot be retrieved unless the revocation status of the certificates used by HTTPS or LDAPS is determined.

  Note  HTTPS URLs are also rejected by the Windows XP and Windows Server 2003 CryptoAPI.

• File Transfer Protocol (FTP) URLs are no longer supported for AIA and CDP extensions.

• Default network timeouts have changed. The new defaults are a maximum of 15 seconds for each network retrieval and 20 seconds overall for certificate path validation.

• A maximum of five URLs are allowed in the AIA extension for every certificate in the certificate chain. In addition, a maximum of 10 URLs for the entire certificate chain is also supported. This limitation on the number of URLs was added to mitigate the potential use of “Authority Info Access” references in denial of service attacks.

  Note  The maximum URLs behavior described previously does not apply to the Windows XP prior to Service Pack 2 and Windows 2000 without MS04-011 applied. For information about all Cryptography API (CAPI) registry and policy settings, see Appendix D.

• Certificate chains that rely on cross-certificate discovery and inclusion are supported.

• Delta CRLs are fully supported.

• Certificates from foreign CAs that include IDP extensions with only the onlyContainsUserCerts or only ContainsCACerts fields are supported.

• Name and policy name constraints are implemented providing support for cross-certification and enforcement of cross-certification constraints.

• Critical flags in CRLs are respected.

• Base64-encoded CRLs are properly processed.

• X.500 style distinguished names (DNs) for CRL and AIA references are supported.

• The CryptoAPI no longer uses the Internet Explorer cache. Instead, the CryptoAPI maintains a separate cache at
  C:\Documents and Settings\{user name}\Application Data\Microsoft\CryptnetUrlCache

Certificates

A certificate securely binds a public key to the entity that holds the corresponding private key. A certificate is commonly used for authentication and secure exchange of information on open networks, such as the Internet, extranets, and intranets. Certificates are digitally signed by the issuing CA and can be issued for a user, a computer, or a service. The most widely accepted format for certificates is defined by the ITU-T X.509 version 3 international standards.

A certificate is a collection of certificate attributes and extensions that can be stored as a file or is maintained in a certificate store. The set of fields in a certificate may vary depending on the certificate request and the certificate template that was used to issue the certificate.

Generally, it is the responsibility of a security-enabled application to interpret the content of a certificate or to use a sub-system like CryptoAPI to verify the status of a certificate.

Fields in a certificate can be marked as critical or non-critical when the certificate request is created. The CryptoAPI engine does not enforce critical extensions in certificates. The CryptoAPI engine and programming model puts the responsibility of parsing critical extensions on the calling application. Therefore, an application must understand and enforce a critical extension when it evaluates a certificate.

Note  The default behavior of an application, as defined in RFC 3280, should be to reject a certificate if the certificate contains a critical extension not understood by the application. It is still possible for an application to accept a certificate that contains a non-critical extension that is not understood by the application.

Certificate Stores

Windows maintains certificates in certificate stores. These stores can be represented by containers in the file system, in the registry, or implemented as physical stores such as smart cards. Certificate stores are associated either with the computer object or they are owned by a distinct user who has a security context and profile on that computer. In addition, services can have certificate stores the same as user accounts. A certificate store will often contain numerous certificates, possibly issued from a number of different CAs.

A computer (local system) has read and write permissions to the personal certificate store that belongs to the computer. A user who owns certificate stores also has read and write permissions to their own personal store and read-only access to the certificate stores that are owned by the computer. The Certificates console display merges the two views, showing both the certificate stores that belong to the computer as part of the certificates node of the current user. A user without local administrative permissions has no access to certificate stores that are owned by services.

Note  Only members of the local Administrators group have the ability to manage certificate stores that are owned by the computer or a service.

The advantage of sharing certificate stores between the computer and the user is to reduce the total number of certificates that have to be stored in all certificate stores on a computer.

Certificate chains are formed by looking at certificates available in multiple certificate stores. The certificate chaining engine must determine what scope of certificate stores to search when building certificate chains. By default, the chain engine searches the Trusted Root Certification Authorities, “Enterprise Trust”, Intermediate Certification Authorities, and “Personal” certificate stores (Figure 1). The certificate stores may be viewed through the Certificates snap-in (Certmgr.msc) in the Microsoft Management Console (MMC).

Note  You can open the Certificates console focused on the Current User on a Windows XP or Windows Server 2003 by opening Certmgr.msc in the Run dialog box. On a Windows 2000–based computer, you must open an empty MMC console, and then open the Certificates snap-in focused on the Current User.

Each of these certificate containers has physical sub-containers. These sub-containers maintain certificates according to their origin. A user may have added certificates to his or her profile. These certificates are stored in the physical container called “Registry”. The user may have downloaded certificates from Active Directory. These certificates are stored in the “Group Policy” container. And, as mentioned previously, the user has read access to some of the computers certificate stores that are shown as the physical certificate store “Local Computer”.

The number of certificates per store is limited by the total registry size and performance. Larger amounts of certificates within a store can result in performance problems because all certificates within the store are decoded into memory when the certificate store is opened.

Note  Microsoft has tested stores with 1300 certificates with no performance problems.

When CryptoAPI needs to discover a certificate, it can use any store where the current security context has read permissions. By default though, the CryptoAPI only looks at the Trusted Root Certification Authorities, “Enterprise Trust”, Intermediate Certification Authorities, and “Third-party Root Certification Authorities” stores for both the current user and the local machine during path processing.

In addition to the default stores, the certificate chaining engine can be configured to use different stores. While the Trusted Root Certification Authorities store is the only store that can contain trusted root certificates, an application can use other stores, such as restricted root, restricted trust, restricted other, and additional stores to further restrict the set of root certificates considered trusted. For example, the “Trusted People” store is used by both Microsoft Outlook and Encrypting File System (EFS) when searching for certificates. If a certificate is found in the “Trusted People” store, Outlook and EFS will ignore a non-trusted root error returned by the CryptoAPI.

Also, an application can create its own store for certificate storage or even call additional revocation providers registered with CryptoAPI. In addition to which certificate stores are searched during a chain validation call, the certificate chaining engine can also be configured with the following parameters programmatically.

• Maximum number of cached certificates. The default value is 256.

• A specific store to use. The certificate chain can be built using either the current user or local machine stores.

• URL retrieval settings. The certificate chaining engine can be set to bypass URL retrieval based on URLs included in the AIA or CDP extension of an evaluated certificate, and use only cached certificates.

• End certificate caching. Allows the end certificate in the certificate chain (that is, the certificate that caused the validation call) to be cached.

• Cyclic chain settings. This setting defines at what number of certificates a chain should be checked for being a cyclic chain.

• Timeout settings. Sets the timeout period that should be used when accessing a CRL URL. The default value is 15 seconds for the first URL and 20 seconds for the cumulative retrieval for all available URLs.

• Thread settings. Configures whether a separate thread of execution is used for store synchronization.

These parameters are set by the calling application using various APIs, including CertGetCertificateChain and CertVerifyRevocation.

Note  For more information about these APIs, search for CertGetCertificateChain and CertVerifyRevocation at
http://msdn.microsoft.com/library

Note  For more information about the certificate trust status, see the MSDN library at
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/security/security/cert_trust_status.asp

Logical and Physical Certificate Stores

Certificate management tools distinguish between the physical structure of certificate stores and their logical abstraction. The logical abstraction, which simplifies the physical structure, was implemented to group certificates by function or purpose and provided a simpler way to understand certificate stores.

Unfortunately, today, different certificate tools exist to maintain certificate stores. Users may prefer one tool over the other to maintain their certificates. The following list briefly explains the tools and their capabilities.

• Internet Explorer  Does not show the physical structure of certificate stores. Only logical certificate stores are visible through Internet Explorer. The certificate management interface in Internet Explorer can be accessed through the Tools menu item Internet Options in the Content tab or can be accessed directly from the command line. To do so, type rundll32 cryptui.dll CryptUIStartCertMgr at a command-line prompt and press ENTER.

• The Console Certificates and Public Key Management  Can show the physical structure of subcontainers for each Default certificate store if the Physical Stores option is enabled in the View Options. If this option is disabled, the physical structure is collapsed into a logical structure, which is the default setting.

• Registry Editor  Shows some of the physical certificate store structures.

  Note  It is not recommended to modify or manage the contents of a certificate store by using the Registry Editor (regedt32.exe).

• Certutil  Refers to certificate stores by labels that are equal to the store names in the registry or LDAP directory.

If certificates are written to certificate stores, the physical structure is more important than the logical structure. The system expects certificates at predefined physical locations. Even if a certificate seems to be at the right logical position, it might not be at the right physical location. For example, a certificate might be stored in a user’s personal store where it is expected to be in the computer’s personal store. Since the logical view forms a union of both stores, the users might not recognize the actual physical location of a certificate.

Each certificate store can physically have a number of subcontainers. The Certificates console knows the following physical store names. The stores are invisible by default and show up only if the physical certificate store view has been turned on.

• Registry  Depending on which certificate store is opened, certificates in the container named Registry belong to the computer or current user. Usually, a locally accessible private key is associated with these certificates.

• Group Policy  Certificates that are part of this container have been received through Group Policy objects (GPOs) from Active Directory. Depending on the GPO configuration, the content of this container varies.

• Third-Party  This container exists only in the Trusted Root Certification Authorities certificate store. It keeps certificates from CAs that participate in the Microsoft Root Certificate Program.

• Enterprise  Certificates that have been added to the Active Directory configuration container are maintained in the Enterprise container. Primarily, CA certificates appear in this container. CA certificates can be added manually to the CA configuration or are added to the Enterprise configuration when an Enterprise CA is installed.

• Local Computer  This container is only shown in the Certificates - Current User certificate store or Certificates - Service certificate stores, not in the LocalComputer certificate store. This subcontainer keeps all the certificates that are in the local computer’s certificate store for the parent container (for example, “Enterprise Trust”).

The logical view does not distinguish between the current user’s and the local computer’s Registry physical store. Regardless of whether a certificate is physically stored in the local machine’s Registry container or the current user’s Registry container, the user will see all certificates in those containers in a single view.

Generally, it is recommended to know the physical structure of certificate stores because it enables the administrator to maintain certificates at the right physical location.

Different tools use different names for the same certificate store. Table 2 shows the names that are used by these tools.

Table 2.  Certificate Store Labels

MMC Certificate Store Name	Registry Editor	Internet Explorer	Supported With
Personal	My	Personal	Windows 2000 or later
Trusted Root Certification Authorities	Root	Trusted Root Certification authorities	Windows 2000 or later
Enterprise Trust	Trust	n/a	Windows 2000 or later
Intermediate Certification Authorities	CA	Intermediate Certification Authorities	Windows 2000 or later
Active Directory User Object	UserDS	n/a	Windows 2000 or later
Trusted Publishers	TrustedPublisher	Trusted Publishers	Windows XP or later
Un-trusted Certificates	Disallowed	n/a	Windows XP or later
Third-Party Root Certification Authorities	AuthRoot	n/a	Windows XP or later
Trusted People	TrustedPeople	n/a	Windows XP or later
Other People	Addressbook	Other People
Certificate Enrollment Requests	REQUEST	n/a	Windows 2000 or later
_NMSTR	_NMSTR	n/a
SPC	SPC	n/a	Windows 2000 or later
	NTAuth	n/a
	SMS	n/a

The following list explains the logical certificate stores by name.

• Personal  This certificate store maintains certificates that belong to a user or a computer. By default, this store is empty. Certificates are added here when a file is encrypted using the encrypting file system (which results in a self-signed certificate), or a certificate is received through an autoenrollment event, or a certificate has been requested or imported manually.

• Trusted Root Certification Authorities  The container that belongs to the local computer keeps root certificates that are trusted by default. For the current list of root certificates that are distributed with Windows, see the Microsoft Web site at
  http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsecure/html/rootcertprog.asp The certificate update service in Windows XP and Windows Server 2003 will add certificates on demand to this store. In Windows 2000, there is no such update service and trusted root certificates can be updated through Windows update functionality. The container that belongs to the user is empty by default; however, if the physical view is not turned on in the Certificates console, you will see the certificates that are stored in the local computer’s container.

• Enterprise Trust  The Enterprise Trust containers owned by the local computer and the current user are empty by default. This is a container for certificate trust lists. For example, if you are running an instance of Key Management Server (KMS), its certificate trust lists appear in this container.

• Intermediate Certification Authorities  This container keeps many different types of CA certificates. CA certificates that are parent certificates of issued certificates are stored here (found in the AIA container). Also, certificates that have been published into the Enrollment Services container in Active Directory (CN=Enrollment Services,CN=Public Key Services,CN=Service,CN=Configuration,DC=...) or the NTAuth container (CN=NTAuthCertificates,CN=Public Key Services,CN=Service,CN=Configuration,DC=...) are available in the Intermediate Certification Authorities container.

• Active Directory User Object  Certificates associated with a user object and published in Active Directory. The content of this container is equal to the certificates that are shown in the advanced view of the “Active Directory Users and Computers” console when the properties of a user object are viewed.

• Trusted Publishers  Certificates from CAs that are trusted by Software Restriction policies.

  Note  For more information about Software Restriction policies, see “Using Software Restriction Policies to Protect Against Unauthorized Software” at
  http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/rstrplcy.mspx

• Un-trusted Certificates  In this container, two certificates are available by default. For more information about these certificates, see the Microsoft Knowledge Base at
  http://support.microsoft.com/?id=293817
  Also, these are certificates that you have explicitly decided not to trust using either Software Restriction policies or by clicking “Do not trust this certificate” when the decision is presented to you in Outlook or Internet Explorer.

• Third-Party Root Certification Authorities  This certificate store is similar to the Trusted Root Certification authorities. It keeps the certificates from the Microsoft Root Certificate Program.

• Trusted People  Certificates issued to people or end entities that are explicitly trusted. Most often, these are self-signed certificates or certificates explicitly trusted in an application such as Outlook. To share an EFS–encrypted file with other parties, you must have their certificate in this store.

• Other People  This container maintains certificates that have been added to an Outlook contact.

• Certificate Enrollment Requests  When a certificate request was submitted to a certification authority but the certificate has not been accepted by the client, the certificate request is stored in this container.

• _NMSTR  This container belongs to NetMeeting and is empty by default.

• SPC  This container exists only in the local machine’s certificate store and maintains Software Publisher Certificates (SPC). The container is empty by default. This store has been deprecated; SPCs should be stored in the user’s Personal store.

• SMS  If a workgroup computer is a Microsoft Systems Management Server (SMS) client, a self-signed certificate will appear in this container.

Note  If you are importing a certificate along with a private key (a .pfx file), it will go to the Personal store. If it is an end-entity certificate for which you do not have a private key, it will go in the Other People store. If it is a CA certificate and not a root (self-signed), it will go to the Intermediate Certification Authorities store. If it is a self-signed certificate, it will go to the Trusted Root store. In all cases, a user can change the described default behavior by designating a specific store when running the Certificate Import wizard.

Root Store Trust

On Microsoft platforms, certificates are validated using the CryptoAPI certificate stores. A certificate store is a location where related certificates are stored. The root store is the certificate store used to establish trust when certificates are validated. Microsoft ships a set of root certificates built into the root store from commercial CA's like Verisign and Thawte. There are over 100 such built-in root certificates.

Root Store Management Models

There are four models for managing the root store.

• Use certificates accepted by the Microsoft Root Certificate Program.

• Manage the list of root trust for a single computer.

• Manage the list of root trust for a single domain.

• Manage the list of root trust for an entire forest.

Use Certificates Accepted by the Microsoft Root Certificate Program

Under this management model, the customer accepts the default choice of root certificates provided by Microsoft. If running Windows XP or Windows Server 2003, the customer should ensure the Update Root Certificates option is enabled as shown in Figure 2.

For Windows 2000 and earlier versions, a patch is available for download from the Windows Update Web site.

Manage the List of Root Certificates for a Single Machine

Customers can choose to customize the list of trusted root certificates trusted on a single machine. In Windows 2000, Windows XP, and Windows Server 2003, this is accomplished by using the Certmgr.msc snap-in to manage their list of root certificates. In addition, they can use the Certificate Manager launched from Internet Options > Content > Certificates in Internet Explorer.

On a single machine, the root certificates can be added to either the local machine store or to the current user store.

• If added to the local machine trusted root store, the root certificate is trusted by all users of the computer.

• If added to the current user trusted root store, the root certificate is only trusted by that user. If another user were to log on to the computer, the root certificate would only be trusted if the certificate was also added to the current user trusted root store.

Manage Root Certificates for an Entire Domain or OU

If Administrators want to customize the list of root certificates trusted by machines in their domains, they can distribute additional root certificates through Group Policy objects that are linked to domains or organizational units (OUs).

Note  Although you could define Trusted Root Certification Authorities for a site, it is not typically implemented through GPOs linked to a site.

When trusted root certificates are defined in a GPO, they are defined in the Computer Configuration container shown in Figure 3.

In addition to defining which root authorities are trusted in the domain or OU where the GPO is linked, you can also define whether the 100 plus commercial CAs that ship in the box are trusted by computers where the GPO is applied. To prevent trust of the third-party root CAs, ensure that "Client computers can trust the following certificate stores" option is set to "Enterprise Root Certification Authorities" as shown in Figure 4. This option will effectively turn off the "Update Root Certificates" feature on Windows XP as all the certificates it downloads are stored in the “Third Party Root Certification Authorities” certificate store.

Manage the List of Root Certificates for an Entire Forest

If Administrators want to customize the list of root certificates trusted by all machines in their forest, it is recommended to publish the root certificates in Active Directory in the Enterprise Trust Store, When a root certificate is published in Active Directory by using the Certutil.exe command, the certificate is published into the CN=Certification Authorities,CN=Public Key Services,CN=Services,CN=Configuration,ForestRootLDAPName container.

Note  The actual command used to publish the root certificate in Active Directory is
Certutil –dspublish –f RootCertFileName.crt RootCA

Windows 2000, Windows XP, and Windows Server 2003 domain member computers will automatically download these certificates using the built-in autoenrollment service.

NTAuth Store

The NTAuth store defines trust between domain controllers and CAs. A CA that is included in the NTAuth store is considered trusted for issuing authentication certificates.

After a certificate is validated by the certificate chaining engine, the client ensures that the domain controller’s (DC) certificate is included in the NTAuth store. In addition, the DC ensures that the CA that issued the user’s certificate is also in the NTAuth store. This provides a form of mutual authentication between the user and the domain controller, ensuring that the certificates were issued by a trusted source.

The user’s certificates must be issued from a CA included in the NTAuth store for the following applications.

• Smart Card Logon

• Internet Information Services (IIS) certificate-based authentication

• Any application that uses Internet Authentication Services (IAS) for authentication. This can include Virtual Private Networking (VPN), dial-up networking, 802.1x wireless networking, and 802.1x wired networking.

Certificate Revocation Lists

A CRL is a file, created and signed by a CA, which contains serial numbers of certificates that have been issued by that CA and are revoked. In addition to the serial number for the revoked certificates, the CRL also contains the revocation reason for each certificate and the time the certificate was revoked.

Today, two types of CRLs exist (per RFC 3280). Base CRLs keep a complete list of revoked certificates while delta CRLs maintain only those certificates that have been revoked since the last publication of a base CRL.

A Microsoft CA publishes certificate status information in the form of CRLs. Third-party products use this information to provide revocation information in other formats such as OCSP, Simple Certificate Validation Protocol (SCVP), and XML Key Management Specification (XKMS). These alternative revocation providers are possible because CAPI is built on a pluggable revocation provider model.

Note  For more information about pluggable revocation providers for CAPI, see
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsecure/html/rpcrypto.asp 

A CRL can be viewed through the Certificates MMC console or can be dumped with the Certutil.exe command. For an example of a CRL dump, see Appendix B.

CRL Format

CRLs that have been generated with a Microsoft CA follow the version 2 CRL format.

Note  The version 1 CRL format is not supported by Microsoft.

A CRL that was generated by a Microsoft CA includes the following fields.

• Version  The version of formatting used for the CRL. At this time, version 2 is the only possible version.

• Issuer  The issuing CA’s DN represented using an X.500 DN such as “cn=CA11,dc=contoso,DC=com” or “CN=CA11,O=Contoso Limited,C=US”.

• Effective Date  The date that this CRL became effective. UTCTime format is used for date up to the year 2049. Generalized Time format is used for dates in the year 2050 and beyond. The effective time, by default, is set to 10 minutes prior to the current date and time to allow for clock synchronization issues.

• Next Update  The date and time that a Windows client considers as the expiration date of the CRL. The same date formatting rules are used for “Effective Date”.

• CRL Entries  A sequence of zero or more revoked certificates with the following fields represented for each revoked certificate.

  • Serial Number  The serial number assigned by the issuing CA for each revoked certificate.

  • Revocation Date  The date of the revocation.

  • Extensions  An optional field that contains version 2 extensions for CRLs that provides additional information about a single CRL entry. Version 2 CRLs are described fully in RFC 3280.

  • CRL Reason Code  Identifies the reason for the certificate revocation. Reasons can include: unspecified, keyCompromise, CACompromise, affiliationChanged, superseded, cessationOfOperation, certificateHold, and removeFromCRL. For more information about CRL reason codes, see the CRL Reason Codes section.

  • HoldInstructionCode  This option, as defined in RFC 3280, indicates the action to be taken if the ReasonCode is defined as CertificateHold. This extension is not supported by the Windows Server 2003 CA.

  • InvalidityDate  The date it is known, or suspected, that the private key associated with the certificate was compromised. This extension is not supported by the Windows Server 2003 CA, but is understood by Windows 2000 with MS04-11, Windows XP, and Windows Server clients.

  • CertificateIssuer  An optional field that indicates which CA issued the certificate if indirect CRLs have been implemented. The Windows Server 2003 CA does not implement this extension, but it is supported by Windows 2000 clients with the MS04-11 update installed, Windows XP clients, and Windows Server 2003 clients when included by third-party CAs.

• CRL Extensions

  Within an issued CRL, a CA includes the following extensions.

  • AuthorityKeyIdentifier  A numeric representation of the issuer name and serial number from the CRL issuer’s certificate that is used in the certification chain-building process. Windows 2000 clients without the MS04-11 update installed do not recognize this extension in the CRL.

  • IssuerAltName  An optional field that allows alternative identities to be associated with the issuer. This can contain a Domain Name System (DNS) name or a Uniform Resource Indicator (URI). The Windows Server 2003 CA does not use this extension, but it is supported by Windows 2000 with MS04-11, Windows XP, and Windows Server 2003 clients. Although supported, the CryptoAPI does not use this extension when performing chain-building.

  • CRLNumber  This non-critical extension is a monotonically increasing sequence number for each CRL issued by a CA. The CRL number is increased for each issued CRL, regardless of whether the CRL is a base CRL or a delta CRL. The extension is added to both base CRLs and delta CRLs.

  • Next CRL Publish or CRL Publication Period  This non-critical extension indicates the date and time when the Windows CA will publish a new CRL. The same date formatting rules are used for “Effective Date”.

    Presently, a Microsoft Object ID (OID) is used for this extension. It is known as the NextPublish extension. For a list of OIDs used by Microsoft Cryptography, see the Microsoft Knowledge Base article at
    http://support.microsoft.com/?id=287547
    If a standard OID is defined in the IETF, this extension will be changed to the standard OID.

  • IssuingDistributionPoint  Identifies the CRL distribution point if CRL partitioning is implemented. For example, the CRL may be partitioned so that separate CRLs are maintained for end-entity certificates and CA certificates.

    The Windows Server 2003 CA does not implement this extension, but has limited support on Windows 2000 clients with MS04-11 installed, Windows XP clients, and Windows Server 2003 clients when performing chain validation. A Windows client only supports the onlyContainsUserCerts and onlyContainsCACerts extensions within the IssuingDistributionPoint extension. If the extension contains the HoldInstructionCode, InvalidityDate, CertificateIssuer, or IssuerAltName extensions in the IssuingDistributionPoint option, the behavior is determined by whether the criticality flag is set. If the IssuingDistributionPoint extension is marked as a critical extension, validation of a certificate chain with the IDP extension will fail. If the IssuingDistributionPoint is marked as a non-critical extension, the contents of the IssuingDistributionPoint are ignored.

  • deltaCRLIndicator  Indicates that the CRL is a delta CRL. This also specifies the minimum CRL number of BaseCRL with which the delta CRL can be combined to obtain the complete state of the CA.

  • Signature (Issuer Signature Algorithm)  Identifies the algorithm used to certify the CRL.

  • SignatureValue  The actual digital signature computed using the indicated Issuer Signature Algorithm on the ASN.1 Distinguished Encoding Rules (DER)–encoded CRL. The value is encoded as a BIT STRING and omits the signature algorithm and SignatureValue fields.

  • Freshest CRL  This non-critical extension lists the issuers and locations from which to retrieve the delta CRLs. If the “Freshest CRL” attribute is neither present in the CRL nor in the certificate, then the base CRL will be treated as a regular CRL, not as part of a base CRL/delta CRL pair.

    The Microsoft CA does not put the “Freshest CRL” extension into issued certificates. However, it is possible to add the “Freshest CRL” extension to an issued certificate. You would have to write code to add it to the request, write a custom policy module, or use certutil –setextension on a pending request. For more information about advanced certificate enrollment, see the “Advanced Certificate Enrollment and Management” documentation on the Microsoft Web site at
    http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/advcert.mspx

Critical Extensions

Windows 2000 computers with the MS04-11 patch applied, Windows XP, and Windows Server 2003 use a version of the CryptoAPI that enforces critical extensions in CRLs. The CryptoAPI revocation provider evaluates critical extensions in CRLs and rejects a CRL with critical extensions that are not known or understood.

Note  A Windows 2000 client that does not have the MS04-11 patch installed does not support extensions as being marked critical in a CRL; such a client returns the error 0x80092012 CRYPT_E_NO_REVOCATION_CHECK when a critical or unknown extension is encountered.

CRL Encoding Format

Windows 2000 computers with the MS04-11 patch applied, Windows XP, and Windows Server 2003 support both binary and base64–encoded formats. Prior versions (such as W2K without MS04-11) do not support base64–encoded CRLs and will return the error 0x80092013 CRYPT_E_REVOCATION_OFFLINE.

CRL Creation

The serial number for each revoked certificate is kept in the CA’s database and published as part of the CRL until the certificate expires. Typically, a revoked and expired certificate remains in the CRL for one additional CRL publication interval. Then, the certificate’s entry is removed from the CRL because a client that performs certificate status verification would detect that the certificate became invalid since it has expired. Thus, certificate revocation verification is not performed for expired certificates.

If an organization wants to keep a revoked certificate in the CRL beyond the certificate’s expiration date, you can enable the publication of expired certificates to the CRL by running the following command at a command-line prompt and then restarting Certificate Services.

certutil –setreg ca\CRLFlags +CRLF_PUBLISH_EXPIRED_CERT_CRLS

A Microsoft CA that is installed on a computer running Windows 2000 or Windows Server 2003 requires access to the private key of the CA to sign a CRL. Microsoft does not support signing CRLs with private keys that do not belong to the CA.

Delta CRLs

One of the greater challenges for a PKI planner is to determine the best publication schedule for CRLs.

If a CA publishes a complete base CRL frequently, clients are quickly aware of a newly revoked certificate. However, this can cause higher amounts of network traffic due to the more frequent downloading of the updated CRL to all clients. If a CA publishes CRLs less often, this reduces the amount of network traffic, but increases the latency before a client is aware of a newly revoked certificate. Remember that clients cache CRLs locally until they are expired.

Delta CRLs are defined in RFC 3280 and address this problem by publishing information about certificates that have been revoked after the last base CRL was published. When support for delta CRLs is implemented, a client can download the base CRL at longer intervals, and download the smaller delta CRL more frequently.

Because of their assumed smaller size, delta CRLs can be published at shorter intervals than base CRLs to increase the confidence in the certificates being validated without the resource burden of frequent base CRL publication.

Note  Although delta CRLs can be published at shorter intervals, you must consider network latency when determining the delta CRL publication schedule. For example, if it takes eight hours for changes in the Configuration naming context of Active Directory to fully replicate to all domain controllers, and you plan to include CDP URLs that reference Active Directory, you cannot publish delta CRLs more frequently than every eight hours.

Delta CRLs do not eliminate the requirement to download base CRLs. A base CRL must be downloaded initially and when the previous base CRL is going to expire or has expired. A delta CRL can force the client to retrieve a more recent base CRL, even though the current base CRL is still time valid. This is achieved by having the delta CRL refer to a more recent base CRL than the locally cached CRL. When a CA creates a delta CRL, only certificates where the revocation status has changed since the last base CRL publication are included in the delta CRL. Typically, a delta CRL is much smaller than a base CRL.

In the example shown in Figure 5, the initial base CRL (Base CRL #1) is published at time t₀ with a single revoked certificate, Cert3. At time t₁ , the certificate Cert5 is revoked. When the delta CRL (Delta CRL #2) is published at time t₂, the delta CRL contains the serial number for Cert5. The delta CRL’s attributes indicate that it is to be used with Base CRL #1. At time t₃ , the certificate Cert7 is revoked. When the updated delta CRL (Delta CRL #3) is published at time t₄, the delta CRL now contains the serial numbers for both Cert5 and Cert7.

Finally, when the base CRL is updated at time t₅, the base CRL (Base CRL #4) will now include the serial numbers for certificates Cert3, Cert5, and Cert7. Any new delta CRLs will now only include certificates that have been revoked since Base CRL #2 was issued at time t3.

The delta CRL process is very similar to a differential backup strategy. As a differential backup will include all files that have changed since the last full backup, a delta CRL contains all revoked certificates since the last base CRL was issued. The delta CRL will reference the base CRL according to the following algorithm.

The primary algorithm for delta publication refers to the most recent base CRL.

If such a base CRL is not available, the delta CRL will refer to the oldest, non-expired base CRL.

Delta CRL Extensions

To support delta CRLs, some new optional extensions defined in RFC 3280 have been added to the CRL. The extensions include:

• Delta CRL Indicator  This critical extension, only found in a delta CRL, contains the minimum base “CRLnumber” that can be used in conjunction with the delta CRL. If the only base CRL available is less than the base CRL indicated in the “Delta CRL Indicator” field, the base CRL cannot be used with the delta CRL. If this scenario takes place, CryptoAPI will then attempt to retrieve an updated base CRL.

In addition to the extensions added to CRLs to support delta CRLs, some changes were made to CRLs to support the implementation of delta CRLs. These changes include:

• Certificate Hold Processing  If a certificate is revoked with the status CertificateHold, it can subsequently be un-revoked. With delta CRLs, this requires a new entry on the CRL called “RemovedFromCRL” to indicate that the entry exists on the base CRL, but has subsequently been un-revoked.

• Distribution Point Name  Any names in this field are enumerated and compared to names in the subject certificate’s CRL Distribution Point extension. If a match is found, the CRL is considered valid for the certificate.

• Freshness Period  Applications are able to pass a freshness period to Windows 2000 with MS04-11 applied, Windows XP, and Windows Server 2003 clients when requesting a CRL. The freshness period specifies, in seconds, the maximum permissible age of the base or delta CRL. (This age is determined by taking the difference between the current time and the ThisUpdate field in the CRL.) If the CRL is older than the freshness period, a new CRL must be retrieved.

Delta CRL Processing

The application of the MS04-11 patch on Windows 2000 brings the Windows 2000 platform in line with Windows XP and Windows Server 2003 when processing delta CRLs.

Note  Prior to the MS04-11 patch, Windows 2000 clients did not support delta CRLs. If the Freshest CRL extension is included in a base CRL, the pre-MS04-11 Windows 2000 will ignore the non-critical extension.

When the patch is applied, the following behavior takes place when delta CRLs are processed.

• Active Revocation Freshness Policy  When calling the CertGetCertificateChain API, the calling application can specify the policy or target for the revocation freshness information. For more information about the CertGetCertificateChain API, see the MSDN article “CertGetCertificateChain” at
  http://msdn.microsoft.com/library/default.asp?url=/library/en-us/seccrypto/security/certgetcertificatechain.asp
  The API will then make best efforts to meet this policy. If it succeeds, it returns success; if not, it returns an error as appropriate. If the code encounters information that meets the policy, it can terminate revocation checking at that point. For example, if the policy asks for CRL information to be considered valid for eight hours and the code finds a base CRL that was published six hours ago, there is no need to check for delta CRLs.

• Revocation Freshness Property  If there is no policy regarding revocation freshness, the code will make best efforts to establish revocation freshness. On all calls, the value of the revocation freshness information shall be available to the calling application. Moreover, it shall be the latest “this update” value from the CRL.

• Inclusion of the Issuing Distribution Point (IDP) extension  The IDP extension allows partitioned CRLs to be deployed when using third-party CAs. Partitioned CRLs allow a third-party CA to publish CRLs with only specific certificate types within each CRL. For example, you can have separate CRLs for end certificates versus CA certificates. The IDP extension can also be used to validate that the CRL used is the CRL indicated in a certificate’s CRL Distribution Point extension.

  Specifically, the following options can be set in the IDP.

  • onlyContainUserCerts  This option in the IDP allows only certificates that do not have the value “CA” in the basic constraints extension. If the certificate does not contain a basic constraints extension, it is assumed that it is not a CA.

  • onlyContainsCACerts  Thisoption in the IDP allows only certificates having a basic constraints extension set to “CA” to be included in the CRL.

  If the IDP extension is present, CryptoAPI compares the names in the IDP and CDP extensions. If a successful match is made on a single name form, the CRL will be considered as valid for the certificate being validated.

  In Windows, the “onlySomeReasons” and “indirectCRL” fields of the IDP are not supported.

• Establishing if the CA Published Delta CRLs  The client checks for the presence of the “FreshnessCRL” extension in both the certificate and CRL. If the extension is absent from both locations, CRL processing based on CA publishing full CRLs is followed.

• Delta CRL Processing  If the “FreshestCRL” extension is found, it should be used to retrieve the CRL. The client should then examine both CRLs for the presence of the certificate serial number being checked.

• Caching Delta CRLs  As with base CRLs, all retrieved delta CRLs are cached and removed from the disk cache when a new Delta CRL is retrieved.

• Looking for New Delta CRLs  The client can start looking for a new delta CRL once the publication period has elapsed from the “This update” timein the CRL, that is, time now is greater than or equal to the CRL’s “This update” plus the CRL’s publish interval. The Windows XP client can use the “CRLNextPublish” field in the CRL to fetch the next base CRL or delta CRL accordingly.

• New Delta CRL Error Conditions  Delta CRLs introduce a new set of possible errors. These include the following:

  • If a valid base CRL exists and is available, but no delta or time valid delta is available, the certificate chaining engine returns a warning that no delta CRL is available.

  • If the CRL number in the base CRL is less than the base CRLNumber in the available delta CRLs, an error is returned indicating that an updated base CRL should be retrieved.

• CertificateHold Processing  The processing of un-revoked certificates depends on the sequence that the CRLs are examined. If the delta CRL is checked first, the “RemovedFromCRL” entry is equivalent to not appearing on the CRL and returns a response that the certificate is valid. If the base CRL is checked first, the delta CRL must be checked to verify if the entry has been removed from the CRL.

CRL Distribution Point Extensions

When a Windows CA issues a certificate, it may place a CRL distribution point (CDP) extension in the certificate. The CRL distribution point URL refers to the corresponding CRL for the certificate.

Some of the common reasons CryptoAPI may fail to retrieve a CRL object is due to authentication and authorization requirements or timeouts of the target server hosting the CRL object.

If the security context in which the application runs does not have read access to the CRL object on an LDAP server, for example, CryptoAPI will not be able to retrieve the CRL and a “revocation offline” error is returned to the application. CryptoAPI also may not be able to authenticate to a proxy or to caching servers that require basic authentication to reach the HTTP URL that refers to the CRL distribution point. Further, if the CRL object is so large that CryptoAPI is not able to download the object within the allotted maximum timeout threshold, a “revocation offline” error is returned and the object download is terminated.

If the CDP extension is missing in a certificate, CryptoAPI will only check the local stores and cache for a CRL. If a local CRL is available, it will be checked despite the absence of a CDP extension. However, applications must make the decision whether to demand a revocation check on a certificate. Some applications, such as smart card logon on domain controllers, always enforce the revocation check and will reject a logon event if the revocation check cannot be performed or fails.

Note  The URLs within the CDP extension must be supported by the CryptoAPI. Windows 2000 with MS04-11, Windows XP with MS04-11, and Windows Server 2003 clients with MS04-11 only support LDAP, FILE, and HTTP URLs. If your PKI implements HTTPS or FTP URLs, they are no longer supported by the clients for CRL retrieval.

Cross-Certification Distribution Point Extensions

The Cross-Certification Distribution Point extension identifies where cross-certificates related to a particular certificate can be obtained and how often that location is updated. The Windows XP and later operating systems use this extension for the discovery of cross-certificates that may be used during the patch discovery and chain-building process. The extension SHOULD be non-critical, but this white paper RECOMMENDS support for this extension by CAs and applications.

Note  The terms SHOULD, RECOMMENDS, MAY, and MUST are used in this section based on the definitions of these terms in RFC 2119 “Key words for use in RFCs to Indicate Requirement Levels” available at
http://www.ietf.org/rfc/rfc2119.txt

The CrossCertDistPoints extension consists of two fields: CrossCertDistPointNames and syncDeltaTime. The CrossCertDistPointNames is a SEQUENCE of GeneralNames that reference a location where the cross-certificates related to a particular certificate can be found. Applications that support this extension MUST support general names of type directoryName and MAY support other types.

The syncDeltaTime is an OPTIONAL INTEGER field that specifies the time after which this location will be refreshed. If “syncDeltaTime” is present, “CrossCertDistPointNames” MUST also be present.

   id-ce-crossCertDistPoints OBJECT IDENTIFIER ::=  { id-ce ??}
   CrossCertDistPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint
   CrossCertDistPoints ::= SEQUENCE {
        syncDeltaTime               INTEGER (0..4294967295) OPTIONAL,
        crossCertDistPointNames     CrossCertDistPointNames }
   CrossCertDistPointNames ::= SEQUENCE OF GeneralNames
   GeneralNames ::= AltNames
   AltNames ::= SEQUENCE OF GeneralName
   GeneralName ::= CHOICE {
        otherName                       [0]     OtherName,
        rfc822Name                      [1]     IA5String,
        dNSName                         [2]     IA5String,
        x400Address                     [3]     ORAddress,
        directoryName                   [4]     Name,
        ediPartyName                    [5]     EDIPartyName,
        uniformResourceIdentifier       [6]     IA5String,
        iPAddress                       [7]     OCTET STRING,
        registeredID                    [8]     OBJECT IDENTIFIER }
   OtherName ::= SEQUENCE {
        type                    EncodedObjectID,
        value                   [0] EXPLICIT ANY
   }
   SeqOfAny ::= SEQUENCE OF ANY
   EncodedObjectID ::= OBJECT IDENTIFIER
   IA5STRING ::= IA5String
   OCTETSTRING ::= OCTET STRING

CRL and AIA Caching

To increase performance, the CryptoAPI caches CRLs and certificates referenced in AIAs. The entries are cached in memory on a per process basis. The chain engine does not purge its memory cache until the object expires and there is no way to force the chain to flush its memory cache except to restart the host process.

Base and delta CRLs are cached in memory for each application that calls the certificate status checking APIs. This may require an application to be restarted before the application will determine that a locally cached CRL no longer exists and must be fetched from the CDP location in the certificate. The Windows operating system does not support manual or programmatic flushing of the CRL cache. CryptoAPI also does not support forcing the download of a CRL object when an existing valid CRL has been cached in memory or on the disk subsystem.

The benefit of caching CRLs locally is that CryptoAPI will always look for a cached copy first to avoid traversing the network, generating additional download traffic, and introducing latency in the revocation status checking.

The disadvantage of local caching is that the client will not look for a new base CRL or delta CRL until the CRL has expired. Therefore, if a revocation has occurred on a CA and a new CRL is published, the client may not download the updated CRL due to having a time valid locally cached copy.

Note  Certificate caching is a core functionality of CryptoAPI. Its behavior cannot be modified or turned off.

During certificate status checking, valid certificates and CRLs cached in memory are always preferred before a certificate store search is performed. If a certificate or CRL is not in the cache or certificate store, CAPI will download them using information in the AIA or CDP extension of the certificate.

Certificates are cached when CryptoAPI retrieves them from a certificate store or a URL. The cache location varies depending on the source where a certificate or a CRL was retrieved. A certificate or a CRL can exist in one or several of the following locations.

• Memory  All valid certificates and CRLs that have been touched by the chain-building engine since the last reboot are cached in memory.

• Certificate Store  All certificates that are not treated as root CA certificates and that have been retrieved from an HTTP–, LDAP– or FILE–URL reference via the AIA certificate extension are cached in the certificate store if the certificates are found to be part of a valid chain by the CryptAPI. Root CA certificates are not automatically cached and must be added explicitly by the interactive user to the corresponding certificate store.

• Local File System  When a certificate or CRL is retrieved via LDAP or HTTP by a Windows 2000 client with MS04-11, Windows XP SP2 client, or Windows Server 2003 client, it is cached by CAPI in the “Application Data” folder. The per-user cache location is “C:\Documents and Settings\{user name}\Application Data\Microsoft\CryptnetUrlCache” and the per-machine cache location is “%WINDIR%\System32\config\SystemProfile\Application Data\Microsoft\CryptnetUrlCache”.

Windows 2000 with MS04-11, Windows XP, and Windows Server 2003 handle caching for HTTP–, LDAP–, or FILE–URL references exclusively with CAPI. Earlier versions of CryptoAPI used WinInet instead of CAPI for this purpose.

Note  On computers where the Windows Server 2003 version of certutil is available, cached CRLs can be listed by typing Certutil –urlcache CRL at a command-line prompt. This command is also available on Windows XP computers that have the Windows Server 2003 Administration Pack installed.

Cross-Certification

Cross-certification is the process of cross-certifying CA hierarchies using basic constraints, name constraints, issuance policies, and application policies to limit which certificates are accepted from partner CA hierarchies or a secondary hierarchy within the same organization.

A Cross-Certification Authority (CrossCA) certificate includes its defined constraints and policies, and allows clients that trust your CA hierarchy’s root CA to trust certificates issued by CAs from another organization that meet the constraints and policies defined in your CrossCA certificate.

Prior to the Windows Server 2003 PKI, the only available alternative to trust certificates from other CA hierarchies was to define Certificate Trust Lists (CTLs) that trusted specific CAs and restricted certificate usage. By using cross-certification, a CA administrator can clearly define which certificates issued by a partner’s PKI are trusted by the CA administrator’s organization. Cross-certification also provides methods for compartmentalizing and controlling certificate issuance within an organization according to policy guidelines.

When cross-certification is implemented, not all client computers will recognize the certificate chains formed by the CA. To recognize the certificate chains, the client must be running Windows 2000 with MS04-11, Windows XP, or Windows Server 2003. Prior versions of Microsoft operating systems will not build chains using CrossCA certificates.

The Effect of CA Certificate Renewal

When you renew a CA certificate, the certificate name and CRL name may change based on the type of renewal that you perform as follows:

• When you renew with the same key pair, the name of the CA’s certificate is modified to indicate a change in the version of the CA certificate. The name of the CRL does not change from the previous version because the CRL is still signed with the same private key.

• When you renew a CA certificate with a new key pair, both the name of the CA certificate and the CRL are changed. The CA will publish both the previous CRL and the new CRL until all CA certificates associated with the previous CA certificate expire.

When you issue the CA certificate for a CA, the default certificate name is based on the following variable combination: %1_%3%4.crt. In this naming scheme, the variables represent:

• %1  The DNS name of the CA certificate.

• %3  The logical name assigned to the CA instance by the installer of Certificate Services.

• %4  The version number of the CA certificate. When the CA certificate is renewed, the version number will be incremented.

For example, if the DNS name of the computer is ca.example.com and the logical name of the CA computer is Example Issuing CA, the initial CA certificate will be named ca.example.com_Example Issuing CA.crt.

Note  The initial name of the certificate will suppress the version number of the certificate. Do not exclude the %4 variable when naming the root CA certificate so that the version number is not suppressed in the CA certificate name when the CA certificate is renewed.

Likewise, the default CRL name is based on a combination of variable these %3%8%9 including the crl extension as %3%8%9.crl. In this variable expression, the following variables are used.

• %3  The logical name assigned to the CA instance.

• %8  The CRL version indicator. When the CA certificate’s key pair is renewed with a key pair, the version number is incremented to the version number of the current CA certificate.

• %9  The delta CRL indicator. If the CRL is a delta CRL, the character “+” is added to the CRL name. If the CRL is a base CRL, no characters are added to the CRL name.

Table 3 shows an example of how the CA certificate name and CA CRL name change as the CA certificate is renewed with a combination of same key pairs and new key pairs. The table assumes that during the first half of the CA certificate lifetime, the CA certificate is renewed with the same key pair. When the CA certificate reaches the end of the original CA certificate lifetime, the CA certificate is then renewed with a new key pair.

Note  The renewal pattern of renewing the CA certificate with the same key pair at half the certificate lifetime and with a new key pair at the completion of the certificate lifetime is based on recommendations from the “Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure” white paper. You can download this white paper from the Microsoft Web site at
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/ws3pkibp.mspx

When you renew a CA certificate with a new key pair, the Windows Server 2003 CA also issues two additional certificates. These certificates are Cross-Certification Authority certificates that associate:

• The new CA certificate with the previous CA certificate. A CrossCA certificate is created, which is issued by the new CA certificate to the previous CA certificate. This CrossCA certificate allows computers that only trust the new CA certificate to trust certificates that were signed with the CA’s previous key pair.

• The previous CA certificate with the new CA certificate. A CrossCA certificate is created, which is issued by the previous CA certificate to the new CA certificate. This CrossCA certificate allows computers that only trust the previous CA certificate to trust certificates that were signed with the CA’s new key pair.

Note  If a computer trusts both the previous and new versions of the CA certificate, the CryptoAPI will never select a chain that uses these CrossCA certificates, as the default chain will be shorter than any chain assembled that uses this CrossCA certificate. For more information about chain-building, see the Path Construction and Validation section.

Table 3 outlines the CA certificates and CRLs that exist for a CA computer as the computer’s CA certificate is renewed over time. The table describes the following timeline.

1. The original CA certificate is issued with both base CRLs and delta CRLs.

2. At half of the original CA certificate’s lifetime, the original CA certificate is renewed using the same key pair. Note that two valid CA certificates now exist for the CA.

3. At the completion of the original CA certificate’s lifetime, the CA certificate is renewed with a new key pair. In addition to a new CA certificate being created, two CrossCA certificates are created to associate the two CA certificates. In addition, a new CRL file is generated that is signed by the new key pair. The original CA certificate is no longer maintained by the CA, as the certificate has now expired.

4. At half the lifetime of the CA certificate generated in step 3, the CA’s certificate is renewed with the same key pair. The CA certificate generated in step 2 is no longer maintained by the CA, as it has expired.

5. At the end of the lifetime of the CA certificate generated in step 3, the CA’s certificate is renewed with a new key pair. The certificate generated in step 3 is no longer maintained by the CA. A new CA certificate, a pair of CrossCA certificates, base CRL, and delta CRL are generated for the CA.

Assuming that the CA is installed on a computer named ca.example.com and that the name of the CA is “Example Issuing CA”, Table 3 details the CA certificate names and CRL names maintained by the CA during each step in the CA lifetime.

Table 3.  CA Certificate Names and CRL Names During the CA Lifetime

CertificateTimeline	Certificate Instance	Cert Name	CRL Name
1	Original	CA.EXAMPLE.COM_Example Issuing CA.crt	CA.EXAMPLE.COM_Example Issuing CA.crl CA.EXAMPLE.COM_Example Issuing CA+.crl
2	Renew with same key pair	CA.EXAMPLE.COM_Example Issuing CA.crt and CA.EXAMPLE.COM_Example Issuing CA[1].crt	CA.EXAMPLE.COM_Example Issuing CA.crl and CA.EXAMPLE.COM_Example Issuing CA+.crl
3	Renew with new key pair	CA.EXAMPLE.COM_Example Issuing CA[1].crt CA.EXAMPLE.COM_Example Issuing CA[2].crt CA.EXAMPLE.COM_Example Issuing CA[1-2].crt CA.EXAMPLE.COM_Example Issuing CA[2-1].crt	CA.EXAMPLE.COM_Example Issuing CA.crl CA.EXAMPLE.COM_Example Issuing CA+.crl and CA.EXAMPLE.COM_Example Issuing CA[2].crl CA.EXAMPLE.COM_Example Issuing CA[2]+.crl
4	Renew with same key pair	CA.EXAMPLE.COM_Example Issuing CA[3].crt CA.EXAMPLE.COM_Example Issuing CA[2].crt CA.EXAMPLE.COM_Example Issuing CA[1-2].crt CA.EXAMPLE.COM_Example Issuing CA[2-1].crt	CA.EXAMPLE.COM_Example Issuing CA[2].crl CA.EXAMPLE.COM_Example Issuing CA[2]+.crl
5	Renew with new key pair	CA.EXAMPLE.COM_Example Issuing CA[3].crt CA.EXAMPLE.COM_Example Issuing CA[4].crt CA.EXAMPLE.COM_Example Issuing CA[4-3].crt CA.EXAMPLE.COM_Example Issuing CA[3-4].crt	CA.EXAMPLE.COM_Example Issuing CA[2].crl CA.EXAMPLE.COM_Example Issuing CA[2]+.crl and CA.EXAMPLE.COM_Example Issuing CA[4].crl CA.EXAMPLE.COM_Example Issuing CA[4]+.crl

Certificate Status Checking

When an application requests the certificate chaining engine to evaluate a certificate, the validation is performed on all certificates in that certificate’s chain. This includes every certificate from the leaf certificate presented to the application to the root certificate.

When the first certificate in the chain is validated, the following process takes place.

1. The chaining engine will attempt to find the certificate of the CA that issued the certificate being examined. The chaining engine will inspect the local system certificate stores to find the parent CA certificate. The local system stores include the CA store, the Root store, and the Enterprise Trust store. If the parent CA certificate is not found in the local system certificate stores, the parent CA certificate is downloaded from one of the URLs available in the inspected certificates AIA extensions. The paths are built without signature validation at this time because the parent CA certificate is required to verify the signature on a certificate issued by the parent CA.

2. For all chains that end in a trusted root, all certificates in the chain are validated. This involves the following steps.

   • Verify that each certificate’s signature is valid.

   • Verify that the current date and time fall within each certificate’s validity period.

   • Verify that each certificate is not corrupt or malformed.

3. Each certificate in the certificate chain is checked for revocation status. The local cache is checked to see if a time valid version of the issuing CA’s base CRL is available in the cache. If the base CRL is not available in the local cache, or the version in the local cache has expired, the base CRL is downloaded from the URLs available in the CDP extension of the evaluated certificate. If available, it is confirmed that the certificate’s serial number is not included in the CA’s base CRL.

   When a root certificate—a certificate that contains the same DN for both the Subject and Issuer attributes—is encountered, a revocation check may or may not occur. If the certificate chaining engine behavior will depend on whether the application enables the CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT flag, which is the default, the root CA’s certificate is not checked for revocation. If the flag is not enabled, the root CA certificate is checked for revocation if the root CA certificate includes the CDP extension. If the CDP extension is not included, no revocation check is performed.

   Note  Windows XP RTM and Windows XP SP1 will perform revocation checking as the chain is built, rather than only performing revocation checking on chains that end at a trusted root CA.

4. If the base CRL contains the Freshest CRL extension, the local cache is checked to see if a time valid version of the issuing CA’s delta CRL is available in the cache. If available, it is confirmed that the certificate’s serial number is not included in the CA’s delta CRL. If the delta CRL is not available in the local cache, or the version in the local cache has expired, the delta CRL is downloaded from the URLs available in the CDP extension of the evaluated certificate.

   Warning  If delta CRLs are enabled at a CA, both the base CRL and delta CRL must be inspected to determine the certificate’s revocation status. If one of the two, or both, are unavailable, the chaining engine will report that revocation status cannot be determined, and an application may reject the certificate.

Once the validation check is completed, the certificate chaining engine returns the results of the validation check to the calling application. The results will indicate if all certificates in the chain are valid, if the chain terminates at a non-trusted root CA, if any certificates in the chain are not valid, or if the revocation status for any of the certificates in the chain cannot be determined.

Note  If any certificate in the chain cannot be validated or is found to be revoked, the entire chain takes on the status of that one certificate.

Certificate Status Checking Details

The status of a public key certificate is determined through inter-related processes implemented in the CryptoAPI.

• Certificate Path Discovery  The process of collecting CA certificates from Group Policy, Enterprise Policy, and AIA pointers in issued certificates, and the certificate enrollment process. The certificate discovery process can be part of the path validation or can be a separate task. Certificate discovery only occurs during path validation if the certificates necessary for validation are not already available in the local certificate stores.

• Path Construction and Validation  This process covers building a certificate chain for a certificate to verify.

• Application Policy Validation  If an application policy is defined, any defined Extended Key Usage (EKU) constraints are applied. The EKU constraints are applied from the root CA to the end certificate. As part of the application policy validation Name constraints, basic constraints and certificate policy validation are performed as well.

• Certificate Revocation Checking  Each certificate in the certificate chain is verified for time validity and revocation. The revocation checking can take place either in conjunction with the chain-building process, or after the chain is built.

Certificate Path Discovery

One of the important aspects of a PKI deployment is the management of CA certificate discovery for path validation purposes. The Windows operating system family and Active Directory provide the highest level of integrated support to abstract the CA certificate discovery process from users and applications. Group policies can ensure that clients receive the current set of trusted root CA certificates. Nevertheless, CA certificates can also be distributed in non–Active Directory environments. The process of CA certificate discovery depends on the CryptoAPI and CryptNet version.

Note  The certificate discovery process is the same in Windows 2000 with MS04-011 applied, Windows XP, and Windows Server 2003. However, the process is different for Windows 2000 systems that