Using Third-Party Root CA Configuration

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

Building a new public key hierarchy from an existing third-party root CA is an appropriate solution if you want to cross-certify with multiple business partners simultaneously. The third-party root CA is used to build a new public key hierarchy designed specifically to serve the needs of multiple organizations. Figure 16.12 shows an example of an extended CA infrastructure built from an existing root CA. In this example, organization A and organization B maintain their existing PKIs and share a new PKI that serves the specific needs of their business relationship.

Figure 16.12   Extended CA Infrastructure Built from an Existing Third-Party Root CA

The advantage to this approach is that you can off-load responsibility for maintaining the new infrastructure to an organization that specializes in this type of service. The intermediate and issuing CAs that you create on your side of the shared infrastructure can be administered separately from your existing internal PKI. In this way, the functions of the external PKI cannot compromise the internal PKI, and the organizations that share the extended infrastructure do not have to share transitive trust between their existing PKIs.

The disadvantage to this approach is that it involves the creation of a new, separate infrastructure with its own administrative requirements. Although much of this administration is off-loaded to a third party, this approach involves considerable additional cost. The costs can multiply each time you add a new business relationship that requires a separate shared PKI infrastructure.

You need to plan for an extended PKI based on an existing root CA in the same way that you plan for your existing internal PKI, in that you must decide where to locate intermediate and issuing CAs, how to manage them, how to protect them, and so on. In this case, you must work with your business partner and the root CA provider to make these decisions.

Third-party CAs can form all or part of a CA trust hierarchy. To ensure that third-party CAs provide interoperability with your existing infrastructure, test all proposed interoperability scenarios in your lab.

Note

• Some PKIs require CA trust models that are not interoperable with rooted CA hierarchies. Windows 2000 and most commercial CAs support rooted CA hierarchies.

Adding Trusted Root Certificates to Group Policy

If a stand-alone CA is not a domain member buts runs as a member of a workgroup, the root CA certificate must be added manually to the domain Group Policy. In contrast, when you install a stand-alone root CA on a computer that is a domain member, the certificate of the CA is added to the Trusted Root Certification Authorities Group Policy for the domain.

You can also add certificates for other root CAs to Trusted Root Certification Authorities Group Policy manually. These root CAs then become trusted root CAs for the computers within the scope of the Group Policy. For example, if you want to use a third-party CA as a root CA in a certification hierarchy, you must add the certificate for the third-party CA to the Trusted Root Certification Authorities Group Policy.