Securing PKI: Planning a CA Hierarchy

  • Article

 

Applies To: Windows Server 2003 with SP2, Windows Server 2008 R2, Windows Server 2012 R2, Windows Server 2012

Certificate hierarchy planning is one of the most important aspects of PKI design because the design will affect how certificates are validated and used by PKI-enabled solutions. This section introduces a number of recommendations for designing a certificate hierarchy that can be used to meet today’s pressing business needs as well as future needs that may not yet be identified.

A PKI can be implemented either as part of the IT infrastructure or by using external, commercial CAs. In general, the following are the PKI design options:

  • Implement a completely self-managed PKI within your organization that contains internal CAs chained to an internal root CA at the top of the chain

  • Purchase a CA certificate from a commercial CA and issue certificates within the organization from internal, self-managed CAs that are chained to the external root CA

  • Purchase certificates from a commercial CA that are chained to a public root CA (preferably a member of the Microsoft Root Certificate Program that are automatically distributed to clients that use Microsoft Windows® platforms)

If the security solutions supported by the PKI do not require external parties to trust the issued certificates, and will not in the future, then you may opt for a self-managed PKI that uses an internal root CA as the trust anchor for the PKI. Using an internal root CA allows you to maintain direct control over its security policies and to align its Certificate Policy (CP) with the overall security policy. Therefore, you will use internal CAs for issuing certificates to end users, to computers, and to services. These internal CAs can be expanded to include additional functionality, such as support for new certificate types, at a lower cost than buying external certificates.

CA Hierarchy Options

In a hierarchical PKI (a typical deployment), there are generally three types of hierarchies – one tier, two-tier, and three-tier.

Single/One-Tier Hierarchy

  • One-Tier Hierarchy – Consists of one single CA. The single CA is both a root CA and an issuing CA. A root CA is the trust anchor of the PKI, so a root CA public key serves as the beginning of trust paths for a security domain. Any applications, users, or computers that trust the root CA also trust any certificates issued by the CA hierarchy. The issuing CA is a CA that issues certificates to end entities.

    This one-tier hierarchy is not recommended for any production scenario because with this hierarchy, a compromise of this single CA equates to a compromise of the entire PKI. For security reasons, root and issuing CAs are normally separated because it is generally very difficult to quickly distribute a new root CA certificate to replace a compromised CA. This is especially true when the environment includes computers not joined to management domain or devices where a special process is required to provision the root CA certificate. Because of this, a one-tier hierarchy may be sufficient for only simple implementations where ease of manageability and lower cost outweigh the need for greater levels of security or flexibility.

    A common finding in PKI assessments is that some organizations install a single CA in order to support a major project that may have required it. Perhaps this is an installation of System Center Configuration Manager, or wireless network protection, or some other PKI-consuming technology and one small line-item in the project’s plan is dedicated to the CA installation. Over time, this single CA begins to get a lot of use as it is leveraged more and more for purposes other than those originally conceived. Suddenly, there is a need for a proper PKI and administrators face some uneasy questions:

    • Can I install multiple PKIs in my forest without them interfering with each other?

    • How do I set up my new PKI properly so that it is scalable and manageable?

    • How do I get rid of my old CA without causing an interruption in my business?

    • Is the configuration of this CA posing a security risk to the enterprise?

    So there are multiple security risks in using a one-tier hierarchy – your only CA is online and more susceptible to compromise, and you cannot revoke this CA if it was compromised. This hierarchy is also more difficult to expand to support other scenarios. If you are in the position to move to the recommended CA hierarchy design, refer to the Moving Your Organization from a Single Microsoft CA to a Microsoft Recommended PKI article.

