Designing the CA Hierarchy

17 Aug

To design the CA hierarchy in a PKI means to determine the actual CAs that your PKI will use
and the trust relationships between them. In most medium-sized and large networks, deploying
more than one CA is recommended.
This lesson describes the considerations that go into determining how many CAs to deploy,
the types of CAs to deploy, and how many tiers of CAs are suitable for your organization’s
After this lesson, you will be able to:
■ Understand the advantages and disadvantages of deploying an internal CA versus
relying on an external CA.
■ Understand the advantages and disadvantages of enterprise CAs versus standalone
■ Understand the difference between a root CA and a subordinate CA.
■ Understand the advantages of using a two-tier or three-tier hierarchy in your PKI.
■ Design a PKI hierarchy for an organization.
Estimated lesson time: 30 minutes
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.
404 Chapter 9 Planning and Designing a Public Key Infrastructure
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
■ Can be expanded to include additional functionality and users at relatively little extra
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.
Lesson 2: Designing the CA Hierarchy 405
■ 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
406 Chapter 9 Planning and Designing a Public Key Infrastructure
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.
NOTE Mixing standalone and enterprise CAs
You can use both enterprise and standalone CAs in your organization.
Table 9-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.
Table 9-1 Options for Enterprise vs. Standalone CAs
Option Enterprise CA Standalone CA
Publish certificates in Active Directory and use Active Directory
to validate certificate requests
Take the CA offline X
Configure the CA to issue certificates automatically X
Allow administrators to approve certificate requests manually X
Use certificate templates X
Authenticate requests to Active Directory X
Lesson 2: Designing the CA Hierarchy 407
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
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.
NOTE Internal and external policy CAs
Many organizations use one root CA and two policy CAs—one to support internal users and
another to support external users.
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.
408 Chapter 9 Planning and Designing a Public Key Infrastructure
The hierarchy consisting of a root CA, policy CAs, and issuing CAs is illustrated in Figure 9-1.
Figure 9-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.
Root CA
Policy CA Policy CA
Issuing CA
Issuing CA
Issuing CA
Issuing CA
Lesson 2: Designing the CA Hierarchy 409
IMPORTANT The root CA should be a standalone, workgroup CA
Installing an offline CA on a server that is a member of a domain can cause problems with a secure
channel when you bring the CA back online after a long offline period. This is because the computer
account password changes every 30 days. You can get around this by making offline CA
computers members of a workgroup. Installing an offline CA as an enterprise CA can cause Active
Directory to have problems updating when you disconnect the server from the network. Therefore,
do not use an enterprise CA as a root CA.
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.
Quick Check
■ Why should a root CA remain offline?
Quick Check Answer
■ To protect the entire PKI from becoming compromised in case of a network attack.
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:
■ First, do you require only one CA? If you are supporting only a single application and
location, and if 100 percent availability of the CA is not critical, you might be able to use
a single CA. Otherwise, you probably require at least one root and multiple subordinate
■ If you need more than one CA, how many root CAs do you require? Generally, it is recommended
that you have only one root CA as a single point of trust. This is because significant
cost and effort is required to protect a root CA from compromise. With multiple
root CAs, root maintenance becomes much more difficult.
410 Chapter 9 Planning and Designing a Public Key Infrastructure
However, organizations with a decentralized security administration model, such as corporations
with multiple, largely independent business units and no strong central
administrative body, might require more than one root CA.
■ How many intermediate or policy CAs do you need?
■ How many issuing CAs or RAs do you need?
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.
PRACTICE Planning the CA Infrastructure
You are an enterprise administrator at Humongous Insurance, Inc., a company that specializes
in selling automobile insurance at discount prices. The company consists of a headquarters in
New York City and three branch offices in Albany, Binghamton, and Buffalo. The company
employs about 800 workers among its four office sites. The Humongous Insurance network
consists of a single Active Directory domain,
Humongous Insurance is planning to launch a new version of its Web site that allows customers
to view confidential data. In advance of the new site launch, the company has recently
updated its written security policy. The chief security officer has given you the responsibility of
Lesson 2: Designing the CA Hierarchy 411
designing a PKI to meet the new security needs of the company. Currently, the company does
not have any CA deployed.
The company’s updated written security policy includes the following requirements:
■ The Web site must require an encrypted Hypertext Transfer Protocol (HTTP) connection
when users view account data.
■ All e-mail messages sent among employees must be encrypted.
■ All remote server administration must be conducted over an encrypted channel.
■ At any of the four company branches, access to the company wireless network must
require smart card authentication.
 Exercise Planning for a PKI Deployment
