Export (0) Print
Expand All

Establishing a certification hierarchy

Updated: January 21, 2005

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Establishing a certification hierarchy

The first step to establish a certification hierarchy is that a Domain Admin installs a root certification authority (CA).

Using a Microsoft certification authority as your root authority

The installation process for a Certificate Services root authority generates a root CA certificate containing the CA's public key and the digital signature created using the root's private key. If the root authority is installed using Certificate Services on a server that has access to the Active Directory directory service, the root authority's certificate will automatically be placed in all users' Trusted Root Certification Authorities certificate store, thereby establishing forest-wide trust in the root CA.

Using a certification authority outside of your organization as your root authority

If your organization is using a non-Microsoft certification authority from outside your organization as the root authority, you will need to obtain the root certificate and distribute it to any user and computer that needs to establish trust in the root authority. One way to distribute this type of root certificate to Windows XP and Windows Server 2003 family users is to use a certificate trust list (CTL) by way of Group Policy. For more information about distributing third party root certificates using Group Policy, see Enterprise trust policy.

Using a non-Microsoft certification authority inside your organization as your root authority

If your organization is using its own non-Microsoft certification authority (CA) as the root authority, you will need to obtain the root certificate and distribute it to any user and computer that needs to establish trust in the CA root authority. One way to distribute a root certificate to Windows XP and Windows Server 2003 family users is to use the Trusted Root Certification Authorities policy setting via Group Policy. For more information about distributing non-Microsoft root certificates using Group Policy, see Policies to establish trust of root certification authorities.

Subordinate certification authorities

After trust in a root authority has been established, you can install certification authorities (CAs) that are subordinate to the root CA as well as installing subordinate CAs that are subordinate to other subordinate CAs. By doing this, you can create a chain of parent-child relationships between CAs that serve different functions in an organization's public key infrastructure (PKI). The only significant difference in the installation process between a root CA and a subordinate CA is that a certificate request is generated for submission to another CA by a subordinate CA instead of creating a self-signed certificate. This request may be routed automatically to online CAs located via Active Directory, or routed manually, if offline. In either case, the resulting certificate must be installed on the new subordinate CA before it can begin operation.

Note that there is a relationship between the enterprise CAs and the Windows Server 2003 family domain trust model, but this does not imply a direct mapping between CA trust relationships and domain trust relationships. There is nothing that prevents a single CA from servicing entities in multiple domains or even entities outside the domain boundary. Similarly, a given domain may have multiple enterprise and root CAs.

For a brief overview of certification hierarchies, see Certification authority hierarchies.

For extensive information about planning certification hierarchies, refer to the Microsoft Windows Deployment and Resource Kits.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft