Share via


Public Key Infrastructure Design Guidance

Before you configure a Public Key Infrastructure (PKI) and certification authority (CA) hierarchy, you should be aware of your organization's security policy and certificate practice statement (CPS). If your organization does not have such policy statements, you should consider creating them. For more information on policy statements, see Example Policy Statements in this article.


PKI Design Options

When planning your CA hierarchy for your organization's PKI, you can use the following table to get an idea of the type of hierarchy and CAs to implement.

 

Design Option

Best for

Pros

Cons

Enterprise root CA on a domain controller online

> Lab environments only when PKI design is not a priority.

> Resources severely constrained (worst case scenario).

+ Fewer Windows Server operating system (OS) licenses and configurations

- Configuration dependencies make domain controller maintenance and restore complex.

- Root CA is online and more susceptible to compromise

Enterprise root CA online

> Small organizations with limited security needs.

> Environments that don’t have high security needs and do not want to manage an offline system.

> Large companies with limited certificate needs, such as internal SSL online only.  

+ Easy to manage, uses templates, integrates with Active Directory Domain Services (ADDS)

- Root CA is online and more susceptible to compromise.

- Cannot revoke online CA if compromised

- More difficult than multi-tier CA hierarchies to expand

Enterprise root CA offline

Not recommended.

+ When offline the CA is not exposed to network-based attacks

- Administrative difficulty and uncommon configuration, which may not function properly or reliably with no known benefit over using an offline Standalone Root CA

- Unlikely that an Enterprise root CA could be installed offline, unless Windows Server 2008 R2 is used with offline domain join. Such a use of offline domain join has not been tested and is not supported

Standalone offline root CA

Secure environment, multiple Issuing CAs.

+ Provides security and management of online CAs. Allows environments to have a single point to trust all CAs in the company

+ Helps control physical and logical control to CA

- Easy to forget about and allow CDP/AIA to expire and break PKI

- Expensive – requires dedicated hardware or virtual computer that is infrequently used

- More complex and requires greater skill level to integrate in an Active Directory Domain Services (AD DS) environment

Two-tier CA hierarchy

Most environments that do not have a need to create security boundaries in their CA architectures.

+ No unnecessary offline systems

+ Less CAs to manage and renew offline than three or more tier configurations

- No ability to restrict subordinate CAs or administrators

- Should include a Hardware Security Module (HSM), which comes at additional cost

Three-tier CA hierarchy

Very large and expansive PKI environments with segmented CAs or separate groups that will manage CAs and need to be restricted.

+ Ability to restrict CAs from issuing certs that should not. For example, a perimeter network (also called DMZ) CA should not issue Smart cards

+ Allows greatest flexibility of PKI

- Middle tier often never utilized and is wasted. Extra computer or virtual machine, OS, and HSM expense.

- Another computer to maintain in an offline state

Return to Top


 

Return to Top


Example Policy Statements

Return to Top


Consider Compatibility

 

Return to Top


Additional Resources

 

Return to Top