In this exercise, you review the business and technical requirements and answer specific questions
to help you plan for PKI deployment.
1. Name the specific applications implied by the security policy that require the use of public
key cryptography.
❑ Web encryption (SSL), for the encrypted HTTP connection when users view
account data.
❑ Secure e-mail, to encrypt e-mail messages sent among employees.
❑ Smart card authentication (with 802.1x), to support the smart card requirement
for wireless access.
(Note that although IPsec is required for the remote server administration over an
encrypted channel, IPsec typically uses Kerberos instead of a public key cryptography in
an Active Directory environment.)
2. Who must obtain the certificates for each of these applications? In particular, specify
whether each application requires certificates for users or computers.
❑ Web encryption: only the Web server (computer) must obtain a certificate.
❑ Secure e-mail: all users in the organization must obtain certificates.
❑ Smart card authentication: users needing wireless access must obtain a smart card
(which includes a user certificate).
3. For each of the applications, specify whether the certificates required should be assigned
by a public CA or an in-house CA.
❑ Web encryption: the Web server should obtain a certificate from a public CA such
as VeriSign or Thawte.
❑ Secure e-mail: users should obtain certificates from an in-house CA.
❑ Smart card authentication: users should obtain certificates from an in-house CA.
412 Chapter 9 Planning and Designing a Public Key Infrastructure
4. For each of the applications that will be supported by an in-house CA, specify whether
the CA should be an enterprise CA or a standalone CA.
❑ Secure e-mail: Enterprise CA
❑ Smart card authentication: Enterprise CA
5. Given the size of the company and best practices for PKI deployments, design the CA
hierarchy for the certificate infrastructure. Specifically, determine how many tiers for the
certificate infrastructure are needed; whether a root CA, intermediate CAs, and issuing
CAs are needed; and which of these should be kept online or offline.
❑ Large companies such as Humongous Insurance should include three tiers in the
CA hierarchy. The root CA should be kept offline, the intermediate CAs should
also be kept offline, and the issuing CAs should be kept online.
Lesson Summary
■ To plan a CA infrastructure, you need to determine how many CAs to deploy, the types
and roles of CAs to deploy, and the trust relationships among those CAs.
■ Within a PKI, a final authority, called a root CA, must be in place. Beneath this root CA,
a PKI can include any number of subordinate CAs. A subordinate CA can act as a parent
to verify the integrity of another subordinate CA. When a PKI includes three tiers in this
way, the higher subordinate is known as an intermediate CA or policy CA. CAs that
actively issue certificates are found at the lowest level of the hierarchy and are known as
issuing CAs.
■ As part of the PKI design process, you need to determine whether to use internal CAs, an
external CA, or a combination of both.
■ As part of the PKI design process, you need to determine which CAs in your PKI should
be enterprise CAs and which should be standalone CAs.
Lesson Review
You can use the following questions to test your knowledge of the information in Lesson 2,
“Designing the CA Hierarchy.” The question is also available on the companion CD if you prefer
to review it in electronic form.
NOTE Answers
Answers to these questions and explanations of why each answer choice is correct or incorrect are
located in the “Answers” section at the end of the book.
Lesson 2: Designing the CA Hierarchy 413
1. You work as an IT administrator in a large company, City Power and Light. The network consists of a single Active Directory Domain Services domain.
You are a member of a team designing a new in-house PKI for use with EFS. Your goals
are to minimize the risk that the entire PKI will be compromised and to minimize the
administrative overhead of publishing certificates. Which of the following CAs should
you deploy for your PKI hierarchy? (Choose two. Each correct answer represents part of
the solution.)
A. Offline root CA
B. Online root CA
C. Enterprise subordinate CA
D. Standalone subordinate CA

Random Posts

No comments yet

Leave a Reply

You must be logged in to post a comment.