9.6 Planning Your Private Certification Hierarchy

In deciding to deploy a private certification hierarchy, you have taken on the task of correctly planning your own architecture and deployment. This is an opportunity for you to revisit your need for a PKI and structure it to meet those needs. Once deployed, it is extremely difficult and expensive to make large changes, so getting it correct from the beginning is quite important.

Numerous considerations will impact the planning of the hierarchy. These should be primarily based on the established business need. The PKI deployment will be supporting and enabling other technologies. The hierarchy should be based on those other technologies and their use of certificates. For example, if your email program does not support certificate chains of a specific length, you may want to plan your deployment to ensure this level of depth is not reached.

The hierarchy is also sometimes based on organizational or political divisions within a company. Many departments have their own IT group that makes decisions for that department and does not coordinate with other groups. Often, managers refuse to allow staff from another department to make security-based decisions that may affect their assets, such as the decision to issue a key recovery agent certificate. These types of situations should be avoided if possible as they unnecessarily complicate the hierarchy and often break technologies that would otherwise work correctly.

9.6.1 Hierarchy Depth

The primary decision in designing a PKI is the number of levels, or depth, of the certification authority hierarchy. The number of tiers in the certification hierarchy is normally two or three. This figure is a direct result of the most commonly planned configurations and their similarities and is a fairly consistent "sweet spot" for well-planned certification hierarchies. There are several reasons to avoid having only one CA in your hierarchy, including:

Lack of redundancy

If your only CA is brought down for maintenance or upgrade, the entire PKI is offline. This is obviously a bad situation in an environment that requires certificates for critical business functions.

Exposure to attack

If you have only one CA, then the issuing CA is also the root CA. Attackers can easily identify the CA and begin to attack it. Once an attacker is able to successfully attack the root CA's private key, he has complete control over the entire PKI. Complete removal and redeployment are required to recover from this type of security breach. Removing the root CA from scrutiny by attackers is an important and highly effective way to provide additional security.

Inability to revoke portions of the issued certificate space

If the single CA is compromised, the entire PKI must be revoked. In a multitier multi-issuer PKI, the problem is more partitioned. If the private key of an issuing CA is compromised, that CA's certificate can be revoked and all certificates issued are rendered invalid. This allows the rest of the hierarchy to function normally. This type of partitioning is critical to disaster planning, as it provides both additional security and redundancy.


Having a single CA immediately creates a performance bottleneck to administrators. All requests must be submitted to and issued by this CA. When certificates are initially deployed, this CA must generate certificates for all requesting subjects. Even with a very high performance CA issuing 10 certificates per second, it can take a very long time to accept a request, issue the certificate, and present it to the subject for installation. Having more than one CA allows this work to be distributed to all issuing CAs and provides better response times to clients.

One policy and practice statement for the entire hierarchy

A CA can have only one certificate policy and certificate practice statement. If a single CA is employed, these documents must cover all possible scenarios, certificates, and issuance processes for this CA. These documents would almost certainly be too large to be useful for their intended purpose and would become a maintenance headache, as their constant update to reflect the changing hierarchy would be expensive. Smaller, distributed policies and practice statements help ensure that they remain useful and easily managed.

There are also several reasons to avoid certification hierarchies deeper than three levels. These reasons are basic and somewhat obvious. They include being unnecessarily complex, creating more infrastructure than necessary, and requiring more maintenance than a shallower hierarchy. In addition, clients will take longer to validate certificate chains as they get deeper, directly impacting client performance across the organization. Finally, there are very few benefits to having a hierarchy this deep that would justify the expense of an additional middle tier in the hierarchy.

Security Showdown: Two-Tier Versus Three-Tier PKI

A PKI can be designed in any way you see fit, including any number of tiers from the root to the issuing CA. As I've already stated, both two-tier and three-tier architectures are extensively used. In this segment of Security Showdown, Don and Mike will debate the benefits of each.

Don: I like three-tier. You keep your top-level CA offline, literally disconnected from your network and hidden in a locked room full of rabid tigers. That way, absolutely nobody can get to it to compromise it. That root CA is the source of all trust in your entire hierarchy, and you've got to protect it better than the crown jewels. The second tier contains a smaller number of servers, which are authorized by the root?authorized by sneakernet, mind you, since you never connect the root to your network. Just write the certificates to floppy disks and walk them (hence sneakernet) to the second-tier servers.

