Planning and Designing a Public Key Infrastructure : Designing the CA Hierarchy

Planning the CA Infrastructure

Before you can implement a PKI that meets the security needs and certificate requirements for your organization, you need to make a number of decisions about how you will deploy CAs. Planning the CA infrastructure for your organization involves making decisions about the following:

• Location of the root CAs

• Internal versus third-party CAs

• CA types and roles

• Number of CAs required

Designing Root CAs

A CA infrastructure consists of a hierarchy of CAs that trust one another and that authenticate certificates belonging to one another. Within this infrastructure, a final authority, called a root CA, must be in place. The root CA certifies other CAs to publish and manage certificates within the organization.

Selecting Internal CAs vs. Third-Party CAs

Depending on the functionality that you require, the capabilities of your IT infrastructure and IT administrators, and the costs that your organization can support, you might choose to base your CA infrastructure on internal CAs, third-party CAs, or a combination of internal and third-party CAs.

Internal CAs

If your organization conducts most of its business with partner organizations and wants to maintain control of how certificates are issued, internal CAs are the best choice. Internal CAs:

• Allow an organization to maintain direct control over its security policies.

• Allow an organization to align its certificate policy with its overall security policy.

• Can be integrated with the Active Directory Domain Services infrastructure of the organization.

• Can be expanded to include additional functionality and users at relatively little extra cost.

The disadvantages of using internal CAs include the following:

• The organization must manage its own certificates.

• The deployment schedule for internal CAs might be longer than that for CAs available from third-party service providers.

• The organization must accept liability for problems with the PKI.

External CAs

If your organization conducts most of its business with external customers and clients and wants to outsource certificate issuing and management processes, you might choose to use third-party CAs. Third-party CAs:

• Allow customers a greater degree of confidence when conducting secure transactions with the organization.

• Allow the organization to take advantage of the expertise of a professional service provider.

• Allow the organization to use certificate-based security technology while developing an internally managed PKI.

• Allow the organization to take advantage of the provider’s understanding of the technical, legal, and business issues associated with certificate use.

The disadvantages associated with the use of third-party CAs include the following:

• They typically involve a high per-certificate cost.

• They might require the development of two management standards—one for internally issued certificates and one for commercially issued certificates.

• They allow less flexibility in configuring and managing certificates.

• The organization must have access to the third-party CAs in order to access the CRLs.

• Autoenrollment is not possible.

• Third-party CAs allow only limited integration with the internal directories, applications, and infrastructure of the organization.

Defining CA Types and Roles

To plan your CA infrastructure, you need to understand the different types of CAs available with Windows Server 2008 and the roles that they can play. Windows Server 2008 Certificate Services supports the following two types of CAs:

• Enterprise

• Standalone

Enterprise and standalone CAs can be configured as either root CAs or subordinate CAs. Subordinate CAs can further be configured as either intermediate CAs (also referred to as policy CAs) or issuing CAs.

Before you create your CA infrastructure, you need to determine the type or types of CAs that you plan to use and define the specialized roles that you plan to have each CA assume.

Enterprise vs. Standalone CAs

Enterprise CAs are integrated with Active Directory. They publish certificates and CRLs to Active Directory. Enterprise CAs use information stored in Active Directory, including user accounts and security groups, to approve or deny certificate requests. Enterprise CAs use certificate templates. When a certificate is issued, the enterprise CA uses information in the certificate template to generate a certificate with the appropriate attributes for that certificate type.

If you want to enable automated certificate approval and automatic user certificate enrollment, use enterprise CAs to issue certificates. These features are available only when the CA infrastructure is integrated with Active Directory. Additionally, only enterprise CAs can issue certificates that enable smart card logon because this process requires that smart card certificates be mapped automatically to the user accounts in Active Directory.

Standalone CAs do not require Active Directory and do not use certificate templates. If you use standalone CAs, all information about the requested certificate type must be included in the certificate request. By default, all certificate requests submitted to standalone CAs are held in a pending queue until a CA administrator approves them. You can configure standalone CAs to issue certificates automatically upon request, but this is less secure and is usually not recommended because the requests are not authenticated.

From a performance perspective, using standalone CAs with automatic issuance enables you to issue certificates faster than you can by using enterprise CAs. However, using standalone CAs to issue large volumes of certificates usually comes at a high administrative cost because an administrator must manually review and then approve or deny each certificate request. For this reason, standalone CAs are best used with public key security applications on extranets and the Internet, when users do not have Windows accounts and when the volume of certificates to be issued and managed is relatively low.

In addition, you must use standalone CAs to issue certificates when you are using a third-party directory service or when Active Directory is not available.

Table 1 lists the options that each type of CA supports.

In general, you should deploy a standalone CA if:

• The CA is an offline root or offline intermediate CA.

• Support of templates that you can customize is not required.

• A strong security and approval model is required.

• Fewer certificates are enrolled and the manual work that you must do to issue certificates is acceptable.

• Clients are heterogeneous and cannot benefit from Active Directory.

• It is combined with a third-party RA solution in a multi-forest or heterogeneous environment.

• It issues certificates to routers through NDES SCEP.

You should deploy an enterprise CA if:

• A large number of certificates should be enrolled and approved automatically.

• Availability and redundancy is mandatory.

• Clients need the benefits of Active Directory integration.

• Features such as autoenrollment or modifiable templates are required.

• Key archival and recovery is required to escrow encryption keys.

Root CAs

