The identification of a CA certificate during chain validation is based on the Authority Key Identifier (AKI) certificate extension of the certificate being verified. A certificate's AKI field can contain different types of information:
- Issuer name and serial number of the issuer's certificate--If the AKI field contains this information, the chain-validation software tries to find a matching certificate by using the certificate's Serial number and Subject fields. This method of identifying a certificate is called an exact match.
- Public Key identifier (KeyID) of the issuer's certificate--If the AKI field contains this information, the chain-validation logic tries to find a matching certificate by using the certificate's Subject Key Identifier (SKI) extension, which contains a unique identifier for a certificate subject's public key. This method of identifying a certificate is called a key match.
If the certificate being verified doesn't contain an AKI field, the chain-validation software tries to identify the issuing CA's certificate by matching the name in the Issuer field of the certificate being verified with the name in a certificate's Subject field. This method of identifying a certificate is called a name match.
When a certificate isn't available locally, the Windows certificate-validation software uses the Authority Information Access (AIA) extension to obtain a copy of the certificate by downloading it from an online location. To do this, the validation software uses a certificate's AIA field, which contains an FTP, HTTP, Lightweight Directory Access Protocol (LDAP), or file system drive pointer to a location in which the CA's certificate is stored. If the AIA field has multiple entries, the validation software tries all entries in the order they're listed in the AIA field. The validation software caches all certificates that it downloads from an AIA location in the PKI user's profile on the local file system (specifically, in the \Documents and Settings\username\Local Settings\Temporary Internet Files folder) and in the user's certificate store.
If the certificate isn't available online or locally, certificate verification fails. When the certificate is available, the certificate-validation logic runs (for every certificate in the chain) all the checks that I discussed earlier: digital signature, trust, time, revocation, and formatting.
You can view a certificate's certificate chain by selecting the Certification Path tab in the certificate's properties dialog box, as Figure 3 shows. To obtain an overview of all your certificates, open the Microsoft Management Console (MMC) Certificates snap-in; to view a certificate's properties, double-click the certificate in the Certificates snap-in.
When you download a certificate by using the CA Web interface in Windows 2003 or Win2K Server, you can choose to download either the certificate itself or the certificate along with all certificates that are part of its certificate chain. In some cases, you might want to download the entire certificate chain--for example, on a laptop or notebook PC--so that all the certificates in the certificate chain are easily available to the validation software when you're on the road.
CTL Certificate-Chain Processing
A special case of certificate-chain processing is Certificate Trust List (CTL) certificate-chain processing. A CTL is a signed list of trusted root CA certificates; that is, it can contain only self-signed root CA certificates. You define CTLs by using the pop-up menu of the Enterprise Trust Group Policy Object (GPO) container, which you can access by navigating to \Windows Settings\Security Settings\Public Key Policies. GPOs also automatically download CTLs to the Enterprise Trust container in an entity's certificate store. The Enterprise Trust container isn't a trust anchor container; by default, its content isn't considered trusted.
For a CTL and its content to be trusted, the CTL signing certificate must be valid. This means that the CTL signing certificate should pass the digital signature, time, formatting, and revocation checks. To ensure that the digital signature check succeeds, the CTL signing certificate's certificate chain should contain a certificate that's part of the Trusted Root Certification Authorities container. You can determine whether a certificate chain is part of a valid CTL by viewing each certificate in the chain on the Certificate properties' Certification Path tab, as I discussed earlier.
Cross-Certification Chain Processing
Cross-certification is a new Windows 2003 PKI trust feature, which I explain in detail in "CA Trust Relationships in Windows Server 2003 PKI." Unlike CTLs, cross-certification allows for granular PKI trust definitions between different CA entities. When you set up cross-certification between two CA entities, each CA becomes both a parent and a subordinate CA, which has interesting effects on the way certificate-chain building works.
Figure 4 shows how a cross-certified trust relationship works--and how it would appear in the certificate's properties. The CA trust relationships that are linked to this setup are on the left side of the figure. In this example, a one-way cross-certification trust exists between OrgB and OrgA. The subordinate CA--SubCA--issues a cross-certificate to HPCA (i.e., OrgA's root CA), which lets users in OrgB trust a certificate named Administrator that HPCA issued. In a nutshell, the users in OrgB trust RootCA, SubCA chains to RootCA and cross-certifies HPCA, and HPCA issues the Administrator certificate.
Certificate validation is a complex topic. The next time you have a problem with an invalid certificate, your knowledge of the basics of Windows certificate validation might help you narrow down possible causes for the problem and make solving it a little easier.