That second tier gives you a small number of servers to deal with for things like managing revocation and whatnot, which is nice. However, you can't always keep that tier small and manageable and use it to issue a zillion certificates to your users, client computers, customers, and what have you. That's where the third tier comes in. Authorized by the second tier, they carry the brunt of your certificate load. Since all they do is issue certificates to actual security principals, you don't have to manage them as much or put them on especially heavy-duty hardware.

The three-tier design works well for the same reasons that three-tier applications, like web sites, work well. You get manageability, scalability, and security all in one neat architecture.

Mike: Good points. I can certainly see the benefits provided by the three-tier design. However, I think it's overkill. Two tiers in a PKI hierarchy is all most administrators will ever need.

A well-managed root CA will do little other than issue the occasional subordinate CA and publish its CRL. The CRL is incredibly short?in most implementations, the root CA's CRL is empty. And the amount of work the root performs to sign CA certificates is trivial. So why would you want to add an additional middle tier that does about the same trivial amount of work? You can maintain a great two-tier hierarchy and the only change is that you may want the root's CRL published a bit more often.

That middle tier in a three-tier hierarchy also requires several intermediate CAs to be set up and maintained. In a smaller organization, that's simply a waste. Most organizations will not need to revoke an entire CA, as its key will be protected and its compromise will be an exceedingly rare event.

As we know, one immutable security law is that complexity is the enemy of security. The flatter we can keep a PKI hierarchy, the happier we will be. There are fewer things to go wrong and less exposure to attack. I simply don't see the benefit of having that third tier unless you honestly expect a CA to be compromised on a regular basis.

Don: Excellent points, especially for smaller organizations. However, in a larger company, I'd definitely stick with three-tier. You get your totally protected offline root, a second tier of authorizing servers that can be relatively small and therefore easier to control. Finally, you get as many servers as necessary in the third tier to issue certificates to the masses, like your users. Sure, three-tier takes a bit more hardware and management, but this is enterprise technology we're talking about, and a certificate hierarchy is no place to wimp out.

Once you've determined the depth and basic structure of the hierarchy, you should identify the role of each CA in the hierarchy. This is usually straightforward. Each CA is usually categorized into one of three roles: root, intermediate, or issuing CA. These should be defined before we continue.

Root CA

Issues certificates to other CAs. It also issues its own CRL, which is usually short or empty. Functionally, that's all it does. It is the "root" of all trust in the organization. Its certificate is deployed to all subjects as a trusted certificate. The root can either be an online root CA, meaning it is on the company network and accessible from other computers, or it may be an offline root CA that is both physically and logically isolated when it is not being used. It may help to think of the root CA as the king of the PKI. All subjects trust the king, and anyone working in the king's name should also be trusted. The king's workers are the intermediate and issuing CAs.

Intermediate CA

Does not issue certificates to end entities such as users and computers. Instead, it issues certificates to issuing CAs. It acts as a buffer layer between an issuing CA and the root CA. This allows partition of the PKI to be revoked or modified without affecting the rest. The intermediate CA also publishes its own CRL.

Issuing CA

Issues certificates to end entities such as users and computers. It is also responsible for revoking end-entity certificates and regularly publishing a CRL. It receives its certificate from either an intermediate or root CA.

These terms are generic industry terms and are applicable to any CA running any available software. Two types of CA are specific to the Microsoft Windows Server 2003 implementation:

Enterprise certification authority

An authority that is configured to integrate with Active Directory. It requires a connection to an Active Directory domain controller during installation, though the CA itself does not need to be a domain controller. The benefits of using an enterprise CA include the ability to publish certificates and CRLs to Active Directory and the use of certificate templates (which are detailed later in this section). Enterprise CAs can be installed only on servers running Windows Server 2003 Enterprise Edition.

Standalone certification authority

The opposite of an enterprise CA. It is not connected to Active Directory. There are fewer options available on a standalone CA. However, the standalone CA can be run on any computer running Windows Server 2003. The root CA, especially if it is offline and would not normally be available to integrate with Active Directory, is often configured as a standalone CA.