Three-Tier Hierarchy

  • Three-Tier Hierarchy – In a three-tier hierarchy, there is a root CA tier (offline), an issuing CAs tier (usually online), and an intermediate tier placed between them. The placement of this intermediate CA can be for several different reasons. The first reason would be to use the second tier CA as a policy CA. For example, one policy CA will issue certificates that requires that a user has to appear in person and another CA will issue certificates to any authenticated corporate users. In other words, the policy CA is configured to issue certificates to the Issuing CA that is restricted in the type of certificates it issues. The policy CA can also just be used as an administrative boundary. That is, you only issue certain certificates from subordinates of the policy CA, and perform a certain level of verification before issuing certificates, but the policy is only enforced from an administrative and not technical perspective.

    Another reason to have the second tier added is that if you need to revoke a number of CAs due to a key compromise, you can perform it at the second tier level, leaving other branches available. It should be noted that second tier CAs in this hierarchy should, like the root, be kept offline.

    Following the paradigm, security increases with the addition of a tier, and flexibility and scalability increase due to the increased design options. On the other hand, manageability increases as there are a larger number of CAs in the hierarchy to manage and cost goes up.

    Note that performance of certificate chain building on PKI solution clients is affected with an increase in the number of tiers because three-tier hierarchy clients need to verify certificate and certificate status information for both issuing CAs and policy CAs. Another consideration is policy or administrative boundary requirements because a three-tier hierarchy will increase operational costs. Also note that if you are not going to implement policy or administrative boundaries, then the middle tier will be unused and is unneeded. Because of this, three-tier CA hierarchies are usually not recommended (with the exception of a few unique cases). In fact, Microsoft IT changed its design to a two-tier CA hierarchy for its internal PKI. Refer to Deploying and Managing PKI inside Microsoft for more information.

Two-Tier Hierarchy

  • Two-Tier Hierarchy – A two-tier hierarchy is a design that meets most company’s needs. In some ways it is a compromise between the one and three-tier hierarchies. In this design there is a root CA that is offline and a subordinate issuing CA that is online. The level of security is increased because the root CA and issuing CA roles are separated. But more importantly the root CA is offline so the private key of the root CA is better protected from compromise. The two-tier hierarchy also increases scalability and flexibility due to the fact that there can be multiple issuing CAs subordinate to the root CA. This allows CAs to exist in different geographical locations, as well as with different security levels. Manageability is increased since the root CA has to be brought online to sign CRLs. Capital cost is increased marginally because all you need is an additional server or a virtual machine. The two-tier hierarchy is the recommended design for most PKI solutions.

    Another advisable idea is to restrict certificates of the subordinate issuing CAs to limit their impact on the CA hierarchy, so that subordinate CAs cannot issue “rogue” certificates that could be used for unintended purposes. This is important when you have more complex certificate hierarchies. The most obvious case occurs when an issuing CA is operated by different parts of an organization, but even for internal issuing CAs, it may make sense to restrict the scope of issued certificates. You want to limit certificates issued for a specific scenario (for example, server authentication) so one CA does not affect others (for example, issuing certificates for smartcards) in case of security breach. The best way to accomplish this task is to implement path length constraint and limit Extended Key Usages (EKUs) for the issuing CA’s certificate as described in the Securing PKI: Planning Certificate Algorithms and Usages section. Please note that there are many shared elements of multiple enterprise subordinate CAs in Active Directory® environment (for example, certificate templates), so this restriction should not be the only mitigation.

Conclusion

For a complete list of the recommendations for planning a CA hierarchy, along with the level of business impact at which you should consider implementing them, refer to Securing PKI: Appendix F: List of Recommendations by Impact Level.

See Also

Securing Public Key Infrastructure (PKI) Securing PKI: Introduction Securing PKI: Physical Controls for Securing PKI Securing PKI: PKI Process Security Securing PKI: Technical Controls for Securing PKI Securing PKI: Planning Certificate Algorithms and Usages Securing PKI: Protecting CA Keys and Critical Artifacts Securing PKI: Monitoring Public Key Infrastructure Securing PKI: Compromise Response Securing PKI: Appendix A: Events to Monitor Securing PKI: Appendix B: Certification Authority Audit Filter Securing PKI: Appendix C: Delegating Active Directory PKI Permissions Securing PKI: Appendix D: Glossary of Terms Securing PKI: Appendix E: PKI Basics Securing PKI: Appendix F: List of Recommendations by Impact Level Security and Protection Secure Windows Server 2012 R2 and Windows Server 2012