Windows Server 2003 Security Infrastructures: Core Security Features (HP Technologies)
Certificate validation is the process by which a PKI-enabled application finds out whether a certificate and the public key contained in it are trustworthy. During certificate validation, the following checks are performed: digital signature, trust, time, revocation, and formatting. The checks are illustrated in Figure 15.26 and explained next.
During the digital signature check, the certificate validation logic validates the digital signature that has been applied to the certificate content by the issuer of the certificate. To be able to do so, a trustworthy public key is needed. This can be the public key of the issuing CA or the public key of another CA that is part of the certificate’s certificate chain. The availability of a public key is not enough to validate a signature: The public key must also be trusted. In Windows PKI, a trusted CA certificate and public key are known as a trust anchor—they are available from two specific containers in an entity’s certificate store (these containers were explained in Chapter14). The process of discovering a trusted CA certificate is done during the trust check, which is also referred to as certificate chain validation. Certificate chain validation may trigger different certificate validation loops: one for each certificate in the certificate chain. Certificate chain validation is explained in more detail later on in this chapter.
During the time check, the start-end date of the certificate are compared to the current time. One of the reasons why a certificate’s lifetime is limited is to cope with the advances in computer technology. For example, every year it becomes easier to break a 512-bit key-rooted asymmetric cipher.
During the revocation check, the validation logic checks whether the certificate has been revoked. Windows 2000 and Windows Server 2003 PKI support complete certificate revocation lists (CRLs) and CRL distribution points (CDPs). Windows Server 2003 PKI also supports delta CRLs. CRLs, Delta CRLs, and CDPs can provide automated certificate revocation checking. We discuss revocation in more detail in the section on certificate revocation.
During the formatting check, the format of the certificate is checked and validated. This is done according to the standard certificate format defined in the ITU-T X.509 standard. This check also includes the validation of the certificate’s extensions (see also the following sidebar). Among a certificate’s extensions are the basic constraints, application policy, issuance policy, and name constraints extensions that were discussed in Chapter 14. A certificate also contains a set of critical extensions that—following the X.509 standard—must be validated by every application. The validation or evaluation of the other noncritical extensions depends on the PKI application using the certificate. Most S/MIME applications, for example, will evaluate the certificate subject’s RFC822 name (e.g., jan.declercq@hp.com). It will be compared to the sender entry in the header of the SMTP message. 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. A similar check is done by most SSL implementations. SSL compares the subject’s RFC822 name to the name that is contained in the URL.
Displaying a Certificate’s X.509 Extensions To view the different X.509 certificate extensions, you must use the Details tab in the certificate properties (illustrated in Figure 15.27). At the top of this tab there is a drop-down box called Show that allows you to filter the X.509 field and extension data that are displayed in the bottom part of the tab. To display only the critical extensions, select Critical Extensions Only. The filter allows you to differentiate between version 1 fields only, all extensions, critical extensions only, and properties only. For most of these field types, the certificate viewer uses another icon as shown here:
| |
|
| |
|
| |
|
| |
|
15.5.1 Regular certificate chain processing
So what is a certificate chain and why do we need to process it during certificate validation? Let’s try to explain this concept using the example of a hierarchical trust model.
Chain construction
During chain construction, the certificate validation software runs through the certificate’s chain until it finds a trusted CA certificate, also known as a trust anchor. In Chapter 14 we explained which CA certificates are considered trust anchors in Windows PKI. In the examples of Figure 15.29, the validation software finds a trust anchor at the root CA level (example 1) and at the intermediate CA level (example 2). When a trust anchor is found, the chain construction subprocess stops and the validation logic will switch to chain validation. In Figure 15.30 (example 3), the validation logic cannot find a trust anchor. In this case, the certificate chain process stops and no decisions can be made regarding the trustworthiness of the certificate.
Chain validation
During chain validation, the certificate validation software walks the chain in the opposite direction (top-down) and validates every CA certificate that is part of the chain. In order to validate a certificate, it must be available locally in one of the containers of a user’s certificate store (see Chapter 13). When a certificate is not available locally, the Windows PKI software will use the Authority Information Access (AIA) method that is explained next to obtain a copy of the certificate.
The identification of a CA certificate during chain validation is based on the Authority Key Identifier (AKI) field in the certificate under verification. A certificate’s AKI field can contain different types of information:
-
It may contain the issuer name and serial number of the issuer’s certificate. In that case the chain validation logic will try to find a matching certificate using a certificate’s Serial number and Subject fields. This way of identifying a certificate is called an exact match.
-
It may contain the public Key identifier (KeyID) of the issuer’s certificate. In that case the chain validation logic will try to find a matching certificate using a certificate’s Subject Key Identifier (SKI) extension. This way of identifying a certificate is called a key match.
If the certificate under verification does not contain an AKI field, the chain validation logic will try to identify the issuing CA’s certificate by matching the name in the Issuer field of the certificate under verification with the name in the Subject field. This way of identifying a certificate is called a name match.
The AIA method that the validation logic uses to obtain a local copy of the certificate simply means that it will try to download the certificate from an online location. To do this it will use a certificate’s Authority Info Access (AIA) field,[7] which contains an LDAP, HTTP, or File System pointer to a location where the CA’s certificate is stored. If the AIA field has multiple entries, all entries will be tried out in the order that they are listed in the AIA field. All certificates that are downloaded from an AIA location will be cached in the certificate store and on the file system for future use. On the file system they are cached in the \Documents and Settings\<username>\ Local Settings\Temporary Internet Files folder. Note the use of the <user- name> variable in the previous file system path: the cache location is dependent on the user security context under which the calling application is running.
If the certificate is not available, certificate verification will fail. If the certificate is available, the certificate validation logic will run (for every certificate in the chain) through all of the steps that were explained earlier: time, digital signature, formatting, and revocation checking.
A certificate’s certificate chain can be viewed from the certificate’s properties: in the Certification Path tab. Figure 15.31 shows the certificate chain of a certificate that ends in a trusted CA certificate (Figure 15.31(a)) and another that ends in an untrusted CA certificate (Figure 15.31(b)) as they are displayed in the Windows certificate properties.
When a user downloads a certificate using the Windows 2000 or Windows Server 2003 CA Web interface, he or she has the choice to download just the certificate or the certificate together with all of the certificates that are part of its certificate chain. This can be an interesting option for certificate validation on, for example, portable computers. All CA certificates in the certificate chain are made available on the client at once, and there is no need for the client software to download the certificates in the chain using the AIA pointers.
This section illustrates that certificates can be invalid for different reasons: expiration or other time problems, invalid signatures, unavailability of a trusted CA certificate, improper use, improper formatting, revocation, and so forth. That is why finding out the exact reason why a certificate is not valid is sometimes a tough job.
15.5.2 CTL certificate chain processing
A special case of certificate chain processing is Certificate Trust List (CTL) certificate chain processing. CTLs are signed lists of trusted root CA certificates: They can only contain self-signed root CA certificates. CTLs can be defined using Windows 2000 or Windows Server 2003 GPOs and are downloaded to the Enterprise Trust container in an entity’s certificate store. The Enterprise Trust container is not a trust anchor container because its content is not considered trusted by default.
In order 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 time, digital signature, formatting, and revocation check. In order for the digital signature check to succeed, the CTL signing certificate’s certificate chain should contain a certificate that is part of the Trusted Root Certification Authorities container.
Figure 15.32 shows the certificate chain of a certificate that is part of a valid CTL and one that is part of an invalid CTL as they are displayed in the Windows certificate properties.
15.5.3 Cross-certification chain processing
Cross-certification is a new Windows Server 2003 PKI trust feature. It was explained in detail in Chapter 14. Unlike CTLs, it allows for very granular PKI trust definitions between different CA entities. When setting up cross- certification between two CA entities, each CA becomes both a parent and a subordinate CA. This has interesting effects on the way certificate chain building works in a cross-certification setup.
The way that a cross-certified trust relationship shows up in the Certification Path tab of the certificate properties is illustrated in Figure 15.33. The CA trust relationships that are linked to this setup are shown on the left side of Figure 15.33. In this example, a one-way cross-certification trust is set up between OrgB and OrgA. The SubCA issues a cross-certificate to the HPCA. This will allow users in OrgB to trust a certificate named Administrator that was issued by HPCA. The users in OrgB trust the RootCA; SubCA chains to the RootCA; HPCA is cross-certified by the SubCA and the Administrator certificate was issued by HPCA.
As mentioned earlier in this chapter, cross-certificates are downloaded (just like trusted root CA certificates) to Windows PKI clients that are members of a domain at every autoenrollment event. Earlier we explained when this event occurs and how it can be manually enforced. Downloaded cross-certificates are stored in a PKI user’s Intermediate Certification Authorities certificate store container.
For cross-certificates that are stored on locations other than the default AD locations, Windows XP and Windows Server 2003 allow you to define additional cross-certificate download locations for each certificate that is stored in your certificate store. To do this, right-click a certificate to bring up its properties dialog box—then select the cross-certificates tab (as illustrated in Figure 15.34). This tab allows you to specify the cross-certificates download interval as well as the download URLs.
[7]The content of the AIA field of the certificates a CA issues can be configured from the CA object’s properties in the CA MMC snap-in. The CA certificate’s proper AIA field can be configured using a capolicy.inf configuration file (as was mentioned in Chapter 14).
Категории