Having a hierarchy with all CA roles identified is the essential component of any good PKI planning. This document should be reviewed to ensure it meets all business and organizational objectives before continuing.

A typical mixed-tier hierarchy with all roles identified is shown in Figure 9-4. This diagram shows all desired certification authorities with their names and roles. Some portions of the hierarchy are two-tiered and some are three-tiered, depending on the business justification for intermediate CAs in each case. The diagram shows a dotted line from the root CA to the authorities it has issued, which indicates that it will function as an offline root CA. The diagram also shows the CA name for each entity. In Microsoft Windows Server 2003, this is frequently the same as the computer name, although they can be different if desired. For simplicity and because there is no other business rule preventing it, I use the CA name as the computer name.

Figure 9-4. A typical certification hierarchy for Woodgrove Bank

Note that finance is isolated from the other portions of the PKI because of the high value and risk of compromise for this department. It also does not require an intermediate due to its low number of issued certificates and high level of assurance.

9.6.2 Desired Certificate Configuration

The purpose of creating a certification authority hierarchy is to create and distribute certificates to clients, which allow them to trust other clients. Early in the planning phase, you should make a careful analysis of the intended uses of certificates. This will allow you to determine the number and configuration of certificates that each type of user will require.

There are two schools of thought on this topic. These two schools are similar to the ways administrators design many technologies with similar flexibility in design. Do you want to issue one multipurpose certificate to each user, or do you want each user to have several certificates, each with its own specific intended use and configuration? Either way can be easily accomplished with the Microsoft Windows Server 2003 CA, so the limitation is not in the technology. The biggest consideration in this area is usually one of application usage and compatibility. Some applications, for example, may use only the first certificate available to them that has a local private key. In those cases, it would be ill-advised to deploy numerous certificates that would confuse and break the application. On the other hand, one multipurpose certificate is beneficial in its ease of administration, and the return on investment (ROI) per certificate is far larger than the multicertificate method.

No matter which decision you make, you will almost certainly want to modify the settings that clients use to obtain a certificate. This can be accomplished by the use of certificate templates. Certificate templates are similar to templates for other data structures in that they define what data is contained and in what format. In this case, certificate templates tell the requester what information to provide to the CA. The CA then uses the template to validate the request's completeness and format, and also to determine what information should be included in the issued certificate. The CA also uses the template to determine various other settings, such as whether the issued certificates should be stored in Active Directory.

Virtually any configuration can be supported with an appropriately customized certificate template. However, there is one caveat for using these templates. There are two versions of certificate templates, Version 1 (v1) and Version 2 (v2). Several v1 templates were included with Windows 2000 Server. They cannot be modified, even in Windows Server 2003, because the v1 templates were created to be static. v2 templates can be created and modified to suit any needs. However, v2 templates can be used only on an enterprise certification authority, because v2 templates are stored in Active Directory. These templates are available to all enterprise CAs in the forest, providing for simplified and centralized certificate template administration.

A typical certificate template used to issue certificates to end users for digitally signing contractual documents might be configured with the values shown in Table 9-1.

Table 9-1. Values for a typical certificate template

Configuration setting


Original Template

User Signature Only

Security Permissions

Authenticated Users: Read, Enroll, Autoenroll

Certificate Administrators: Full Control



Key Usage Extension

Digital Signature, Signature Is Proof of Origin (Nonrepudiation), Selection Marked Critical

This Number of Authorized Signatures


Policy Type Required in Signature

Issuance Policy

Issuance Policy

High Assurance

Validity Period

6 Months

Renewal Period

6 Weeks

This is just one example of the power and flexibility provided by customized v2 certificate templates. Many other settings could be applied to this template based on specific needs. And any number of templates can be created.

9.6.3 Issuing Certificates Automatically

When the certification authority's configuration is set to issue certificates automatically, you need to do some advance planning. The decision to automatically issue certificates based on a template has a profound impact on the overall trustworthiness of a PKI. It should be made through your policy-making decision process and include the support of all stakeholders in the solution. The decision is usually based on one or more factors, including:

Access control on the template or request mechanism

