PKI - Certificate Chain Validation

In Part 1 ("PKI: Public Key Infrastructure – The Bane of Many Systems Administrators," October 2012) and Part 2 ("The Role of a Certificate Authority (CA) in PKI," October 2012) of this series on PKI, I explained the basics of PKI and the role of the CA. In this article I focus on how certificate chains are verified.

Well first off, what is a certificate chain? It is simply a list of certificates that are related to each other because they were issued within the same CA hierarchy. In order for any certificate to be validated, all of the certificates in its chain have to be validated. To illustrate this real world, let’s look at how a SSL certificate chain is verified. Another term used for certificate chain is certification path.

If I bank at Key Bank, my SSL connection to https://www.key.com results in the following certificate chain as shown on the certificate’s Certification Path tab:

Each of these certificates has to be validated separately but overall successful certificate chain validation depends on the client first having access to all of the certificates in the chain. In this simple example, the bottom certificate www.key.com (the web server’s SSL cert) was pulled during my https request but the ones above it, the intermediate (sub) CA and the ROOT CA certificates also need to be accessible for validation to take place.

There are a few ways your operating system will find certificates from the chain that it does not have local access to. If you want to examine the list of CA certificates that already reside in the local certificate store, create a MMC console and add in the CERTIFICATES snapin focused on The Local Computer. Then navigate down to all of the folders that have “Certification Authorities” in the title (see graphic below). How did these certificates end up there? Microsoft put them there and will periodically update them through a Windows update. 

If the CA Certificate the client is attempting to validate is not in the certificate store, the client will do one of the following:

1. Crypt32.dll has a cache of CA certificates - not all of them which show up in the local computer certificate store - but which are dynamically retrieved as necessary. This cache only contains the CA certificates Microsoft placed there when the OS was released to manufacturing.

2. For newer Microsoft OS versions, the needed CA certificate is automatically downloaded from Microsoft on the fly but only for those CAs who have joined Microsoft’s root certificate program. 

3. The needed CA certificate is pulled over the network from an AIA point. AIA stands for Authority Information Access and is just a fancy term for the network location (http or ldap) where a CA stores a copy of its own certificate. The AIA point is a potential point of failure so let’s take a closer look at this process.

AIA – Just a Storage Location

Each certificate is digitally signed by the CA that issued it with the exception of a ROOT CA that self-signs its own certificate. Since a digital signature is made with a private key, the corresponding public key needs to be retrieved to verify the signature. Let’s stack up our certificate chain to see how this works.

In graphic number 1, the certificate chain validation process from my earlier example begins with the client validating the www.key.com web server SSL certificate. The signature on that cert was made with the private key of Verisign’s issuing intermediate CA (also known as a subordinate CA or sub). In order to validate this sub CA’s signature we need access to the sub CA’s corresponding public key (embedded inside of that sub CA’s certificate). If the validating client cannot source the sub CA certificate locally, and cannot receive it automatically from Microsoft, it retrieves a copy from the AIA point.

The AIA point itself is just a URL that points to a web server or ldap server that contains a copy of the issuing CA’s certificate (the CA’s public key). In my example, the sub CA’s AIA was embedded in the Key Bank web server’s certificate by the sub CA as a way of stating “I issued this SSL certificate, signed with my private key, if you want to verify that this certificate is valid, go to this location to get a copy of my public key”. 

As part of the certificate chain validation process, the sub CA’s certificate must also be validated. In graphic number 2, the sub CA’s certificate was signed by the ROOT and the ROOT’s public key is needed to validate that signature. Even though the sub CA has an embedded AIA that says “Go here to get the ROOT CA certificate”, a ROOT CA certificate will never be pulled from an AIA point during cert chain validation. It is the one certificate that either must already reside locally in the computer certificate store or Crypt32.dll cache or auto-downloaded directly from Microsoft (if the CA is a member of Microsoft’s root certificate program), otherwise the validating client will receive the dreaded “This certificate could not be validated up to a Trusted ROOT CA” error message.  

Effectively the cert chain validation ignores the AIA for a ROOT CA certificate, requiring instead that it be retrieved only from a trusted location - either from the local OS or directly from Microsoft. The ROOT CA self-signs its own certificate so its own public key will validate that signature.
 


In summary, certificate chain validation is an essential part of PKI and happens behind the scene millions of time a day both in E-commerce as well as internal corporate PKI operations. Certificate chain validation can only be successful if the validating client can locate all the certificates in the chain and the ROOT CA certificate from a Microsoft authorized location. In Part 4 of this series I will examine the other important certificate validation process of certificate revocation list (CRL) checking.