Basics: Finding certificates and validating the certification path

In order to determine whether a certificate has been issued by a certification authority that has been classified as trustworthy, a trust chain must be formed. To do this, all certificates in the chain must be determined and checked. Microsoft CryptoAPI builds all possible certificate chains and returns those with the highest quality to the requesting application.

To better illustrate how this works, the following example explains the process of locating certificates using a three-level PKI hierarchy.

1. For the end-entity certificate to be verified, the download path for the CA certificate of the issuing CA is determined from the Authority Information Access (AIA) field. This is then downloaded and saved locally.
2. The end entity certificate is now assigned to the CA certificate of the issuing CA (see the following paragraph), which must now be verified next.
3. For the issuing CA certificate to be verified, the download path for the certificate of the issuing certification authority (the policy CA) is determined from its AIA field. This is then downloaded and saved locally.
4. The CA certificate of the issuing CA is now mapped to the CA certificate of the policy CA, which must now be verified next.
5. The issuing certification authority (the root CA) is determined for the policy CA certificate to be verified. This certificate must be in the local list of trusted root CAs to be recognized as valid. Even though the AIA field of the issuing CA's certificate points to the root CA, and thus the client would theoretically be able to download and store it, a client would still consider the certificate untrusted unless the root CA certificate was previously stored in local storage by a system administrator. Without this behavior, there would be no control over which CA certificates should be trusted and which should not.

A certificate is assigned to its certification authority by comparing certain attributes within both certificates. There are three possibilities here, depending on which attributes are contained in the certificates:

1. Exact Match. If the end entity certificate contains an Authority Key Identifier (AKI) attribute that includes both a subject and a key identifier, these two fields are compared with those in the issuing certification authority's Subject Key Identifier (SKI).
2. Key Match. If the end entity certificate contains an AKI attribute that only contains the public key identifier of the issuing certification authority, this is compared with the key identifier contained in the subject key identifier (SKI) of the issuing certification authority.
3. Name Match. If the AKI field is either empty or not present at all, the Issuer field of the certificate is compared with the Subject field of the issuing certification authority. The comparison of Subject DN and Issuer DN is not done as a string comparison, but as a binary comparison.

Related links:

• Public Key Infrastructures (PKI) basics
• Installation of a new certification authority certificate fails with error code "ERROR_INVALID_PARAMETER".