Most certification authorities, including Microsoft's, allow other security mechanisms to be used in conjunction with a certificate request. These are usually placed on the certificate template itself or in the certificate request mechanism. They could also take the form of protecting incoming communications to the certification authority (e.g., an IPSec policy). These access controls ensure that only authentic and appropriate requests can be made for a certificate. Thus, no further safeguards may be necessary. This is the most common case in which certificates are automatically issued.

Low value of certificates

When the value of the issued certificates is not significant, it may be more cost-effective to automatically issue the certificate.

Regular issuance reviews

Instead of limiting the issuance of certificates, you may want to review the certificate issuance logs later to determine if any inappropriate issuances have been made. This is somewhat akin to closing the barn door after the cows have gotten out, but may be appropriate for low-value certificates or low-volume certification authorities.

Regardless of the type, security, or volume of issuance, you should make regular audits of issued certificates. This is the only way to ensure that the certification authority is being used properly. Virtually all certification authorities have extensive auditing capabilities for this reason. Auditing of a Microsoft certification authority is covered in the "Configuring CA Auditing" section later in this chapter.

In many cases, certificate requests should not be automatically issued, and some type of manual process should be employed before certificate issuance occurs. This is commonly referred to as pending certificate requests. The certificate request is retained in the certification authority's database, and the client is notified during the enrollment process that the certificate cannot be issued at that time. The reasons a certificate template may be set to place requests in a queue pending approval include:

High value of issued certificates

Some certificates may have a high value, such as those used for digitally signing contracts or authorizing monetary payments. In these cases, great care must be taken to ensure an unauthorized subject does not receive such a certificate.

Absence of other safeguards

If the certificate template and the certification authority have no access controls placed on certificate requests, any user could potentially submit a certificate request. Often users do not know what they're requesting and may request wholly inappropriate certificates. Placing the request in a pending state allows the certificate manager to determine whether the request is valid and appropriate.

9.6.4 Certificate Revocation Architecture

When a client uses a certificate, she has the ability to extract the CDP information and request the CRL. Because this can happen at any time, it is critical to ensure the CRL is reasonably current at all times. The certification authority can be configured to publish the CRL at any interval required. Several major factors contribute to the decision of how often to publish a CRL:

Size of CRL

The more certificates revoked, the longer the list. Although each entry in the list is quite short (the size of each entry may vary but will almost always be less than 1KB), if a great number of certificates are revoked before they expire, the CRL can increase greatly in size. A CRL can have up to 1000 certificates listed before it reaches its maximum default size and another CRL is automatically created.

Network bandwidth

Each time the CRL is published, it must be distributed to all specified CDPs. If the CRL is published to a distributed location, such as Active Directory, additional replication may take place. In addition, all clients must download their own copy of the CRL when used. This can quickly consume network bandwidth, and if the network is already taxed, this may be an unacceptable drain on resources.

Application CRL support

Remember that applications must support CRL checking for any of this to matter?it is good behavior, but not required. If the applications in your enterprise do not check the CRL or check it only infrequently, frequent distribution could be a waste of time.

Most certificate-aware applications do not document whether they require, support, or ignore CRLs. In general, the only way to determine CRL support is to test the application by deploying a test PKI, issuing and revoking the certificate, and then using that certificate with the application. It might take a bit of time, but it's the only way to be sure.

Security exposure of issued certificates

As I discussed earlier, when considering whether to automatically issue certificate requests or place them in a queue pending approval, each certificate type has a different value. Certificates from a certification authority that issues high-value certificates obviously require a higher level of protection. This means that, in addition to the appropriate applications checking the CRL, the CRL should be published more frequently by those high-value certification authorities. This helps ensure that a revoked certificate has a shorter window for misuse.

Now I'll examine the considerations to make when deploying your private certification hierarchy. There are two major considerations, including whether to use delta CRLs and defining the CDP. Delta certificate revocation lists

To help mitigate some of the negative aspects of frequent CRL publication, you can publish delta CRLs. A delta CRL is, as its name implies, a CRL with only those certificates that have been revoked since the last CRL (or base CRL) was published. This makes a delta CRL much smaller and more easily replicated. Applications that support delta CRL usage check the base and delta CRL to ensure that no compromised certificates are trusted. If the delta CRL is out of date, a new one can be quickly retrieved without having to replace the full CRL. Eventually the entries in a delta CRL will be listed in the full CRL. These intervals are configurable on most certification authorities, including Microsoft's. Specific configuration of a Microsoft CA's CRL is discussed later in this chapter.

