Public Key Infrastructures
Applies To: Windows Server 2008
A public key infrastructure (PKI) is a system of digital certificates, certification authorities (CAs), and registration authorities that verify and authenticate the validity of each entity that is involved in an electronic transaction through the use of public key cryptography. Standards for PKIs are still evolving, even as they are being widely implemented as a necessary element of electronic commerce. For more information about planning a PKI and using public key cryptography, see Active Directory Certificate Services Resources.
The Microsoft PKI supports a hierarchical CA model that is scalable and provides consistency with a growing number of commercial and other CA products.
In its simplest form, a certification hierarchy consists of a single CA. However, a hierarchy frequently contains multiple CAs with clearly defined parent/child relationships. In this model, the child subordinate CAs are certified by their parent CA-issued certificates, which bind a CA's public key to its identity. The CA at the top of a hierarchy is referred to as the root CA. The child CA of a root CA is called a subordinate CA. For more information, see Types of Certification Authorities.
In Windows, if you trust a root CA (by having its certificate in your Trusted Root Certification Authorities certificate store), you trust every subordinate CA that has a valid CA certificate in the hierarchy. Thus, a root CA is a very important point of trust in an organization and should be secured accordingly. For more information, see CA Certificates.
There are several practical reasons for setting up multiple subordinate CAs, including:
Usage. Certificates may be issued for a number of purposes, such as secure e-mail and network authentication. The issuing policy for these uses may be distinct, and separation provides a basis for administering these polices.
Organizational divisions. There may be different policies for issuing certificates, depending upon an entity's role in the organization. Again, you can create subordinate CAs to separate and administer these policies.
Geographic divisions. Organizations may have entities at multiple physical sites. Network connectivity between these sites may require individual subordinate CAs for many or all sites.
Load balancing. If your PKI will be used to issue and manage a large number of certificates, having only one CA can result in considerable network load for that single CA. Using multiple subordinate CAs to issue the same kind of certificates divides the network load between CAs.
Backup and fault tolerance. Multiple CAs increase the possibility that your network will always have operational CAs available to respond to user requests.
A CA hierarchy can also provide administrative benefits, including:
Flexible configuration of the CA security environment to tailor the balance between security and usability. For example, you may choose to employ special-purpose cryptographic hardware on a root CA, operate it in a physically secure area, or operate it offline. These may be unacceptable for subordinate CAs, due to cost or usability considerations.
The ability to "turn off" a specific portion of the CA hierarchy without affecting established trust relationships. For example, you can easily shut down and revoke an issuing CA certificate that is associated with a specific business unit without affecting other parts of the organization.