Windows XP: Certificate Status and Revocation Checking

Applies To Windows XP

Currently this Applies to Windows XP only.

The article How Certificate Revocation Works applies to Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2. The goal is to integrate the two articles here in the future.

 

↑ Back to top

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.

 

↑ Back to top

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.

 

↑ Back to top

Terminology

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.

 

↑ Back to top

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

 

↑ Back to top

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

 

↑ Back to top

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.

 

↑ Back to top

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.

Figure 1. Certificate Store View for the Current User with Physical View Enabled

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.

Figure 2. Enabling the Update Root Certificates Option in Add/Remove Programs

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.

Figure 3. Defining Trusted Root Certification Authorities in a Group Policy Object

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.

Figure 4. Preventing Trust of Built-in Commercial Root CA Certificates Downloaded Using Windows Update

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 certificate of the CA that issued the domain controller’s (DC) certificate is included in the NTAuth store. In addition, the DC ensures that the certificate of 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.

 

↑ Back to top

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

 

↑ Back to top

CRL Reason Codes

The process of revocation invalidates a certificate before its end validity date using one of the CRL reason codes.

Note Windows does not support partitioning CRLs by reason code as either a server or a client.

When a certificate is revoked, it is possible for a certificate issuer to specify why the action was taken. This is done by specifying a revocation reason; these reasons are defined by RFC 3280 and include the following:

• Key Compromise The token or disk location where the private key associated with the certificate has been compromised and is in the possession of an unauthorized individual. This can include the case where a laptop is stolen or a smart card is lost.

• CA Compromise The token or disk location where the CA’s private key is stored has been compromised and is in the possession of an unauthorized individual. When a CA’s private key is revoked, this results in all certificates issued by the CA that are signed using the private key associated with the revoked certificate being considered revoked.

• Change of Affiliation The user’s relationship with the organization has been terminated, indicated in the DN attribute of the certificate. This revocation code is most often used when an individual is terminated or has resigned from an organization. You do not have to revoke a certificate when a user changes departments, unless your security policy requires a different certificate be issued by a departmental CA.

• Superseded A replacement certificate has been issued to a user, and the reason does not fall under the previous reasons. This revocation reason is most often used when a smart card fails, the password for a token is forgotten by a user, or the user’s legal name has changed.

• Cease of Operation If a CA is decommissioned—no longer to be used—the CA’s certificate should be revoked with this reason code. Do not revoke the CA’s certificate if the CA no longer issues new certificates, yet still publishes CRLs for the currently issued certificates.

• Certificate Hold A temporary revocation that indicates a CA will not vouch for a certificate at a specific point in time. Once a certificate is revoked with a CertificateHold reason code, the certificate can then be revoked with another Reason Code, or unrevoked and returned to use.

  Note While CertificateHold allows a certificate to be “unrevoked”, it is not recommended to place a hold on a certificate, as it becomes difficult to determine if a certificate was valid for a specific time.

• RemoveFromCRL If a certificate is revoked with the CertificateHold reason code, it is possible to “unrevoke” a certificate. The unrevoking process still lists the certificate in the CRL, but with the reason code set to RemoveFromCRL. This is specific to the CertificateHold reason and is only used in DeltaCRLs.

• Unspecified While it is possible to revoke a certificate with the “Unspecified” reason code, it is not recommended, as it does not provide an audit trail as to why a certificate is revoked.

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.

 

↑ Back to top

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.

 

↑ Back to top

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.

http://i.technet.microsoft.com/dynimg/IC174466.gifWarning
Consider that large CRLs can cause performance issues for certificate clients and domain controllers. For more information on what could cause large CRLs, see TechNet Wiki article Large CRLs: What is added to a Certificate Revocation List (CRL)?

 

