Applies to: Windows Server 2003, Windows Server 2008, Windows Server 2008 R2 

Often the certificate path/revocation checking issues that certification authority (CA) admins encounter are caused by invalid CDP (CRL Distribution Point) or AIA (Authority Information Access) configuration. This article covers the Certificate Chaining Engine (CCE) and how it can be used for troubleshooting purposes.


Certificate Chaining Engine Background

Just like symmetric & asymmetric encryption, certificate chains, and certificate trusts, the CCE is a public key infrastructure (PKI) fundamental. Millions of people see results the CCE everyday when their certificates either work or do not work.

In order for any specific certificate to be trusted, the certificate chain up to the root CA must be trusted explicitly by your operating system system. Certificate trust is determined by the CCE by building certificate chain (also known as Certification Path). Let's see certificate chains on common examples — SSL web sites. When entering the web site (Figure 1) you see a green bar indicating that the site's SSL (Extended Validation or EV) certificate is trusted by your system . However, entering the web site, you see an error message and red 'X' (Figure 2). Both messages are the result of the certificate chaining engine validation process.

Trusted certification path

Figure 1 - Certificate

Untrusted certification path

Figure 2 - Certification Path

How are certificates in the certificate chain are obtained? Certificates are either (1) added into the operating system, (2) integrated into an application when it is released or (3) installed by a computer or application administrator.

↑ Back to the top

Building the Certificate Chain

Windows operating system uses the following methods for retrieving certificates for certificate chains:

  1. Via the local certificate store
  2. Using the Authority Information Access (AIA) extension
  3. Using a PKCS#7 container with a full or a partial chain,
  4. Crypt32.dll and Microsoft Update web site

↑ Back to the top

Local certificate store method

This is the first method used by CryptoAPI to obtain possible certificates for the certificate chain. The following local certificate containers are used: Trusted Root CAs, Intermediate CAs and Third Party Root CAs. As example, you can examine an intermediate certificate at web site. VeriSign's Extended Validation CA certificate does not contain any information about the issuer. This is because VeriSign is well-known issuer and its certificates are installed on each Windows operating system.

The CryptoAPI uses the local certificates store to obtain required certificate, which reduces certificate chain building time. However this is applicable only to the CA certificates that were already installed. If the local certificate store does not contain the required certificates, one of the other methods are used, as described in the following sections.

↑ Back to the top

Authority Information Access method

Notice that in figure 2 (Fig.2) the certificate is issued by Winextreme, a private CA server. Most people would not know about this particular issuing CA, but they could check the entire certificate chain in their Web browser or other certificate enable application. If you open a leaf certificate and examine its Authority Information Access (AIA) extension, you see the following:

