Wikis - Page Details

First published by Kurt L Hudson MSFT
When: 15 Apr 2011 8:31 PM
Last revision by Naomi N (eMicrosoft Partne)
When: 4 Jul 2013 10:55 AM
Revisions: 57
Comments: 41

Options

Can You Improve This Article?

Positively! Click Sign In to add the tip, solution, correction or comment that will help other users.

Report inappropriate content using these instructions.

Public Key Infrastructure Design Guidance

Before you configure a Public Key Infrastructure (PKI) and certification authority (CA) hierarchy, you should be aware of your organizations 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
Links to Detailed Design Guidance
Example Policy Statements
Consider Compatibility
Additional Resources

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