↑ Back to top

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 t0 with a single revoked certificate, Cert3. At time t1 , the certificate Cert5 is revoked. When the delta CRL (Delta CRL #2) is published at time t2, 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 t3 , the certificate Cert7 is revoked. When the updated delta CRL (Delta CRL #3) is published at time t4, the delta CRL now contains the serial numbers for both Cert5 and Cert7.

Finally, when the base CRL is updated at time t5, 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.

Figure 5. Preventing Trust of Built-in Commercial Root CA Certificates Downloaded Using Windows Update

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.

 

Back to top

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.

 

↑ Back to top

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

 

↑ Back to top

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.

 

↑ Back to top

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.

 

↑ Back to top

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	Example Issuing CA.crl 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	Example Issuing CA.crl 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	Example Issuing CA.crl Example Issuing CA+.crl and Example Issuing CA[2].crl 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	Example Issuing CA[2].crl 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	Example Issuing CA(2).crl Example Issuing CA(2)+.crl Example Issuing CA(4).crl 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.

 

↑ Back to top

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 do not have the MS04-011 security update applied.

The certificate discovery process retrieves certificates in the following ways. The order in which Windows retrieves the certificates depends on the availability of a given certificate and, therefore, the actual order is not necessarily equal to the order that follows.

Note In a Windows environment, it is common that LDAP URL references carry three slashes after the protocol specifier. A regular URL reference would provide the hostname to the client, but in case of one with three slashes, the host name is left out, and a Windows client will connect to the closest Domain Controller.

• CA Certificates that are available in the CA’s container in the Active Directory Configuration naming context are deployed with the Enterprise policy into the client computer’s Trusted Root Certification Authorities Enterprise certificate store.

  • To view the content of the CA’s container, perform the following command as a single line at a command-shell and replace “DC=Contoso,DC=com” with the LDAP DN of your Active Directory forest root domain.

    Note: The line has been split into multiple lines for readability. However, while trying it out on a system you must enter it as one line without breaks.

    certutil -viewstore "ldap:///CN=Certification Authorities,CN=Public Key
    Services,CN=Services,CN=Configuration,DC=contoso,DC=com?
    cACertificate?one?objectClass=certificationAuthority"
    

  • To view the content of the client computer’s Trusted Root Certification Authorities Enterprise certificate store, type the following command at a command-line prompt.

    certutil -enterprise -viewstore Root
    

    Note If CA certificates are deleted from a client’s certificate enterprise store, the deleted certificates are not refreshed when Group Policy is next updated and applied. A refresh of the enterprise store occurs only when the corresponding object that holds the certificates is changed in Active Directory or if the client contacts a different Domain Controller.

• CA certificates that are available in the Enrollment Services container in your Active Directory Configuration naming context are deployed with the Enterprise policy into the client computer’s Intermediate Certification Authorities store.

  • To view the content of the Enrollment Services container in Active Directory, type the following command as a single line at a command-line prompt and replace “DC=Contoso,DC=com” with the LDAP DN of your Active Directory root domain.

    Note: The line has been split into multiple lines for readability. However, while trying it out on a system you must enter it as one line without breaks.

    certutil -viewstore "ldap:///CN=Enrollment Services,CN=Public Key
    Services,CN=Services,CN=Configuration,DC=contoso,DC=com?
    cACertificate?base?objectclass=pKIEnrollmentService"
    

  • To view the content of the client computer’s Intermediate Certification Authorities certificate store, type the following command at a command-line prompt.

    certutil -enterprise -viewstore CA
    

  Note More certificates can exist in the local enterprise Intermediate Certification Authorities certificate store than are reported in the Enrollment Services certificate container in Active Directory. The reason is that certificates stored in the Enrollment Services and AIA container in Active Directory are stored in the same certificate store at the client computer.

• CA certificates that are available in the AIA container in your Active Directory Configuration naming context are also deployed with group policies into the client computer’s Intermediate Certification Authorities store.

  • To view the content of the AIA container in Active Directory, type the following command at a command-line prompt and replace “DC=Contoso,DC=com” with the LDAP DN of your Active Directory root domain.

    Note: The line has been split into multiple lines for readability. However, while trying it out on a system you must enter it as one line without breaks.

    certutil -viewstore "ldap:///CN=AIA,CN=Public Key
    Services,CN=Services,CN=Configuration,DC=contoso,DC=com?
    cACertificate?base?objectclass=certificationAuthority"
    

  • As stated previously, certificates in the AIA container of Active Directory are stored in the local enterprise Intermediate Certification Authorities certificate store. To view these certificates, type the following command at a command-line prompt.

    certutil -enterprise -viewstore CA
    

• CA certificates that are available in the NTAuth container in your Active Directory Configuration naming context are also deployed with group policies into the client computer’s Intermediate Certification Authorities store.

  • To view the content of the NTAuth container in Active Directory, type the following command at a command-line prompt and replace “DC=Contoso,DC=com” with the namespace of your Active Directory root domain.

    Note: The line has been split into multiple lines for readability. However, while trying it out on a system you must enter it as one line without breaks.

    certutil -viewstore "ldap:///CN=NTAuthCertificates,CN=Public Key
    Services,CN=Services,CN=Configuration,DC=contoso,DC=com"
    

  • To view the content of the client computer’s NTAuth certificate store, type the following command at a command-line prompt.

    certutil -enterprise -viewstore NTAuth
    

  Note The NTAuth store is created and populated during setup of the first Enterprise CA in Active Directory or when certificates are published manually to that store. Thus, if you have deleted the NTAuth store accidentally, you can recover it by adding certificates manually with certutil -dspublish to this store. The NTAuth store designates CAs that are capable of issuing certificates for smart card logon and “enroll on behalf of” behavior.

• Certificates defined in Group Policy are applied and loaded into the Local Machine certificate store. The root CA certificates that have been added into the Group Policy hive Computer Configuration\Windows Settings\Security Settings\Public Key Policies\Trusted Root Certification Authorities policy appear at the client in the local machine’s Group Policies container. Certificates in Active Directory in the Group Policy can only be viewed from the Group Policy console. The local Trusted Root Certification Authorities certificate container can be viewed with the Certificates console since the current version of Certutil.exe cannot show the local Group Policy certificate store. The Group Policies container is a subcontainer Trusted Root Certification Authorities and is only visible if the physical certificates store view has been turned on in the Certificates console.

• The CA certificates that have been added into the Group Policy hive Computer Configuration\Windows Settings\Security Settings\Public Key Policies\ Enterprise Trust policy appear at the client in the Local Machine - Group Policies container. Certificates in Active Directory in the Group Policy can only be viewed with the Group Policy console. The local Enterprise Trust certificate container can be viewed from the Certificates console. The Group Policies is a subcontainer Enterprise Trust and is only visible if the physical certificates store view has been turned on in the Certificates console. Certificates defined in the Enterprise policy are loaded into the Local Machine certificate store. The Enterprise policy includes certificates stored in the NTAuth store.

• If a certificate in the user’s personal store does not have a CA certificate from the same issuer and is not revoked or expired, the CA certificate will be retrieved using the AIA references in the certificate.

  To view the certificates that are referred to in an AIA certificate extension, type the following command at a command-line prompt.

  certutil -URL [CertificateFile]
  

  Replace “[CertificateFile]” with the file name of the certificate to be verified and select the “Certs from AIA” option. Click the “Retrieve” button. Find the status codes that are returned by this verification step in Appendix C – CRL Return Codes.

• If the “Update Root Certificates” component is installed, updated root certificates are downloaded from the Windows download site periodically. For more information about the Root certificates update component, search for “Update Root Certificates” at

  http://search.microsoft.com

• When certificate enrollment is performed, the whole chain is provided together with the issued certificate to the user or machine certificate store. If a user receives a certificate through autoenrollment, all parent certificates are stored in the user’s Intermediate Certification Authorities certificate store. If a computer receives a certificate through autoenrollment, all parent certificates are stored in the computer’s Certification Authorities certificate store.

If a user encounters a certificate chain that chains to a non-trusted root CA, the user can choose to manually install the root CA certificate into the trusted root store. Not only does this action establish trust for the current certificate chain, it establishes trust for all certificates that chain to the root certificate.

When a user chooses to install a root CA certificate manually, an interactive dialog box is displayed to approve the root CA certificate installation in the user’s certificate store as shown in Figure 6.

Figure 6. Security Warning When a New Root CA Certificate Is Added to the Trusted Root Store

A local Administrator of a computer can choose to add root certificates to the computer’s certificate store instead of their user certificate store, but a local Administrator is still prompted to approve a root CA certificate installation.

Note Only System Services like the “LocalSystem” service can add a root CA certificate to the computer’s certificates store automatically and silently without the approval dialog box.

 

↑ Back to top

Path Construction and Validation

For each certificate in the chain, the chain-building engine must determine the parent CA. This process is repeated until a self-signed certificate is reached, typically, a root CA certificate.

Note While CryptoAPI expects the certificate to be a self-signed certificate, RFC 3280 allows any certificate to be designated as a trust anchor. In RFC 3280, a trust anchor is designated by a specific DN and key pair, allowing for an application to choose an intermediate CA certificate as a trust anchor. For example, an application that does not use CryptoAPI may choose to establish trust at an intermediate CA if the root CA implements a key length that exceeds the maximum supported by the application.

The certificate path construction process begins with certificates that are in the local system certificate stores. These local system certificate stores include CA, Root, and Enterprise Trust. If a parent certificate that is part of the chain is not available locally, the chaining engine attempts to retrieve this certificate from the URL that is specified in the AIA extension of the child certificate. Each certificate in the chain is assigned a status code. The status code indicates whether the individual certificate is signature-valid, time-valid, expired, revoked, time-nested, and so on. Each status code has a precedence assigned to it. For example, an expired certificate has a higher precedence than a revoked certificate. This ensures that an expired certificate is not checked for revocation status.

If different status codes are assigned to the certificates in a certificate chain, the status code with the highest precedence is applied to the certificate chain and propagated into the certificate chain status. Certificate status codes are determined by the CERT_TRUST_STATUS structure defined in the Platform SDK. For more information about the various status codes and error codes that can be assigned to individual certificates and certificate chains by the chaining engine see Appendix A – Certificate and Certificate Chain Status Codes.

Note For a complete list of status and error code definitions, search for CERT_TRUST_STATUS at http://msdn.microsoft.com/library

There are different processes that can be used to select the certificate for an issuing CA. The actual process that is used depends on the Authority Key Identifier (AKI) certificate extension. Inspection of the AKI will lead to one of three matching processes.

• Exact match If the AKI extension contains the issuer’s subject, issuer serial number, and KeyID, only parent certificates that match with their subject, serial number, and KeyID are chosen in the chain-building process.

  Note Windows 2000 computers, without the MS04-11 update, assign a higher status code precedence for an exact match than a key match or name match. This higher status code results in a certificate chain built with an exact match being preferred over a certificate chain built with key match or name match. Application of MS04-11 changes the Windows 2000 behavior to match the behavior of Windows XP and Windows Server 2003, reducing the weight of an exact match so that other factors could result in a key match or name match chain being selected as the best quality chain.

  Figure 7 shows a certificate where exact matching is used to find the issuer’s certificate. The subject and serial number in the AKI extension in the certificate on the left match the serial number and subject of the certificate on the right.

  

  Figure 7. Certificate Exact Match

• Key match If the AKI extension contains just the KeyID, only certificates that contain a matching KeyID in the Subject Key Identifier (SKI) extension are chosen as valid issuers. This selection method is known as a key match.

  Note The most common case where the CryptoAPI would prefer a key match rather than an exact match or name match is the case where a Windows 2000 CA was upgraded to Windows Server 2003. The order of LDAP DNs, within the Subject and Issuer fields of a CA certificate, was changed between Windows 2000 and Windows Server 2003. This change in LDAP DN ordering would cause name matches to fail, since the name no longer matched.

  Figure 8 shows a scenario where key matching is used to find the issuing CA certificate. The hash of the public key in the AKI extension for the certificate on the left matches the hash of the public key in the SKI extension of the certificate on the right.

  

  Figure 8. Certificate Key Match

  Note If a certificate’s AKI extension contains a KeyID, CryptoAPI requires the issuer certificate to contain a matching SKI. This differs from RFC 3280 where SKI and AKI matching is optional.

• Name Match If no information exists in the AKI or if the AKI extension is not in the certificate, name matching will occur. In this case, the subject name of the issuer certificate must match the issuer attribute of the current certificate. The CryptoAPI uses a binary comparison algorithm to match the subject and issuer attributes. The binary comparison, although not strictly following RFC 3280, improves the performance of the matching. In addition, CryptoAPI does not normalize a name before performing the comparison. As a result, DNs that use alternate encodings, different ordering of LDAP DNs, or names intermixed with white spaces will not successfully match.

  Figure 9 illustrates name matching between a root CA certificate and a certificate that was issued by a root CA. The root certificate shown on the right does not include an AKI extension, so name matching is used to match the issuer and subject attributes of the certificate.

  

  Figure 9. Certificate Name Match

The information that is stored in the AKI extension of certificates issued by Windows CAs differs between Windows 2000 and Windows Server 2003. By default, the following information is stored in the AIA extension of issued certificates.

• Windows 2000 The AIA extension of certificates issued by the CA includes the LDAP DN of the issuing CA (Issuer name), the serial number of the issuing CA’s certificate, and the key hash of the CA certificate’s public key.
• Windows Server 2003 The AIA extension of certificates issued by the CA only includes a hash of the public key of the issuing CA, also known as the Key-ID.

The change in behavior is due to chaining errors that could occur when a CA’s certificate was renewed. The default Windows 2000 behavior could result in incomplete chains if the CA certificate used to sign the issued certificate was not available to the client. With the Windows Server 2003 default behavior, if the CA was renewed with the same key pair, any CA certificate for the issuing CA that uses the same key pair could be included in the certificate chain.

You can change the Windows 2000 CA behavior to match the Windows Server 2003 behavior by typing the following commands at a command-line prompt.

certutil -setreg policy\EditFlags -EDITF_ENABLEAKIISSUERNAME
certutil -setreg policy\EditFlags -EDITF_ENABLEAKIISSUERSERIAL

Note These commands disable the inclusion of the issuername and issuerserialnumber in the AIA extension of certificates issued by the CA. Certificates that were issued prior to the execution of the previous commands remain unmodified.

The CA architecture has an effect on the chain-building process. Before a distinct certificate chain is considered valid, the chaining engine builds all chains that are possible with the certificate that is being verified. If an end-entity certificate was generated by a freshly set up CA, the certificate chain is straightforward. However, a certificate that was issued by a renewed CA or where a cross-certification exists between the issuing CA and another CA, multiple certificate chains might exist.

The entire graph of certificate chains is constructed and then ordered by the “quality” of the chain. The best quality chain for a given end certificate is returned to the calling application as the default chain. For more information on the chain-building process for different CA infrastructures, see the Appendices. The models discussed include:

• 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

 

↑ Back to top

Application Policy Validation

If application policies, issuance policies, or name constraints are defined within a CA certificate or Cross-Certification Authority certificate, the CryptoAPI will indicate to a calling application only certificate chains that match the defined policies.

• Application Policies If application policy or Extended Key Usage (EKU) OIDs are designated in a CA certificate, the CryptoAPI will return a certificate status code of CERT_TRUST_INVALID_POLICY_CONSTRAINTS to the calling application. CryptoAPI determines if the certificate contains the required application policy OID or OIDs by examining the application policy extension.

  Note The application policy extension allows the use of application policy mapping. A Cross-Certification Authority certificate can map one application policy OID to represent another application policy OID. This is subject to a certificate closer to the root CA and not inhibited by policy mapping.

• Issuance Policies If an issuance policy is defined within a CA certificate or CrossCA certificate, the issuance policy is applied starting at the root certificate to the end certificate. If a certificate does not contain the required issuance policy, the CryptoAPI will return a certificate status code of CERT_TRUST_NO_ISSUANCE_CHAIN_POLICY.

• Name Constraints If name constraints are defined within CA certificates or CrossCA certificates, CryptoAPI combines the name constraint information found in the certificate chain, and then enforces the name constraints at the end-entity certificate. The CryptoAPI will return one of the following certificate status codes, depending on whether the name forms in the “Subject” or “Subject Alternate Name” fields match or do not match the defined name constraints.

  • CERT_TRUST_INVALID_NAME_CONSTRAINTS An invalid name constraint is defined in the certificate being evaluated.
  • CERT_TRUST_HAS_NOT_SUPPORTED_NAME_CONSTRAINT A name constraint that uses a name form not supported by the CryptoAPI is implemented.
  • CERT_TRUST_HAS_NOT_DEFINED_NAME_CONSTRAINT The certificate contains a name that does not match any permitted or excluded namespaces.
  • CERT_TRUST_HAS_NOT_PERMITTED_NAME_CONSTRAINT The certificate contains a name that matches a “not permitted” name constraint.
  • CERT_TRUST_HAS_EXCLUDED_NAME_CONSTRAINT The certificate contains a subject name that matches an excluded name constraint.

  Note The CryptoAPI method of applying name constraints is not compliant with RFC 3280, which requires name constraints defined at a CA to be applied to every certificate in the chain that is subordinate to the certificate where the name constraint is defined.

• Basic Constraints If basic constraints are defined within a CA certificate or a Cross-Certification Authority certificate, CryptoAPI will identify if the certificate is a certificate issued to a CA or a certificate issued to a user, computer, network device or service. Basic constraints can also limit the path length of a certificate chain, limiting the chain to a specific number of certificates below the CA certificate where the basic constraint is defined.

 

↑ Back to top

Certificate Revocation Process

All certificates in a certificate chain are processed to verify that none of the certificates is revoked. Revocation checking is optional from an application standpoint and may not be enforced by CryptoAPI. The Windows operating system by default checks certificate revocation status via CRLs, as the CRL processing engine is the native revocation provider included with CryptoAPI. When this functionality has been invoked, each certificate in the certificate chain is checked against the CRL that is referred to in the CDP extension in the certificate. If the certificate’s serial number is found in the CRL, the certificate is then considered revoked.

The CDP extension indicates both the protocol that must be used to retrieve the CRL (HTTP or LDAP) and the location where the CRL is stored (represented as a URL). Additionally, third-party revocation providers can be registered with CryptoAPI to add support for additional revocation status checking mechanism protocols including OCSP, SCVP, and XKMS.

When a certificate’s status is verified against a CRL, several steps must be performed to check the certificate status. These steps are performed with each certificate in the chain. These steps include:

1. Verification of the CRL signature. The CRL must be signed so that the application can determine whether it trusts the issuer of the CRL.

   Important The Windows operating system family can only verify a CRL that was signed by the same private key used to sign the issued certificate. The Windows operating system does not support indirect CRLs, which are CRLs that are signed by an entity other than the CA that signed the issued certificate.

2. Verification that the CRL has not expired. A CRL is considered expired if the current data is after the date contained in the next update field of the CRL. If the certificate that is being checked has expired, the application must verify that the CRL’s issue date follows the effective date of the certificate, but precedes the certificate’s expiration date.

3. Look up the certificate’s serial number in the CRL to determine that the serial number is not included in the CRL.

If a third-party revocation provider supporting OCSP has been registered, an OCSP responder will be used for certificate status checking; in this case, the following process applies for certificate status checking.

• Verify that the OCSP response indicates that the certificate is valid. A valid response indicates that the certificate has not been revoked.
• Verify the signature of the OCSP response. This step includes developing and processing a path that ensures that the certificate issuer or a trust point is trusted.

Currently, the Windows operating system family has no OCSP client component by default. However, a third-party OCSP client may be installed as a revocation provider to the CryptoAPI.

OCSP responders may be located using the AIA extension in the certificate as defined by RFC 2560. The Windows Server 2003 CA supports the OCSP responder location to be included in the AIA extension of certificates. Multiple revocation providers can be added to CryptoAPI depending on revocation requirements. For example, a company may want to deploy an OCSP responder on the intranet to speed up responses but leave an external URL for users or customers outside of the firewall.

Note For more information about revocation providers, see the Windows Platform SDK at http://msdn2.microsoft.com/en-us/library/default.aspx

For a general discussion about OCSP, see RFC 2560 at http://www.ietf.org/rfc/rfc2560.txt

If multiple certificate verification dynamic link libraries (DLLs) are registered, for example, the default cryptnet.dll and an OCSP client component, you can set the order CryptoAPI cycles through the providers. To verify a certificate, CryptoAPI cycles through the revocation providers that are registered until either SUCCESS or REVOKED is indicated. The providers are registered in a REG_MULTI_SZ registry key at

HKLM\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 1\CertDllVerifyRevocation\default\Dll

Two implementations of certificate revocation checking exist. Depending on the CryptoAPI version, the revocation checking is performed during or after the chain-building process.

• Post-Processing Revocation Checking The chain is built first and then the certificates in the best chain are checked for revocation. Windows 2000 with MS04-11, Windows XP with SP2 or higher, and Windows Server 2003 RTM or higher perform revocation checking after a certificate chain is chosen from all the possible chains. Performing the revocation check after the best chain is selected limits the number of network retrievals for non-cached CRLs.
• “Inline” Revocation Certificates are checked for revocation while a chain is being built. Certificate status checking is performed during the path-validation process, rather than after the chains are assembled. If a certificate in the chain is found to be revoked or expired, the chain is not discarded; the chain is only weighted less than a chain without a revoked or expired certificate. The initial release of Windows XP used inline revocation checking, but the behavior was changed to post-processing revocation checking with the release of Windows XP SP2.

Generally, CryptoAPI first searches the local certificate stores and the local cache for any CRL signed by the issuer (Certification Authority) of the certificate being validated. A cached version of a current CRL will always be used, rather than downloading a CRL that is available locally. The following logic is used to evaluate the CRL.

• If a CRL is found and the certificate’s serial number is listed in this CRL, the certificate is considered to be revoked.
• If the CRL is expired and the certificate is listed in the CRL with any reason other than certificate hold, the certificate will be considered to be revoked and no attempt to retrieve a new CRL will be performed.
• If the certificate is not listed in the CRL or the revocation reason is certificate hold, a new CRL is retrieved if the current time is past the time in the NextUpdate field in the current CRL. The new CRL is then checked to determine if the certificate is revoked. If the original reason was certificate hold, the CRL is checked to determine if the certificate is unrevoked by looking for the RemoveFromCRL revocation code.
• If the CRL cannot be obtained, the client will generate a “Server offline” error.

Note The existence of a revoked certificate in a certificate chain does not preclude the chain from being presented to the calling application as the best quality certificate chain. The best quality chain may not necessarily be a trustworthy chain.

CRL Retrieval Timeout Thresholds

If the client is able to resolve the hostname in the URL reference but no CRL is physically available, the client will attempt to download the CRL for the default threshold of 10 seconds. Windows 2000 with MS04-11, Windows XP, and Windows Server 2003 provide programmatic enhancements in reducing the timeout threshold as well as CRL unavailability detection.

The first CDP location is given a maximum of 10 seconds to succeed. Subsequent CDP locations each will use a maximum of one half of the remaining time to retrieve a specific CRL object before continuing to the next location. Each location download is attempted in sequential order. If CryptoAPI is unable to retrieve a CRL for any reason during the allotted maximum timeout interval, such as invalid path or access denied, an error of “revocation offline” will be returned to the application.

Revocation Checking with Delta CRLs

If certificate revocation checking is invoked, CryptoAPI will, in the case of the default revocation provider, examine a presented certificate for a CDP that indicates where the base CRL is published. If a delta CRL exists for a base CRL, the “Freshest CRL” extension in the base CRL provides the URL reference where the delta CRL can be retrieved from.

Note When calling the chain-building engine, the calling application can specify the policy or target for the revocation freshness information. The policy can, for example, specify that revocation information may be as old as eight hours, so if a base CRL (or delta CRL) is found, which was published only six hours previously, the chain-building engine will not attempt to retrieve a new delta CRL or base CRL.

The retrieved delta CRL has its own identifying number, plus the “Delta CRL Indicator” extension indicating the version number of the base CRL that must be used with the delta CRL.

The revocation provider may look for an updated delta CRL once the publication period has elapsed. This is determined by comparing the current time to the CRL “This Update” and “CRL Publishing Interval”. If the current time is greater than or equal to the time indicated by adding the CRL publishing interval to the CRL “This Update”, a new delta CRL should be retrieved.

When delta CRLs are implemented, the following results can occur during revocation checking.

• If the delta CRL cannot be retrieved for some reason, the revocation result returned to the certificate chaining engine will be revocation offline.
• If freshness policy is implemented and the base CRL falls within the period defined for freshness, no delta CRL retrieval is attempted.
• If the delta CRL’s indicator is less than the current base CRL, the delta CRL cannot be reached, or the delta CRL is time-invalid, a warning of no delta available should be returned to the certificate chaining engine.
• If the delta CRL’s indicator is less than the base CRL number, the chain engine should attempt to retrieve a new base CRL.
• If there is more than one delta CRL in the cache and the revocation information in the base CRL is older than what is specified by policy, the first delta CRL in the cache that meets the freshness policy will be used, even if there are more recent delta CRLs.

Note Delta CRLs are only supported by Windows 2000 clients if the MS04-11 security update is applied. Windows 2000 clients without the MS04-11 security update will only examine base CRLs during the revocation checking process.

Chain Selection Process

Once all certificate chains are determined by the CryptoAPI, the CryptoAPI will present the selected certificate chain to the calling application. It is possible that two certificate chains will have the same weight. In this case, the following process is used to select one certificate chain over the other.

1. A certificate chain with an issuance policy is selected over a certificate chain without an issuance policy.
2. A shorter chain will be selected over a longer chain. For example, when using cross-certification, you can end up with multiple, equivalently weighted chains of differing length, which chain to a root CA that you trust. In this case, the shortest chain would be selected.

The newest chain will be selected. Starting at the end certificates, the issuance date will be compared between the certificate chains, and the most recently issued certificate will be selected. If the end certificates were issued at the same time, the process is repeated at the issuing CA certificate of the end certificate, until one chain is determined to be newer than the other chain.

Generally, CryptoAPI returns certificate chains to the application that has triggered CryptoAPI. The application may decide if a different chain than the default chain is used.

Note A problem with the chain selection process has been identified with Windows XP SP1 and Windows 2000 with no service packs. In these versions, the CryptoAPI would incorrectly select a revoked certificate if a CA in the chain had two certificates, where one certificate was active and the other certificate was revoked. Without the patch described in Microsoft KB article 329433, the chaining engine would select the chain with the revoked certificate, rather than the chain with the active certificate. For more information about this issue, see the Microsoft Knowledge Base at http://support.microsoft.com/?id=329433

Certificate status checking also verifies cross-certification, which can limit the validity scope of certificates. With such constraints, a certificate administrator decides whether certificates can be used for distinct purposes such as validation of subordinate CAs, cross-certification of CAs, or to enable an end-user application.

For a detailed discussion about cross-certification, see the following documents.

• Designing and Deploying Directory and Security Services – Using Qualified Subordination at http://technet2.microsoft.com/windowsserver/en/library/c283b699-6124-4c3a-87ef-865443d7ea4b1033.mspx
• Planning and Implementing Cross-Certification and Qualified Subordination Using Windows Server 2003 at http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/ws03qswp.mspx

 

↑ Back to top

Appendix A – Certificate and Certificate Chain Status Codes

The following list of Certificate and Certificate Chain Status Codes was taken from the Microsoft Platform SDK February 2003. The status codes are defined in wincrypt.h.

Note These codes can be used with CAPIMON—the CryptoAPI Monitor to troubleshoot certificate validation problems. You can download CAPIMON and its support documentation at http://www.microsoft.com/downloads/details.aspx?FamilyId=0BFE87A8-4E79-4441-9D4C-0CAB35D49A01&displaylang=en

For a description of the error labels, search for “CERT_TRUST_STATUS” in the MSDN Library at http://msdn.microsoft.com

Error Label	Error Status Bit
CERT_TRUST_NO_ERROR	0x00000000
CERT_TRUST_IS_NOT_TIME_VALID	0x00000001
CERT_TRUST_IS_NOT_TIME_NESTED	0x00000002
CERT_TRUST_IS_REVOKED	0x00000004
CERT_TRUST_IS_NOT_SIGNATURE_VALID	0x00000008
CERT_TRUST_IS_NOT_VALID_FOR_USAGE	0x00000010
CERT_TRUST_IS_UNTRUSTED_ROOT	0x00000020
CERT_TRUST_REVOCATION_STATUS_UNKNOWN	0x00000040
CERT_TRUST_IS_CYCLIC	0x00000080
CERT_TRUST_INVALID_EXTENSION	0x00000100
CERT_TRUST_INVALID_POLICY_CONSTRAINTS	0x00000200
CERT_TRUST_INVALID_BASIC_CONSTRAINTS	0x00000400
CERT_TRUST_INVALID_NAME_CONSTRAINTS	0x00000800
CERT_TRUST_HAS_NOT_SUPPORTED_NAME_CONSTRAINT	0x00001000
CERT_TRUST_HAS_NOT_DEFINED_NAME_CONSTRAINT	0x00002000
CERT_TRUST_HAS_NOT_PERMITTED_NAME_CONSTRAINT	0x00004000
CERT_TRUST_HAS_EXCLUDED_NAME_CONSTRAINT	0x00008000
CERT_TRUST_IS_OFFLINE_REVOCATION	0x01000000
CERT_TRUST_NO_ISSUANCE_CHAIN_POLICY	0x02000000
These can be applied to chains only
CERT_TRUST_IS_PARTIAL_CHAIN	0x00010000
CERT_TRUST_CTL_IS_NOT_TIME_VALID	0x00020000
CERT_TRUST_CTL_IS_NOT_SIGNATURE_VALID	0x00040000
CERT_TRUST_CTL_IS_NOT_VALID_FOR_USAGE	0x00080000

 

Info Label	Info Status Bit
These can be applied to certificates only.
CERT_TRUST_HAS_EXACT_MATCH_ISSUER	0x00000001
CERT_TRUST_HAS_KEY_MATCH_ISSUER	0x00000002
CERT_TRUST_HAS_NAME_MATCH_ISSUER	0x00000004
CERT_TRUST_IS_SELF_SIGNED	0x00000008
These can be applied to certificates and chains.
CERT_TRUST_HAS_PREFERRED_ISSUER	0x00000100
CERT_TRUST_HAS_ISSUANCE_CHAIN_POLICY	0x00000200
CERT_TRUST_HAS_VALID_NAME_CONSTRAINTS	0x00000400
These can be applied to chains only.
CERT_TRUST_IS_COMPLEX_CHAIN	0x00010000

 

 

↑ Back to top

Appendix B – Example CRL Dump

Note: Some of the lines in the following code have been displayed on multiple lines for better readability.

X509 Certificate Revocation List:
Version: 2
Signature Algorithm:
 Algorithm ObjectId: 1.2.840.113549.1.1.5 sha1RSA
 Algorithm Parameters:
 05 00
Issuer:
 CN=CA11
 DC=contoso1
 DC=com
ThisUpdate: 6/24/2004 10:33 AM
NextUpdate: 7/1/2004 10:53 PM
CRL Entries: 2
 Serial Number: 61172ba7000000000006
 Revocation Date: 6/24/2004 10:43 AM
 Serial Number: 6116ab76000000000005
 Revocation Date: 6/24/2004 10:42 AM
 Extensions: 1
 2.5.29.21: Flags = 0, Length = 3
 CRL Reason Code
 Key Compromise (1)
CRL Extensions: 6
 2.5.29.35: Flags = 0, Length = 18
 Authority Key Identifier
 KeyID=f5 fe ff 69 79 47 fe 51 e8 fb 18 8f 03 d3 75 a4 a1 62 55 3d
 1.3.6.1.4.1.311.21.1: Flags = 0, Length = 3
 CA Version
 V0.0
 2.5.29.20: Flags = 0, Length = 3
 CRL Number
 CRL Number=5
 1.3.6.1.4.1.311.21.4: Flags = 0, Length = f
 Next CRL Publish
 Thursday, July 01, 2004 10:43:29 AM
 2.5.29.46: Flags = 0, Length = e9
 Freshest CRL
 [1]Freshest CRL
 Distribution Point Name:
 Full Name:
 
URL=ldap:///CN=CA11,CN=Server23,CN=CDP,CN=Public%20Key%20Services,
CN=Services,CN=Configuration,DC=contoso1,DC=com?deltaRevocationList?
base?objectClass=cRLDistributionPoint
 URL=http://server23.contoso.com/CertEnroll/CA11+.crl
 1.3.6.1.4.1.311.21.14: Flags = 0, Length = bc
 Published CRL Locations
 [1]Locations
 Distribution Point Name:
 Full Name:
 
URL=ldap:///CN=CA11,CN=Server23,CN=CDP,CN=Public%20Key%20Services,
CN=Services,CN=Configuration,DC=contoso,DC=com?certificateRevocationList?
base?objectClass=cRLDistributionPoint
Signature Algorithm:
 Algorithm ObjectId: 1.2.840.113549.1.1.5 sha1RSA
 Algorithm Parameters:
 05 00
Signature: UnusedBits=0
 0000 dd 02 82 6d b3 1b d7 c4 45 d4 f5 ca c9 02 6c 95
 0010 79 77 f5 14 ac e1 78 53 44 74 9e 25 67 99 fd 57
 0020 77 c3 f2 b5 dd c0 c8 8e 98 02 1b 8c 25 34 6f be
 0030 85 51 ae 07 3b dc b1 4c d6 fb a5 d2 fe 1a 33 f8
 0040 84 9d 55 3c 5c 46 82 4a 3c 76 b3 96 9f 69 23 24
 0050 71 42 fe 3b 81 6a 34 09 fd 27 0d 2a 1d 2a f7 a3
 0060 91 58 a7 1a 72 e8 f8 22 3a ad 96 73 8d 1f 29 ab
 0070 30 59 89 19 f7 30 17 e3 36 39 2f 04 fa 96 91 35
CRL Hash(md5): 5c 6b 40 6f 10 0b c9 d4 dc 92 bb 04 38 9b 15 5e
CRL Hash(sha1): ba f3 0d a3 a6 15 87 e8 7a 22 9b 1b 5a ac bd 05 eb c0 f7 c2
CertUtil: -dump command completed successfully.

 

↑ Back to top

Appendix C – CRL Return Codes

The following CRL codes can be returned when an attempt is made to retrieve a CRL.

• OK Displayed if the CRL is retrievable and not enough information is available to verify the CRL.
• Verified Displayed if all aspects of the CRL have been examined and they are completely correct.
• Wrong Issuer The URL that points to a CRL that is not cryptographically relevant for the certificate being verified. "Wrong Issuer" is displayed when a signature check on the CRL fails when verified against the public key in the issuing CA certificate. This can happen if the certificate of the issuing CA has been renewed with new keys, and the URLs are not configured with suffixes that include the default replacement parameter syntax that allows a single URL template to be used to generate unique URLs for each CRL.
• Expired Displayed if the CRL or certificate has expired.
• Old Base CRL A current delta CRL is available, but the base CRL is no longer time valid or cannot be used in combination with the current delta CRL.
• No IDP Intersection An IDP extension can be used to partition CRLs. When this is done, there must be some way to tell if a CRL signed by the correct CA certificate private key is covering the partition that includes a specific certificate being verified. Windows does this by comparing all the IDP extension URLs in the certificate being verified against the IDP extension URLs in the CRL being considered for use. If any URL appears in both extensions, the CRL is accepted for the certificates "partition". This is effectively an intersection operation. "No IDP Intersection" means no common URLs were found in the certificate and CRL IDP extensions.

Note Neither the Windows 2000 nor the Windows Server 2003 CA currently issues certificates or CRLs with IDP extensions.

 

↑ Back to top

Appendix D – CryptoAPI Policy Settings

The following policy settings are available for CryptoAPI.

• Trust Stores
• Trust Policy Management
• Trust Publisher Policy Management
• General Options

Trust Stores

Trust stores are available for trusted root stores and for enterprise trust through Certificate Trust Lists (CTLs).

The local machine Trusted Root Store is managed through a policy container in Active Directory that contains root CA certificates that are added to the following location.

Note: The line has been split into multiple lines for readability. However, while trying it out on a system you must enter it as one line without breaks.

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\SystemCertificates
\Root\Certificates\

A unique key for each root CA certificate is added using the thumbprint (hash) of the certificate as the key name. The CA certificate is stored in the Blob value as a REG_BINARY type.

The local machine Enterprise Trust Store is managed through a policy container in Active Directory that contains CTLs that are added to the following location.

Note: The line has been split into multiple lines for readability. However, while trying it out on a system you must enter it as one line without breaks.

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft
\SystemCertificates\Trust\CTLs\

A unique key for each CTL is added using the thumbprint (hash) of the CTL as the key name. The CTL is also stored in the Blob value as a REG_BINARY type.

Trust Policy Management

Trust policy management settings can be split into current settings and new settings. Both the current and new settings are system-wide settings that are set on a per-machine basis and apply to all users who log on to the machine.

Windows Server 2003 and Windows XP SP2 clients support the following policy options on the local machine that may be set in the registry as DWORD values in the following location.

• HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\SystemCertificates\Root\

  ProtectedRoots\Flags

• Type: REG_DWORD

• Values: bitmask (see the following values list)

The following values are bitmask values that may be added and applied to affect the local machine policy.

• 0x1 – Disable user root store trust This setting prevents CryptoAPI applications from using the user root store when building trusted certificate chains.

• 0x2 – Disable user root store changes This setting prevents the user from adding root CAs to the user trusted root store.

  Note This value may be set through Group Policy in Windows Server 2003.

• 0x4 – Disable user root store purge This setting prevents the user from removing root CAs from the user trusted store that are also included in the local machine trusted root store.

• 0x8 – Disable default machine third party roots trust This setting disables all third-party roots on the machine that are installed by default or downloaded through Windows Update. This setting does not disable the default code signing roots that are required for system boot or to disable the Microsoft code signing root. This setting is OFF by default.

• 0x10 – Disable the requirement for NTAuth policy processing This disables the requirement for an issuing CA to be present in the NTAuth store of the local machine.

  Note This value may be set through Group Policy in Windows Server 2003.

• 0x20 – Disable name constraint enforcement for undefined name types By default, Windows XP SP2 and Windows Server 2003 will reject undefined name types in a name constraint validation. Setting this value will accept all name forms that are not explicitly defined. Note that this is not exposed in existing GPO user interfaces (UIs).

  Note This option is not exposed in the existing GPO UI.

 

↑ Back to top

Trusted Publisher Policy Management

Trusted Publisher management will be a separate GPO object (property page) GPO UI. The Trusted Publisher management will use the existing Windows XP definitions in wincrypt.h for the registry keys, values, and locations. Both user stores and machine (inherited) stores will be supported. Trusted publisher policy will be a union of user, machine, and local trusted publisher stores. The policy path in the registry is the following for both machine AND user policy.

• HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\SystemCertificates\TrustedPublisher\

  Safer\

• HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\SystemCertificates\TrustedPublisher\

  Safer\

• Type: REG_DWORD

• Name: AuthenticodeFlags

The following values can be defined for the Authenticode Flags.

• 0x0 – Allow end user selection of Trusted Publishers Allows end users to add Trusted Publisher (Authenticode) certificates to the Trusted Publisher store of the current user profile. This would not affect the local machine store. Users can still add certificates to the Untrusted Certificates store. This setting will be ON by default.

• 0x1 – Allow only local machine administrators to select Trusted Publishers Allows only local machine administrators to add Trusted Publisher (Authenticode) certificates to the Trusted Publisher store of the local machine. This setting will be OFF by default.

• 0x2 – Allow only Enterprise Administrators to select Trusted Publishers Allows only the domain-based (GPO) Trusted Publisher (Authenticode) certificates to be added to the Trusted Publisher store of the local machine. This setting will be OFF by default.

• 0x100 – Enable revocation of Trusted Publisher certificate chain Forces the system to validate the revocation status of a Trusted Publisher (Authenticode) certificate chain when a Trusted Publisher certificate is added to the user or local machine Trusted Publisher store. This setting will be ON by default. This is a change from Windows XP behavior.

• 0x200 – Enable revocation of Authenticode package time stamp Forces the system to validate the time stamp of a Trusted Publisher (Authenticode) certificate chain when a Trusted Publisher certificate is added to the user or local machine Trusted Publisher store. This setting will be OFF by default.

  Note Trusted Publisher revocation checks, when configured, always ignore revocation offline errors. This policy will stay in effect for Longhorn and not be configurable.

 

↑ Back to top

General Policy Options

The following general policy options can be defined in the registry of a client computer.

• Disable Basic Constraints Disables the basic constraint check for CA certificates when building a certificate chain. This setting was first introduced with MS02-050.

  • Location: HKLM\SOFTWARE\Microsoft\Cryptography\OID\

    EncodingType 0\CertDllCreateCertificateChainEngine\Config

  • Type: REG_DWORD

  • Name: DisableMandatoryBasicConstraints

  • Value: 1

• URL Retrieval Timeout Defines the default URL timeout for AIA retrievals and for non-accumulative CRL retrievals. This setting was first introduced with MS04-011. This registry key will be exposed as a Group Policy UI item on the policy property page titled: “Default URL Retrieval Timeout”, with a list box control of units in seconds. The default value will be 15 seconds. Although the UI will only allow a maximum value of 1000 seconds, the actual registry key and policy processing will allow an increased value to 65536 seconds.

  • Location: HKLM\SOFTWARE\Microsoft\Cryptography\OID\

    EncodingType 0\CertDllCreateCertificateChainEngine\Config

  • Type: REG_DWORD

  • Name: ChainUrlRetrievalTimeoutMilliseconds

  • Value: If this value is set to 0 or if this value is undefined, the default value that is used is 15000 milliseconds.

• Aggregate URL Retrieval Timeout Defines the default revocation accumulative URL timeout. The first revocation URL retrieval uses half of this timeout. This registry key will be exposed as a Group Policy UI item on the policy property page—Default Accumulative URL Retrieval Timeout—with a list box control of units in seconds. The default value is 20 seconds. The UI will only allow a maximum value of 1000 seconds, but the actual registry key and policy processing will allow an increased value to 65536. This setting was first introduced with MS04-011.

  • Location: HKLM\SOFTWARE\Microsoft\Cryptography\OID\

    EncodingType 0\CertDllCreateCertificateChainEngine\Config

  • Type: REG_DWORD

  • Name: ChainRevAccumulativeUrlRetrievalTimeoutMilliseconds

  • Value: If this value is set to 0 or if this value is undefined, the value that is used is 20000 milliseconds.

• Maximum AIA URL Count Defines the default number of AIA URLs that will be retrieved for the purpose of chain-building. This registry key will be exposed as a Group Policy UI item on the policy property page—Default Maximum AIA Retrieval Timeout—with a list box control in integer units with a default value of 5. The UI only will have a maximum value of 25 URLs, but the actual registry key and policy processing will allow an increased value to 65536. This setting was first introduced with MS04-011.

  • Location: HKLM\SOFTWARE\Microsoft\Cryptography\OID\

    EncodingType 0\CertDllCreateCertificateChainEngine\Config

  • Type: REG_DWORD

  • Name: MaxAIAUrlCountInCert

  • Value: If this value is undefined, the value that is used is 5.

 

↑ Back to top

Appendix E – Status Checking in a Single-Tier CA Topology

The single CA is the most basic PKI topology. In this case, a single CA provides all certificates and CRL information. Figure 10 shows an example of a single CA, where the CA certificate has been renewed with the same key pair.

Figure 10. Certificate Chain in a Single CA Structure

In a single CA topology, the number of certificate chains that are built depends on the renewal status of the root CA. For all certificate chains, the root CA certificate is the start of the chain, and the chain terminates at the end-entity certificate.

Regardless of the matching algorithm, the chain-building engine will choose the CA certificate of CA1 as parent certificate.

Assume that the certificate for User1 was signed with the CA1 certificate with the serial number 6e5f. If the certificate of CA1 was renewed using the existing key material, the chain-building engine can build different chains depending on the matching algorithm because the SKI is the same for both CA certificates.

• Exact match If the certificate of User1 contains the CA certificate’s serial number and subject in the AKI extension, the certificate-chaining engine will pick the parent certificate with the serial number 6e5f as shown in Figure 11.

  

  Figure 11. Certificate Chain Formed for the Original User Certificate When an Exact Match Is Used

• Key match If the certificate of User1 only contains the CA certificate’s KeyID in the AKI extension, the certificate-chaining engine can pick either of the CA1 certificates since, in this case, the key has not been renewed and both certificates would carry the same KeyID. However, if the CA certificate renewal would have been performed with generating a new key pair, the chaining engine would be able to distinguish between the CA certificates and would pick 6e5f as parent certificate. Figure 12 shows the two chains that can be formed when the CA certificate is renewed with the same key pair and the AKI of the User1 certificate only contains the KeyID of the issuing CA.

  

  Figure 12. The Two Certificate Chains Formed When the AKI Contains Information for Key Matching

• Name match If the certificate of User1 does not include an AKI extension, the certificate-chaining engine can pick either of the CA1 certificates since both certificate’s subject name matches the issuer name extension of the User1 certificate. Figure 13 shows the two certificate chains that can be formed in this case.

  

  Figure 13. The Two Certificate Chains Formed When No AKI Exists in the Issued Certificates

 

↑ Back to top

Appendix F – Status Checking for a Hierarchical CA

In a multi-tier topology, multiple CAs are organized in a structure with a single root CA. Figure 14 shows a PKI topology where the CA certificates for CA11 and CA111 have been renewed. Assume that the renewal for CA111 was used with a new key generation, whereas for CA11, the same key-set was used.

Figure 14. A Multi-tier Topology

Exact match

In the case of an exact match, all certificates in the chain (excluding the root) would contain the subject, the serial number, and possibly the subject-key identifier of the issuing CA in the AKI extension. Based on the certificates available in this scenario, the certificate chain shown in Figure 15 would be formed for User1’s initial certificate.

Figure 15. The Certificate Chain Formed When the CryptoAPI Uses Exact Matching

Table 4 shows the details of the certificate chain; note how the details of each certificate’s AKI field matches the parent certificate’s attributes.

Table 4. Details of the Certificate Chain for the CrypoAPI

Subject	Serial #	AKI	Parent SKI	Parent Subject	Parent Serial #
User1	B653	KeyID=E37F Issuer=CA111 SerialNumber=3428	E37F	CA111	3428
CA111	3428	KeyID=F5FE Issuer=CA11 SerialNumber=6148	F5FE	CA11	6148
CA11	6148	KeyID=3E9C Issuer=CA1 SerialNumber=6E5F	3E9C	CA1	6E5F
CA1	6E5F	n/a	n/a	n/a	n/a

When time passes and User1’s certificate is renewed, the CA certificate chain that is built differs as the CA11 and CA111 certificates have been renewed. Because the AKI extension of each certificate contains information about the issuing CA’s serial #, subject, and KeyID, an exact match results in the certificate chain shown in Figure 16 being built.

Figure 16. The Certificate Chain Formed When an Exact Match Is Used in a Hierarchical CA Structure

Table 5 shows the details of the certificate chain. Again, an exact match is used when building the certificate chain because the AKI of the issued certificates includes the details necessary to find the exact CA certificate used to sign the issued certificate.

Table 5. Details of the Certificate Chain in a Hierarchical CA Structure

Subject	Serial #	AKI	Parent SKI	Parent Subject	Parent Serial #
User1	B654	KeyID=E38C Issuer=CA111 SerialNumber=3429	E38C	CA111	3429
CA111	3429	KeyID=F5FE Issuer=CA11 SerialNumber=6149	F5FE	CA11	6149
CA11	6149	KeyID=3E9C Issuer=CA1 SerialNumber=6E5F	3E9C	CA1	6E5F
CA1	6E5F	n/a	n/a	n/a	n/a

Key match

 In this example, if the AKI of the issued certificate contained the key ID of the CA certificate that issued the certificate, a single chain would be built. The chain would be the same chain as the chain built using an exact match, except that, in this case, the key ID in the AKI extension of the issued certificate would be matched to the SKI extension of the issuing CA’s certificate as shown in Figure 17.

Figure 17. The Certificate Chain Implemented When the AKI Contains Key Matching Information

When User1’s certificate is renewed, the CA certificates for CA11 and CA111 have been renewed. Because the CA11 certificate is renewed using the same key pair, two certificate chains can be formed by the chaining engine as shown in Figure 18.

Figure 18. The Two Chains Formed When Key Matching Is Implemented

As you can see, the only certificate in the two certificate chains that differs is the CA11 certificate. Because the CA11 certificate was renewed with the same key pair, either CA11 certificate is valid in the certificate chain.

Name match

 If the issued certificates do not have an AKI extension, a name match is used to build the chain. For the initial certificate, the same certificate chain is built, but the chain is built by matching the Issuer Name field in the issued certificates to the Subject Name field in the CA certificates as shown in Figure 19.

Figure 19. A Single Chain Is Formed Initially When the CA Certificates Do Not Include an AKI Extension

When User1’s certificate is renewed, both CA11 and CA111’s certificate are renewed (CA11 with the same key pair and CA111 with a new key pair). Because no AKI extension exists in the certificates, the chaining engine can build four possible CA chains as shown in Figure 20.

Figure 20. Four Chains Are Possible When Two CA Certificates Are Renewed and the Certificates Do Not Include an AKI Extension             

↑ Back to top

Appendix G – Status Checking for Cross-Certification

Cross-certification allows two organizations to establish a trust relationship between PKI topologies. There are several different ways that topologies can be cross-certified. Figure 21 shows cross-certification between root CAs.

For more information about deciding where cross-certification should be established between two CA hierarchies, see the Designing a Public Key Infrastructure section in the Windows Server 2003 Server Resource Kit Deployment Guide.

Note Cross-certificates have the same subject and SKI as the CA certificate with the matching subject name in the foreign CA hierarchy.

Figure 21. Cross-Certified Topologies

Because of the cross-certification, several paths can be built. Figure 22 shows the first path that can be built uses exact matches to build a chain that chains to the Root CA certificate for CA1. This chain is shown in Figure 22.

Figure 22. The CA Certificate Chain Formed When a Client Includes CA1 in the Trusted Root Store

This chain would be built by any application running on a computer that has the CA1 certificate in its trusted root store.

A second certificate chain can be built by using the Cross-Certificate issue from CA2 to CA1. This chain chains to the CA2 root CA as shown in Figure 23.

Figure 23. The CA Certificate Chain Formed When a Client Includes CA2 in the Trusted Root Store

This shows that the certificate chain is built using a combination of exact matches and key matches. This chain would be built by any computer that includes CA2 in the trusted root store.

Note If a computer included both CA1 and CA2 in its trusted root store, the certificate-chaining engine will always prefer the shorter of the two chains.

For more information, see the “Planning and Implementing Cross-Certification and Qualified Subordination Using Windows Server 2003” white paper at the Microsoft Web site http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/ws03qswp.mspx

Cross-certification may also take place between subordinate CAs, rather than between root CAs as shown in Figure 24. The actual design may vary depending on specific organizational or business requirements.

Figure 24. Cross-Certification Between Subordinate CAs

As with the previous Cross-Certification Authority example, the first chain terminates at the CA1 root CA computer. In this case, all CA certificates are found using a key match, as the AKI extension in the certificates contains the key ID of the issuing CA, as shown in Figure 25.

Figure 25. The Certificate Chain Formed When CA1 Is in the Trusted Root Store

If the certificate chain is evaluated by a computer that has the CA2 in its trusted root authority store, a chain is built that includes the CrossCA certificate issued by CA21 to CA11. When the chaining engine completes the chain-building process, the chain shown in Figure 26 is built.

Figure 26. The Certificate Chain Formed When CA2 Is in the Trusted Root Store

As was the case with the previous chain, each certificate in the chain was found by using a key match. In all cases, the AKI of the issued certificate contains the KeyID of the issuing CA certificate.

Important The Windows certificate-chaining engine is configured to not propose paths that contain the same certificate more than one time. This prevents the cross-certification path from being presented more than once in a certification path.

↑ Back to top

Appendix H – Status Checking for a Bridge CA

A bridge CA deployment requires a level of trust between the partner organizations and the organization hosting the bridge CA. A common scenario where this is deployed is a large organization with mainly independent subsidiaries. The bridge CA allows PKI interoperability between the subsidiaries, yet allowing private management of the individual CA hierarchies. For more information, see the “Planning and Implementing Cross-Certification and Qualified Subordination Using Windows Server 2003” white paper at the Microsoft Web site http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/ws03qswp.mspx

A bridge CA structure takes cross-certification between two organizations and extends the model to allow multiple organizations to configure trust between their CA hierarchies. In a bridge CA structure, one CA becomes the hub or bridge for the trust between the CA hierarchies. Figure 27 shows a bridge CA that links three separate CA hierarchies.

Figure 27. PKI Topology with a Bridge CA

In this cross-certification example, different certification paths can be built for the user certificate. If your computer includes CA1 in the trusted root store, the simple chain shown in Figure 28Error! Reference source not found. can be built using a combination of exact matching and key matching.

Figure 28. The Certificate Chain Formed When CA1 Is in the Trusted Root Store

The chaining engine builds a different chain when CA2 is located in the trusted root store. This chain uses both the certificates issued from CA2 to CA0 and the certificate issued from CA0 to CA1. Figure 29 shows the chaining engine also uses a combination of exact matching and key matching to build the certificate chain.

Figure 29. The Certificate Chain Formed When CA2 Is in the Trusted Root Store

The chaining engine takes a slightly different approach when CA3 is located in the trusted root store of the computer evaluating the User1 certificate as shown in Figure 30. The difference is that the certificate issued by CA3 to CA0 does not include an AKI extension. The exclusion of the AKI in the certificate causes the certificate-chaining engine to use a name match to select the CA3 root CA certificate.

Figure 30. The Certificate Chain Formed When CA3 Is in the Trusted Root Store

In some cases, a fourth chain can be formed if the Bridge CA (CA0) is added to the trusted root CA store of a computer. When CA0 is included in the root CA store, the certificate chain shown in Figure 31 is built by the certificate chaining engine.

Figure 31. The Certificate Chain Formed When CA0 Is in the Trusted Root Store

Note In addition to the certificate paths, additional paths can exist if any of the CAs in the shown certificate paths renews its CA certificates.

 

↑ Back to top

Related Links

The following Internet links are referenced in this white paper.

• The latest information and additional white papers on PKI technologies http://www.microsoft.com/pki
• Planning and Implementing Cross-Certification and Qualified Subordination Using Windows Server 2003 white paper http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/ws03qswp.mspx
• A programmer’s reference to CryptoAPI; search for “Cryptography Functions” at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/seccrypto/security/cryptography_functions.asp
• Details on the certificate trust status http://msdn.microsoft.com/library/default.asp?url=/library/en-us/security/security/cert_trust_status.asp
• The current list of root certificates that are distributed with Windows http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsecure/html/rootcertprog.asp
• Details on certificates that are included in the non–trusted root store http://support.microsoft.com/?id=293817
• Details on the OIDs used by Microsoft Cryptography http://support.microsoft.com/?id=287547
• Details about WinHTTP and WinInet; search for “WinINet Reference” or “WinHTTP Reference” http://msdn.microsoft.com/library.
• Details on selecting a trust model for your CA hierarchy http://msdn2.microsoft.com/en-us/library/default.aspx
• Details about the Root certificates update component of the Control Panel; search for “Update Root Certificates” http://search.microsoft.com.
• Full details about status and error code definitions; search for CERT_TRUST_STATUS http://msdn.microsoft.com/library.
• A general discussion about PKI architectures http://technet2.microsoft.com/windowsserver/en/library/c283b699-6124-4c3a-87ef-865443d7ea4b1033.mspx
• Details on Windows-supported revocation providers http://technet2.microsoft.com/windowsserver/en/library/c283b699-6124-4c3a-87ef-865443d7ea4b1033.mspx
• RFC 2560 http://www.ietf.org/rfc/rfc2560.txt
• Details on a problem with the chain selection process when running Windows XP SP1 http://support.microsoft.com/?id=329433
• Designing and Deploying Directory and Security Services - Using Qualified Subordination http://technet2.microsoft.com/windowsserver/en/library/c283b699-6124-4c3a-87ef-865443d7ea4b1033.mspx
• Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure white paper http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/ws3pkibp.mspx 

 

↑ Back to top

Acknowledgements 

• David Cross
• Sergio Dutra
• Nick Voicu
• Kelvin Yiu
• Derek Adam
• Fei Chua
• Shivaram Mysore
• Vic Heller
• Nisha Gambhir

 

↑ Back to top

Additional PKI Resources

• Community directory for documentation and information: Windows PKI Documentation Reference and Library(http://social.technet.microsoft.com/wiki/contents/articles/987.windows-pki-documentation-reference-and-library.aspx)
• Frequently asked questions (FAQs) list Active Directory Certificate Services (AD CS) Frequently Asked Questions (FAQ) (http://social.technet.microsoft.com/wiki/contents/articles/1587.active-directory-certificate-services-ad-cs-frequently-asked-questions-faq.aspx)
• Support forum: Windows Server Security Forum (http://social.technet.microsoft.com/Forums/en-US/winserversecurity/threads)
• Product team blog: Windows PKI Blog (http://blogs.technet.com/b/pki/)
• Support Team Blog: Ask the Directory Services team (http://blogs.technet.com/b/askds/)
• Script repository: TechNet Script Center Repository (http://gallery.technet.microsoft.com/scriptcenter) search for Certification, Certificate, or PKI
• Technology overview: Active Directory Certificate Services (AD CS) Overview

 

↑ Back to top