Many newer applications and operating systems support the use of delta CRLs when checking certificate revocation status. However, as always, you should verify that the PKI-aware applications you are using will recognize and correctly process a delta CRL. These applications may be incorrectly written to look for only a single base CRL at the CDP. This is not correct behavior when a delta CRL exists, as the base CRL will include a reference to the delta CRL's CDP. However, you must know whether your PKI-leveraging applications handle delta CRL configuration before beginning your deployment. A quick test in a lab would suffice. The test could easily be accomplished with the following tasks. The detailed steps for each task are covered later in this chapter.

  1. Install a root CA.

  2. Configure the CA to issue your desired certificate template.

  3. Configure the CA to publish both base and delta CRLs. Publish your base CRL.

  4. Enroll for and issue a certificate from the test client.

  5. Revoke the issued certificate.

  6. Publish a delta CRL. You now have a revoked certificate that appears on the delta CRL but not the base CRL.

  7. Test the application's use of the certificate. If the application correctly detects that the certificate is invalid, it supports the delta CRL configuration. If the application does not recognize the certificate as revoked, the application does not support the use of a delta CRL.

If your application does not support delta CRLs, you should make one of two decisions. Either modify your deployment plans or obtain an updated version of the application that supports this configuration. If the former option is chosen, you should decide how you will make the CRL shorter. This can be done in several ways, such as shortening the lifetime of issued certificates, separating the users of the misbehaving application to their own CA, or distributing the users to more CAs. CRL distribution points

Choosing a CRL distribution point (CDP) is a fairly simple matter. The main consideration is whether the CDP must be reachable by clients outside the LAN. If the clients are all within the corporate network, choose a highly available centralized server or Active Directory (or both) to act as the CDP. If you will issue certificates to clients both inside and outside the LAN, another CDP should be added that includes an Internet location (or some other location that the intended clients can reach). This is usually a web server, and the CDP is included in the certificates as an HTTP URL, which provides fairly ubiquitous access.

9.6.5 Hardware Plans

Although a CA can be configured on any computer running Windows Server 2003 family, there is some benefit to having it reside on a computer without other software services. The primary benefit is a reduction of attack surface. If other applications or services are running on the CA, they could potentially expose the CA to an attack. It also allows the CA to be kept current with security updates and patches as the need arises with a minimum of effort.

Most server hardware configurations are more than acceptable for a CA running on the Windows Server 2003 family. The CA is a relatively small consumer of CPU horsepower and memory space. Unless the CA is generating and issuing certificates at a constant pace, as in an initial deployment, the server will usually carry a light load relative to other servers in the enterprise. However, as stated earlier, this does not indicate that you should provide other services with the computer. A somewhat idle CA that doesn't fully use the hardware's capabilities is far more secure than a fully loaded server that carries numerous security exposures that an attacker might probe.

Should I Waste Hardware on a Dedicated Root CA?

Many administrators wonder whether a large amount of dedicated equipment is really necessary to maintain an offline root CA. Once the root CA is established and it issues the intermediate or issuing CA certificates, its only ongoing role is to periodically issue a CRL and renew child CA certificates. Its CRL will include only revoked certificates it has directly issued?intermediate or issuing CA certificates. The CA certificates issued by the root are normally long-lived certificates. So there may be days, weeks, or even months in which there is absolutely no activity on the root CA.

However, the root CA must be readily available if a second-tier's certificate is compromised. It is far more efficient to revoke the CA's certificate than the certificate of all issued certificates from the compromised CA, and the compromised key could always be used to issue new nonrevoked certificates. But this requirement for quick access does not mean that the CA cannot have a small lag interval.

The decision on whether to use dedicated computer hardware for the root CA is entirely yours. In some enterprises the root CA is a hard drive that is periodically installed into a standard hardware configuration to issue a fresh CRL. This is a perfectly valid configuration, as long as the root CA can be brought up quickly in case of urgent need. This configuration also allows the continued use of expensive hardware that would otherwise sit mostly idle.

