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 jan.declercq@hp.com) 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.