[1]Authority Info Access

     Access Method=Certification Authority Issuer (

     Alternative Name:


This URL is used by a certificate chaining engine to retrieve issuer certificate. Once it is retrieved, the CCE determines whether the issuer certificate is present in a self-signed form, indicating an end of chain or root certificate. If it is a self-signed root certificate, the CCE performs certificate validation (described later in this article). Otherwise the CCE examines AIA extension in the issuer's certificate for additional chain certificates. An example for this is as follows:

[1]Authority Info Access

     Access Method=Certification Authority Issuer (

     Alternative Name:


In the example above, when the Winextreme root CA certificate is retrieved, it is presented as a self-signed certificate. The CCE then indicates that the certificate chain is complete.

Note: You can open the URLs: shown in the previous examples in and The second certificate is shown in Figure 3 when downloaded by a Windows 7 client computer that does not trust the root CA.

Figure 3 - Untrusted Root Certificate

↑ Back to the top

PKCS#7 method

The PKCS#7 certificate method is common, as are the DER, PFX, and serialized store certificate types. A PKCS#7 message can contain multiple certificates and as such acts as a certificate container. This method allows server applications to simplify certificate trust chain building by delivering the client (leaf) certificate with the complete or partial certificate chain. The client application can then use multiple certificates, if delivered, for certificate chain building purposes. For example, Internet Information Service (IIS) by default sends to the client a full server certificate chain in the PKCS#7 format. An example of the PKCS#7 method from the web site is shown in Figure 4.


Figure 4 - Untrusted Certificate Chain

If you switch to the 'Certification Path' tab you will see that an issuer is presented:

Figure 5 - Incomplete certification path

However issuer (Vimpelcom External CA) is not presented in the self-signed form and additional CA certificates in the chain must present:

Figure 6 - Missing issuer

The BeeLine certificate illustrate how PKCS#7 method works. Since URLs in the certificate Authority Information Access extension are invalid and Vimpelcom External CA is not a common CA, the only way to retrieve it's certificate is to use PKCS#7 containers.

↑ Back to the top

Crypt32.dll and Microsoft Update

When you open Trusted Root CAs container on Windows XP/Windows Server 2003 you will see a lot of certificates. When you open this container on Windows Vista and newer operating system — only few common trusted root CA certificates are shown. However this doesn't mean that only displayed certificates are trusted. Trusted root CA list is approximately the same (comparing with Windows XP/Windows Server 2003), but rarely usable certificates are stored in the crypt32.dll file and on Microsoft Update web site.

To see how this works, open the Trusted Root CAs container on your Windows Vista or newer box. You should not see a certificate issued to/by: E-ME SSI (RCA). Now open a certificate from this URL: You'll see that this root certificate is trusted. Now refresh local Trusted Root CAs container content and you will see this certificate in the list. There is no magic. If your computer is connected to the internet, certificate chaining engine will check Microsoft Update web site for this certificate. And if found (as in a given example) it is downloaded and installed to the certificate store. If your computer is not connected to the internet, CCE will extract certificate content from crypt32.dll library and install the certificate to the Trusted Root CAs container.

In other words, starting with Windows Vista, root CA certificates are typically installed on demand. For more details see the following KB article: Windows root certificate program members.

↑ Back to the top

Binding Certificates

Once chain certificates are retrieved by using one of the mentioned above method CCE binds (arranges) them to the corresponding position in the chain. CCE uses one of the several methods for certificate binding:

  • Exact match
  • Key match;
  • Name match.

↑ Back to the top

Arranging Certificates: Exact Match

In order to bind the issuer certificate with another certificate the following values must match:

  • Key identifier;
  • Issuer name;
  • Certificate serial number.

For example, take a certificate from Intermediate CAs container with the Serial Number=17. This is the StartCom Extended Validation Server CA certificate. This certificate contains Authority Key Identifier (AKI) extension with the following content:

KeyID=4e 0b ef 1a a4 40 5b a5 17 69 87 30 ca 34 68 43 d0 41 ae f2

Certificate Issuer:

     Directory Address:

          CN=StartCom Certification Authority

          OU=Secure Digital Certificate Signing

          O=StartCom Ltd.


Certificate SerialNumber=01

Issuer certificate must match all these values in the Subject Key Identifier (SKI) extension, Subject and Serial Number fields respectively. In other words: KeyID value in the particular certificate AKI extension must match the value in the Subject Key Identifier (SKI) extension of the issuer certificate. Certificate Issuer value in the particular certificate must match the value in the Subject field of the issuer certificate. And Serial Number in the particular certificate must match the value in the Serial Number of the issuer certificate. If one of them doesn't match, certificate binding will fail and CCE will attempt to find another certificate that can be considered as a particular certificate issuer.

You can switch to the Certification Path tab and ensure that these values are identical. As the result CCE can safely bind issuer certificate to the particular certificate as issuer.

Exact match method can correctly bind certificates even if there are several CA certificates with the same Subject values (for example, expired and renewed CA certificate). If a CA certificate was renewed with a new key pair Subject Key Identifier in the CA certificate and Serial Number will be different since new public key is generated and resulting hash will be different. If CA certificate was renewed by using existing key pair only serial number is changed and CCE will be able to bind a correct certificate as a particular certificate issuer.

Note: according to RFC 5280 (§, each CA server must issue certificates with unique serial number within a given CA server.

Tip: What is Subject Key Identifier or SKI? This is a hash (commonly MD5 or SHA1) that is calculated over subject's public key. The value of this extension in the CA certificate should appear in the Authority Key Identifier (AKI) extension of the issued certificates.

↑ Back to the top

Binding Certificates: Key match

Since exact match is not widely used, instead key match is used. Again, you can examine SSL certificate at the web site (Fig.1).

Authority Key Identifier (AKI) extension in the leaf (web server) certificate contains the following information:

KeyID=fc 8a 50 ba 9e b9 25 5a 7b 55 85 4f 95 00 63 8f e9 58 6b 43

Subject Key Identifier in the the issuer's certificate contains the following information:

fc 8a 50 ba 9e b9 25 5a 7b 55 85 4f 95 00 63 8f e9 58 6b 43

In this match form Authority Key Identifier value in the particular certificate must match the value in the Subject Key Identifier of the issuer certificate. You can ensure that in a given example they are identical. If they are identical, the certificates can be bounded as a part of the certificate chain, otherwise certificate binding will fail. This is the most common certificate binding method.

Key match method can correctly bind certificates even if there are several certificates with the same Subject values (for example, expired and renewed CA certificate). If CA certificate was renewed with new key pair Subject Key Identifier in the CA certificate will be different since new public key is generated and resulting hash will be different. However Key match cannot track whether CA certificate was renewed by using existing key pair and can randomly bind two or more certificates as a particular certificate issuer. Since CA key pair remains the same both previous and renewed CA certificate can be used to validate current certificate signature and can be used for chain building.

↑ Back to the top

Binding Certificates: Name match

Since X.509 Version 1 certificates don't contains extensions (as well as Authority Information Access, Authority Key Identifier, Subject Key Identifier and so on) there is only one way to bind certificates to the chain — name match. In this case Issuer field in the particular certificate must match Subject field of the issuer certificate.

↑ Back to the top

Signature verification

It looks that you can exploit V1 certificates and Name match for fraudulent certificates. For example, create a certificate with the Issuer field matching to any trusted issuer's Subject field. Mentioned arranging methods are used only to arrange and bind certificates in the certificate chain. Certificate chaining engine checks each certificate signature against issuer's public key (is extracted from the Public Key field of the issuer certificate). If the signature is valid, certificate is valid too. Otherwise chain is complete, but considered as invalid. Figure 5 illustrates an example of this situation.

Figure 7 - Certification Path

↑ Back to the top

And more...

Certificate chaining engine may apply additional restrictions and processing rules to the certificate chain such name, policy constraints and so on. These are fully described in the RFC 5280 and are out of the scope of this article. Also, once certificate chain is built application may perform certificate revocation checking (unlike chain building, certificate revocation checking is an application choice).

↑ Back to the top


As it was demonstrated certificate chaining engine is one of the important PKI fundamentals that is responsible for certificate chain building and certificate trust checking. In order to chain building succeed each certificate should be properly formed and follow at least basic requirements as discussed above. Also we have learned the purposes of the less-known certificate extensions, like Authority Information Access (AIA), Authority Key Identifier (AKI) and Subject Key Identifier (SKI) and extension-specific processing rules.

↑ Back to the top

Related links

↑ Back to the top