One important consideration when planning hardware investment for the PKI is the physical size and design of the CA hardware. As I've discussed, each CA should be physically secured within a data center specifically designed to provide physical security. The hardware purchase should be a natural extension of that security design. If, for example, the secure data center is configured to support computers in 19-inch racks, the CA hardware should be purchased to fit those racks. This helps ensure there are no surprises during deployment when the computers may be placed in an inappropriate location due to size incompatibility. Cryptographic hardware for certification authorities

Another major consideration when making hardware decisions for your certification authorities is whether to use hardware security modules (HSMs) or cryptographic accelerators. These dedicated and highly specialized devices mitigate numerous threats, assure multifactor authentication, and provide tamper-proof auditing.

At the root of the HSM is the importance of the private key of the CA. You already know that the private key of the CA is used to sign all issued certificates. Compromise of this key allows an attacker to sign any certificate requests he desires, as well as decrypt any information encrypted with the CA's public key. Because of the sensitivity of the CA's private key, it must be protected to whatever extent is deemed necessary. There are several methods to protect the CA's private key. One is to split up the private key using a combination of management techniques and software; that will be discussed later. Another method is to use dedicated hardware.

An HSM is simply a device that holds the private key and allows the key's use only when directed. The HSM is frequently implemented as a small device that connects to a computer's bus via SCSI or PCI and may be configured as an internal or external device. HSMs employ specific software that allows them to notify the CA that the key is available only through the device. When the CA requires the private key for an operation, the appropriate party or parties authenticate themselves with the HSM, and the HSM performs the validation of those parties. When the appropriate number and identity of parties are reached, the HSM does the cryptographic work with the key. The actual private key never leaves the device.

Many organizations are required to use an HSM that meets the Federal Information Processing Standard (FIPS) 140-1?Security for Cryptographic Modules. This is a device-independent standard that defines how an HSM protects private keys and how they can be accessed. FIPS 140-1 has different levels of security, with Level 1 being the least secure and Level 4 being the most secure (and most expensive). You should investigate whether your industry has regulations that define a minimum level of FIPS 140-1 protection before you make any HSM purchases. For most environments, Level 3 protection provides more than adequate private key protection, including protecting against physical attack of the HSM itself.

The incorporation of an HSM in your CA hierarchy provides numerous benefits, including:

A hardware security partition between the computer and the HSM

The cryptographic work with the private key is contained entirely within the HSM. The key is generated on the HSM and remains there forever. Even if the computer is compromised, the key was never known to the computer and cannot be derived from its memory, secondary storage, and so on.

A focal point for security scrutiny

It can be difficult to perform a detailed security analysis of an entire operating system, but an HSM can be subjected to intense scrutiny with minimal effort. They are frequently certified to very high government and military security specifications because of their limited scope and function. They usually employ better random number generation techniques than a computer-based operating system uses.

Auditing of private key usage

Most HSM devices provide the ability to audit each use of the private key. This auditing is done entirely on the HSM and, therefore, cannot be erased or tampered with. Regular reviews of an HSM audit log would reveal any inappropriate use of the private key.

Multifactor authentication

An HSM can easily be configured to perform private key operations only when multiple operators are present. This ensures that no single operator has the opportunity to misuse her privilege and use the private key inappropriately. This goes beyond auditing to be a preventive rather than investigative safeguard.

Acceleration of private key operations

Because a small amount of specially designed hardware is performing dedicated tasks in an HSM, the hardware is more efficient at cryptographic tasks than a computer's multipurpose CPU is. As a result, cryptographically difficult tasks such as long key generation take far less time when performed by an HSM.

Increased randomness

Cryptography relies on random number generation for part of its security. The ability of a computer system to generate values as random as possible contributes directly to the cryptographic security of that system. If the computer's random number generation is predictable, an attacker has an advantage when trying to break its security. Many manufacturers build an improved random number generator into their HSM to help improve randomness. When the CA requires a random number, the HSM uses its own process to generate and return a (hopefully) unpredictable random number. (Note that many security professionals do not believe there is ever a truly random number, and I do not say that an HSM will provide one. However, a number needs to be only sufficiently random as to avoid prediction by an attacker.)