Validating Digital Certificates in Windows PKI

Certificate validation is a key part of the process of authenticating users and systems and securing network communications through the use of digital certificates. To validate a digital certificate, a Windows public key infrastructure (PKI)-enabled application must determine whether the certificate and the public key it contains are trustworthy.

Validating a certificate requires the certificate-validation logic in the PKI-enabled application to perform a series of checks on different parts of the certificate. Let's examine those checks and other aspects of the certificate-validation process. By gaining an in-depth understanding of how certificate validation works, you'll be better prepared to recognize and solve certificate-validation problems when they occur.

Certificate-Validation Checks
The validation process performs the following checks on a certificate: digital signature, trust, time, revocation, and formatting. A certificate is invalid if it doesn't pass one or more of these checks. During the digital signature check, the validation software uses a trustworthy public key to validate the digital signature that the certificate issuer (i.e., the Certificate Authority--CA) has applied to the certificate content. The key can be the public key of the issuing CA or of another CA that's part of the certificate's certificate chain--a hierarchical trust model that I explain later.

The availability of a public key isn't enough to validate a signature; the public key must also be trusted. In the Windows Server 2003 and Windows 2000 Server PKI, a trusted CA certificate and public key are known as a trust anchor and are available from the Trusted Root Certification Authorities container in a Windows PKI client's certificate store. The trust check performs the process of authenticating a trusted CA certificate--a procedure also called certificate-chain validation. Certificate-chain validation might trigger different certificate-validation loops for each certificate in the chain. I explain certificate-chain validation in more detail later.

During the time check, the validation process compares the certificate's start and end dates with the current time. One reason a certificate's lifetime is limited is to accommodate advances in computer security, particularly in cryptography. You don't want to rely on certificates based on obsolete technology.

The revocation check determines whether the issuing CA has revoked the certificate. The PKI in Windows 2003 and Win2K Server supports complete certificate revocation lists (CRLs) and CRL Distribution Points (CDPs). In addition, Windows 2003 Certificate Services supports delta CRLs. CRLs, CDPs, and delta CRLs can provide automated certificate-revocation checking. (For more information about certificate revocation, see "Understanding Windows PKI Certificate Revocation," March 2004, InstantDoc ID 41572.)

The validation process's formatting check validates the certificate's format against the standard certificate format as defined in the International Telecommunications Union Telecommunication Standardization Sector (ITU-T) X.509 recommendation. This check also validates certificate extensions, which include basic constraints, name constraints, application policy constraints, and issuance policy constraints. (For more information about these extension types, see "CA Trust Relationships in Windows Server 2003 PKI," June 2004, InstantDoc ID 42444.) Most Secure MIME (S/MIME) applications, for example, evaluate the certificate subject's Internet Engineering Task Force (IETF) Request for Comments (RFC) 822 name (i.e., the standard Internet mail address format--such as [email protected]) of a signed message and compare it with the sender entry in the SMTP message header. In the case of S/MIME, this check protects against impersonation or man-in-the-middle attacks. In such attacks, a malicious entity reuses a user's identity to gain access to a system or network. Most Secure Sockets Layer (SSL) implementations perform a similar validation check. SSL compares the certificate subject's RFC 822 name with the name contained in the URL of the secure Web site that the client is accessing.

Regular Certificate-Chain Processing
What's a certificate chain, and why does it need to be processed during certificate validation? The certificate chain provides a way to verify that all certificates related to the certificate being validated are trustworthy. To understand certificate chains, let's look at the example of a hierarchical PKI trust model. In a hierarchical trust model (which I also discuss in "CA Trust Relationships in Windows Server 2003 PKI"), each end-entity's certificate chain consists of all CA certificates that form the path between the user and the root CA in the PKI hierarchy. In the hierarchical PKI trust model, each certificate contains a pointer to its parent--or issuing--CA, which is stored in the issuer field of an X.509 certificate. Figure 1 shows the certificate chain of a user certificate that a CA has issued and that's part of a two-level PKI hierarchy. Figure 1 represents certificates in a simplified way by using the certificate subject and certificate issuer. In this example, the user's certificate subject is the user, and its issuer is the intermediate CA. The intermediate CA's certificate subject is the intermediate CA, and its issuer is the root CA. In a hierarchy, the root CA always has a self-signed certificate, which means the certificate subject and issuer are identical.

The certificate-validation software processes a certificate's certificate chain. This process can be split into two subprocesses: chain construction and chain validation.

Chain construction. During chain construction, the certificate-validation software walks through the certificate's chain starting with the user certificate until it finds a trusted CA certificate (i.e., the trust anchor). In the example that Figure 2 shows, the validation software finds a trust anchor at the root CA level. Alternatively, the validation software could find a trust anchor at the intermediate CA level. When a trust anchor is found, the chain-construction subprocess stops and the validation logic switches to chain validation. If the certificate-validation software can't find a trust anchor, the certificate-chain process stops, preventing the validation process from making any decisions about the certificate's trustworthiness.

Chain validation. During chain validation, the certificate-validation software walks through the chain in the opposite direction starting with the trust anchor found by the chain-construction process and validates every CA certificate that's part of the chain. For a certificate to be validated, it must be available locally in a container in the user's certificate store. I explain what happens when a certificate isn't available locally later.

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:

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 SettingsusernameLocal SettingsTemporary 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 SettingsSecurity SettingsPublic 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.