When you look at the certification hierarchy, you are also examining a trust chain that is called the certification path. The certification path goes from the certificate all the way back to the root CA. If you think about it, you will see that it is a logical progression, like that shown in Figure 11.2.
FIGURE 11.2 Trusted certification path
Let's look at the example of the EFS Recovery agent. In the diagram, you see that an EFS Recovery Agent certificate was issued by the issuing CA. Therefore there is a certification path that reaches to the root CA. The EFS
Recovery Agent certificate is trusted simply because the certificate for the root CA is in the Trusted Root Certification Authorities store.
As you have seen, the certification path is designed to link every certificate in the chain all the way back up to the root CA. All the certificates that have a valid certification path back up to any of the root certificates that are in the Trusted Root Certification Authorities store are trusted. This trust extends to all the purposes that are listed in the certificate. What happens if the root CA's certificate that provides for the certification path is not in the Trusted Root Certification Authorities store? In that case, the certification path is not trusted. That relationship remains until the certificate of the root CA has been added to the Trusted Root Certification Authorities store.
Before the Microsoft CryptoAPI will trust a certificate, it has to validate the certification path. The validation goes from the certificate all the way back to the certificate of the root CA. Each step along the way, the Cryp-toAPI checks each certificate in the path. Remember that each certificate contains information about the parent CA that issued the certificate. This way, the CryptoAPI can retrieve the certificate of each parent CA in the path, no matter whether the certificate comes from either the Intermediate Certification Authorities store or the Trusted Root Certification Authorities stores (if the certificates are present in the stores), or even from an online location (such as an HTTP or LDAP address) that is specified in the certificate. If CryptoAPI finds that there is a problem with one of the certificates in the path, or if it cannot actually find a certificate, it does not trust the certification path. Basically, the CryptoAPI just walks back up the certification trail to make sure every authority is still happy with the final outcome.
When CryptoAPI gets one of the subordinate CA certificates that requires certificate path validation, and if the certificate is not located in the Intermediate Certification Authorities store, the API will store the certificate in the Intermediate Certification Authorities store and hold that certificate for future reference. What about the computers that operate offline? In the case of laptop computers that are used by mobile users, you might actually have to import subordinate CA certificates into the Intermediate Certification Authorities store to make sure that non-root CA certificates are available to actually validate certification paths.
Design Scenario: Small Company
You have gone out to a small company that has need of certificate services. There are enough traveling users going and coming that it would be nice to have the added benefit of making sure users are who they say they are. The GM of the company has been to a Windows 2000 class and has heard that in order to use certificate services, you need a minimum of three servers, two of which are not even attached to the network. Now, with the cost of the licenses alone for Windows 2000, that makes things a little prohibitive. The GM is not currently a happy camper.
You explain to the GM that, in large networks, that is the goal. In a small network, however, you can get by with a single server solution. It is not advisable, because you would like at least the root CA to be protected, but it can be done.
Was this article helpful?