A root CA is the CA that is at the top of a certification hierarchy, and clients in your organization must trust it unconditionally. All certificate chains terminate at a root CA. Whether you use enterprise or standalone CAs, you need to designate a root CA.

Because there is no higher certifying authority in the certification hierarchy, the subject of the certificate issued by a root CA is also the issuer of the certificate. Likewise, because the certificate chain terminates when it reaches a self-signed CA, all self-signed CAs are root CAs. The decision to designate a CA as a trusted root CA can be made at either the enterprise level or locally by the individual IT administrator.

A root CA serves as the foundation on which you base your CA trust model. It guarantees that the subject public key belongs to the subject identity information that is contained in the certificates it issues. Different CAs might also verify this relationship by using different standards; therefore, it is important to understand the policies and procedures of the root CA before choosing to trust that authority to verify public keys.

The root CA is the most important CA in your hierarchy. If your root CA is compromised, every other CA and certificate in your hierarchy might be compromised. You can maximize the security of the root CA by keeping it disconnected from the network and using subordinate CAs to issue certificates to other subordinate CAs or to end users.

Subordinate CAs

CAs that are not root CAs are considered subordinate. The first subordinate CA in a hierarchy obtains its CA certificate from the root CA. This first subordinate CA can, in turn, use this key to issue certificates that verify the integrity of another subordinate CA. These higher subordinate CAs are referred to as intermediate CAs. An intermediate CA is subordinate to a root CA, but it also serves as a higher certifying authority to one or more subordinate CAs.

An intermediate CA is often referred to as a policy CA because it is typically used to separate classes of certificates that can be distinguished by policy. For example, policy separation includes the level of assurance that a CA provides or the CA’s geographical location to distinguish different types of users. A policy CA can be online or offline.

The next level in the CA hierarchy usually contains the issuing CA. The issuing CA issues certificates to users and computers and is almost always online. In many CA hierarchies, the lowest level of subordinate CAs is replaced by RAs, which can act as an intermediary for a CA by authenticating the identity of a user who is applying for a certificate, initiating revocation requests, and assisting in key recovery. Unlike a CA, however, an RA does not issue certificates or CRLs; it merely processes transactions on behalf of the CA.

The hierarchy consisting of a root CA, policy CAs, and issuing CAs is illustrated in Figure 1.

Figure 1. CA hierarchy roles

Using Offline CAs

Securing your CA hierarchy is critical. If an intruder can gain access to a CA, either physically or by means of the network, he or she might retrieve the CA’s private key and then impersonate the CA to gain access to valuable network resources. The compromise of even one CA key invalidates the security protection that it and any CAs below it in the hierarchy provide. For this reason, it is important to avoid connecting root CAs to the network.

To ensure the reliability of your CA infrastructure, you should specify that any nonissuing root and intermediate CAs must be offline. This minimizes the risk of the CA private keys becoming compromised. You can take a CA offline in any of the following ways:

• By installing a CA on a standalone computer running Windows 2000, Windows Server 2003, or Windows Server 2008 and configuring it as a standalone CA

• By physically removing the computer from the network

• By shutting down the CA service

• By shutting down the computer

Make sure that you keep CAs in a secure area with limited access.

When a CA is supposed to be an offline CA, you can still publish its certificate and CRL in Active Directory. You must be sure to bring an offline CA online at regular intervals, based on your CRL publication schedule, to generate a new CRL for the CA. You must also bring the CA online to process certificate requests for subordinate CA certificates.

Because offline CAs process a small number of certificate requests at infrequent intervals, the administrative costs of maintaining offline CAs are low.

Determining the Number of CAs Required

After you have identified your application and user requirements, you can begin to estimate the number of CAs that you need to deploy. If your organization has limited certificate requirements, a small user base, and limited expansion goals, a single CA might be sufficient. By using a single CA, you can still meet a variety of needs by customizing and deploying certificate templates and using role separation. However, if availability or distributed functionality of Certificate Services is a priority, you must deploy multiple CAs. You also need multiple CAs if you want separate CAs to issue certificates for different purposes.

To determine the number of CAs required, answer the following questions in order:

The number of intermediate and issuing CAs that you deploy depends on the following factors:

• Usage Certificates can be issued for a number of purposes (for example, secure e-mail, network authentication, and so on). Each of these uses might involve different issuing policies. Using separate CAs provides a basis for administering each policy separately.

• Organizational or geographic divisions You must have different policies for issuing certificates, depending on the role of an entity or its physical location in the organization. You can create separate subordinate CAs to administer these policies.

• Distribution of the certificate load You can deploy multiple issuing CAs to distribute the certificate load to meet site, network, and server requirements. For example, if network links between sites are slow or discontinuous, you might need to place issuing CAs at each site to meet Certificate Services performance and usability requirements.

• The need for flexible configuration You can tailor the CA environment (key strength, physical protection, protection against network attacks, and so on) to provide a balance between security and usability. For example, you can renew keys and certificates more frequently for the intermediate and issuing CAs that are at high risk for compromise without requiring a change to established root trust relationships. Also, when you use more than one subordinate CA, you can turn off a subsection of the CA hierarchy without affecting established root trust relationships or the rest of the hierarchy.

• The need for redundant services If one enterprise CA fails, redundancy makes it possible for another issuing CA to provide users with uninterrupted service.

Strive to have only as many CAs and RAs as you need to function efficiently. Deploying more CAs than you need creates an unnecessary management burden and introduces additional areas of security vulnerability.