C H A P T E R
1 6
Designing a Public Key
Infrastructure
Microsoft® Windows® Server 2003 enables a variety of secure applications and business scenarios based on the
use of digital certificates. Before you can use digital certificates, however, you need to design a public key
infrastructure (PKI), which involves planning configuration options for one or more certification authorities,
preparing certificates to meet the needs of your organization, and creating a PKI management plan.
In This Chapter
Overview of the PKI Design Process ............................................................................................... 730
Defining Certificate Requirements ................................................................................................. 735
Designing Your CA Infrastructure .................................................................................................... 746
Extending Your CA Infrastructure .................................................................................................... 776
Defining Certificate Configuration Options .................................................................................... 788
Creating a Certificate Management Plan ...................................................................................... 810
Deploying the PKI .............................................................................................................................. 830
Additional Resources ........................................................................................................................ 842
Related Information

For more information about Windows Server 2003 public key features, see the Distributed
Services Guide of the Microsoft® Windows® Server 2003 Resource Kit (or see the Distributed
Services Guide on the Web at http://www.microsoft.com/reskit).

For more information about using certificates in conjunction with Encrypting File System, see
the Distributed Services Guide of the Windows Server 2003 Resource Kit (or see the
Distributed Services Guide on the Web at http://www.microsoft.com/reskit).

For more information about deploying smart cards, see “Planning a Smart Card Deployment” in
this book.
730 Chapter 16 Designing a Public Key Infrastructure
Overview of the PKI Design
Process
Organizations use a variety of technology solutions to enable essential business processes, such as online
ordering, exchanges of contracts, and remote access. A public key infrastructure based on Microsoft Windows
Server 2003 Certificate Services provides a means by which organizations can secure these critical internal and
external processes.
Deploying a PKI allows you to perform tasks such as:

Digitally signing files such as documents and applications.

Securing e-mail from unintended viewers.

Enabling secure connections between computers, even if they are connected over the public
Internet or through a wireless network.

Enhancing user authentication through the use of smart cards.
If your organization does not currently have a public key infrastructure, begin the process of designing a new
public key infrastructure by identifying the certificate requirements for your organization. If your organization
already uses a public key infrastructure based on Microsoft ® Windows NT® version 4.0, Microsoft®
Windows® 2000, or third-party certificate services, you can improve your PKI capabilities by taking advantage
of new and enhanced features in Microsoft ® Windows® Server 2003, Standard Edition; Windows® Server 2003,
Enterprise Edition; and Windows® Server 2003, Datacenter Edition. When you have completed the PKI design
process, you can deploy a public key infrastructure that provides solutions for all of your internal security
requirements, as well as security requirements for business exchanges with external customers or business
partners.
Note
For a list of the job aids that are available to assist you with the PKI
design process, see “Additional Resources“ later in this chapter.
Overview of the PKI Design Process 731
Process for Designing a PKI
Designing a PKI for your organization involves defining your certificate requirements, creating a design for
your infrastructure, creating a certificate management plan, and deploying your PKI solution. Figure 15.1 shows
the steps that are involved in designing a public key infrastructure.
Figure 15.1 Designing a PKI
Note
The steps involved in designing a PKI are interdependent. For example,
defining certificate server configurations, locations, and roles has a
significant impact on how you address key certificate management
issues. Your evolving certificate management standards in turn have
significant implications for the certificate server roles, locations, and
configurations that you develop.
732 Chapter 16 Designing a Public Key Infrastructure
Basic PKI Concepts
Public key infrastructure is the term used to describe the laws, policies, procedures, standards, and software that
regulate or control the operation of certificates and public and private keys. More specifically, a PKI is a system
of digital certificates, certification authorities, and other registration authorities that verify and authenticate the
validity of each party involved in an electronic transaction.
A PKI consists of the following basic components:
Digital certificates Electronic credentials, consisting of public keys, which are used to sign and
encrypt data. Digital certificates provide the foundation of a PKI.
One or more certification authorities (CAs) Trusted entities or services that issue digital
certificates. When multiple CAs are used, they are typically arranged in a carefully prescribed order and perform
specialized tasks, such as issuing certificates to subordinate CAs or issuing certificates to users.
Certificate policy and practice statements The two documents that outline how the CA and
its certificates are to be used, the degree of trust that can be placed in these certificates, legal liabilities if the
trust is broken, and so on.
Certificate repositories A directory service or other location where certificates are stored and
published. In a Windows Server 2003 domain environment, the Active Directory® directory service is the most
likely publication point for certificates issued by Windows Server 2003–based CAs.
Certificate revocation lists (CRL) Lists of certificates that have been revoked before reaching
the scheduled expiration date.
Note
With Certificate Services in Windows Server 2003, Microsoft introduces a
new type of certificate revocation list called a delta CRL, which allows
you to publish information about recently revoked certificates more
frequently without using the bandwidth required for publishing full CRLs.
Certificate trust lists These are signed lists, which are located on the client, of trusted CA
certificates. Certificate trust means that a certificate is part of a certificate trust list (CTL) or that the CTL
contains a trusted certificate from another CA that is part of the certificate’s certificate chain. Windows
Server 2003 domain administrators can use Group Policy objects (GPOs) to publish and maintain CTLs.
Overview of the PKI Design Process 733
Key archival and recovery A feature that makes it possible to archive and recover the private
key portion of a public-private key pair, in the event that a user loses his or her private keys, or an administrator
needs to assume the role of a user for data access or data recovery. Private key recovery does not recover any
data or messages; it merely enables the recovery process.
Public key standards Standards developed to describe the syntax for digital signing and
encrypting of messages and to ensure that a user has an appropriate private key. To maximize interoperability
with third-party applications that use public key technology, the Windows Server 2003 PKI is based on the
standards recommended by the Public-Key Infrastructure (X.509) (PKIX) working group of the Internet
Engineering Task Force (IETF). Other standards that the IETF has recommended also have a significant impact
on public key infrastructure interoperability, including standards for Transport Layer Security (TLS),
Secure/Multipurpose Internet Mail Extensions (S/MIME), and Internet Protocol security (IPSec).
Windows Server 2003 PKI
You can use PKI-based applications on workstations and servers running Microsoft ® Windows® XP
Professional, Windows Server 2003, Windows® 2000, or Windows NT 4.0, as well as on workstations running
Microsoft® Windows® 95 and Microsoft® Windows® 98. The ability to create and manage a PKI is available in
Microsoft® Windows NT® 4.0 Server, Microsoft® Windows® 2000 Server, and Windows Server 2003.
However, Windows Server 2003 provides more extensive support for a PKI.
In addition, a growing number of applications and system services that require the secure transfer of information
also rely on the Windows Server 2003 PKI. Applications that are enabled for certificate-based security include
Microsoft® Outlook®, Internet Explorer®, Internet Information Services, Microsoft® Exchange Server,
Microsoft® Commerce Server 2000 and Commerce Server 2002, Outlook Express, and Microsoft® SQL
Server™. A number of third-party applications also take advantage of the Windows Server 2003 PKI.
How a Public Key Infrastructure Works
A Windows Server 2003 PKI makes it possible for an organization to do the following:

Publish certificates. The PKI administrator makes certificate templates available to clients
(users, services, applications, and computers) and enables additional CAs to issue certificates.

Enroll clients. To participate in a PKI, users, services, or computers must request and receive
certificates from an issuing CA or a Registration Authority (RA). Typically, enrollment is
initiated when a requester provides unique information and a newly generated public key. The
CA administrator or enrollment agent uses the information provided to authenticate the identity
of the requester before issuing a certificate.
734 Chapter 16 Designing a Public Key Infrastructure

Use certificates. Clients use their certificates, which are validated or invalidated in a timely
manner as long as CAs and certificate revocation lists are available to verify or deny their
authenticity. If they are validated, a PKI provides an easy way for users to use keys in
conjunction with applications that perform public key cryptographic operations, making it
possible to provide security for e-mail, e-commerce, and networks.

Renew or revoke certificates. A well-designed PKI makes it easy for you to renew or revoke
existing certificates, and to manage the trust level associated with certificates used by different
clients or for different applications.
The status of a public key certificate is determined by means of the chain building process. Chain building is the
process of building a trust chain, or certification path, from the end certificate to a root CA that is trusted by the
security principal. Figure 15.2 shows a certification path in a two-level CA hierarchy.
Figure 15.2 Certification Path in a Two-Level CA Hierarchy
In this example, the issuing CA issued the User certificate, and the root CA issued the certificate of the issuing
CA. This is considered a trusted chain, because it terminates with a root CA certificate that has been designed
and implemented to meet the highest degree of trust.
The chain building process validates the certification path by checking each certificate in the certification path
from the end certificate to the certificate of the root CA. If the CryptoAPI discovers a problem with one of the
certificates in the path, or if it cannot find a certificate, the certification path is either considered invalid or is
given less weight than a fully validated certificate.
For more information about how PKIs function, see the Distributed Services Guide of the Windows Server 2003
Resource Kit (or see the Distributed Services Guide on the Web at http://www.microsoft.com/reskit).
Defining Certificate Requirements 735
Defining Certificate Requirements
You can use a Windows Server 2003 public key infrastructure to provide a wide range of strong, scalable,
cryptography-based solutions for network and information security. The value of the information that you want
to protect, as well as the costs involved with implementing a strong security system, impact the level of security
that you choose for your organization.
Figure 15.3 shows the steps that are involved in determining your certificate requirements.
Figure 15.3 Defining Certificate Requirements
736 Chapter 16 Designing a Public Key Infrastructure
Determining Secure Application
Requirements
Before you begin to design your public key infrastructure and configure certificate services, you need to define
the security needs of your organization. For example, does your organization require electronic purchasing,
secure e-mail, secure connections for roaming users, or digital signing of files? If so, you need to configure CAs
to issue and manage certificates for each of these business solutions.
A Windows Server 2003 PKI can support the following security applications:

Digital signatures

Secure e-mail

Software code signing

Internet authentication

IP security

Smart card logon

Encrypting file system user and recovery certificates

802.1x authentication
Digital Signatures
A digital signature is a means for originators of a message, file, or other digitally encoded information to bind
their identities to the data. This can be extremely useful for important documents such as legal opinions and
contracts. The process of digitally signing information involves transforming the information, together with
some secret information held by the sender, into a tag called a signature. Digital signatures are used in public
key environments to help secure electronic commerce transactions by providing verification that the individual
sending the message is who he or she claims to be, and by confirming that the message received is identical to
the message sent.
You can use digital signatures even when data is distributed in plaintext, such as with e-mail. In this case, while
the sensitivity of the message itself does not warrant encryption, it can be important as a means to ensure that
the data is in its original form and has not been sent by an impostor.
One way that your organization can capitalize on the use of digital signatures is by using CAPICOM.
CAPICOM is an ActiveX control that provides a COM interface to Microsoft CryptoAPI. It exposes a select set
of CryptoAPI functions to enable application developers to incorporate digital signing and encryption
functionality into their applications. Because CAPICOM uses COM, application developers can access this
functionality in a number of programming environments, such as Microsoft ® Visual Basic®, Microsoft® Visual
Basic® Scripting Edition, Active Server Pages, Microsoft® JScript®, C++, and others. CAPICOM is packaged as
an ActiveX control, allowing Web developers to use it in Web-based applications as well.
Defining Certificate Requirements 737
You can use CAPICOM for:

Digitally signing data with a smart card or software key.

Verifying digitally signed data.

Displaying certificate information.

Inspecting certificate properties such as subject name or expiration date.

Adding and removing certificates from the certificate stores.

Encrypting and decrypting data with a password.

Encrypting and decrypting data by means of public keys and certificates.
Secure E-mail
Standard Internet mail is sent as plaintext over open networks with no security. In the increasingly
interconnected network environments of today, intruders can monitor mail servers and network traffic to obtain
proprietary or sensitive information. You also risk exposure of proprietary and confidential business information
when you send mail over the Internet from within your organization.
Another form of intrusion is impersonation. On IP networks, anyone can impersonate mail senders by using
readily available tools to counterfeit the originating IP address and mail headers. When you use standard
Internet mail, you can never be sure who really sent a message or whether the contents of the message are valid.
Moreover, malicious attackers can use mail to cause harm to the recipient computers and networks (for example,
by sending attachments that contain viruses).
For these reasons, many organizations have placed a high priority on implementing secure mail services that
provide confidential communication, data integrity, and non-repudiation. A Windows Server 2003 public key
infrastructure allows you to enhance e-mail security by using certificates to prove the identity of the sender, the
point of origin of the mail, and the authenticity of the message. It also makes it possible to encrypt mail. To
provide message authentication, data integrity, and non-repudiation, secure mail clients can sign messages with
the private key of the sender before sending the messages. The recipients then use the public key of the sender
to verify the message by checking the digital signature.
S/MIME clients that run on any platform or operating system can exchange secure mail because all
cryptographic functions are performed on the clients, not on the servers.
738 Chapter 16 Designing a Public Key Infrastructure
Software Code Signing
A growing number of applications, ActiveX® controls, and Java applets are being downloaded and installed on
computers with little or no user notification.
In response to this problem, Microsoft introduced Authenticode™ digital signature technology in 1996, and in
1997 added significant enhancements to this technology. Authenticode technology allows software publishers to
digitally sign any form of active content, including multiple-file archives. These signatures can be used to verify
both the publishers of the content and the content integrity at time of download. Many software vendors already
sign their applications and you can use these signatures to manage the software applications used on your
network.
Authenticode relies on a certification authority structure in which a small number of commercial CAs issue
software-publishing certificates. If you want to expand the use of software-publishing certificates in your own
organization, the Windows 2000 and Windows Server 2003 PKI allows you to issue your own Authenticode
certificates to internal developers or contractors and allows any employee to verify the origin and integrity of
downloaded applications.
Internet Authentication
The Internet has become a key element in the growth of electronic commerce. However, for many users,
security considerations impact how much and what kind of information they are willing to share across the
Internet. The major concerns are:

Confidentiality. Data that is transferred between clients and servers needs to be encrypted to
prevent its exposure over public Internet links.

Server authentication. Clients need a way to verify the identity of the servers they are
communicating with.

Client authentication. Servers need a way to verify the identity of clients.
Client authentication of the server takes place when the client verifies the cryptographic signatures on the
certificate of the server, and any intermediate CA certificates, to a root CA certificate located in the trusted root
store on the client. Server authentication of the client is accomplished when the server verifies the cryptographic
signatures on the certificate of the client, and any intermediate CA certificates, to a root CA installed in the
trusted root store on the server. When the identity of the client is verified, the server can establish a security
context to determine what resources the client is allowed or not allowed to use on the server.
Defining Certificate Requirements 739
IP Security
Windows 2000 and Windows Server 2003 incorporate Internet Protocol security (IPSec) to protect data moving
across the network. IPSec is a suite of protocols that allows encrypted and digitally signed communication
between two computers or between a computer and a router over an insecure network. The encryption is applied
at the IP network layer, which means that it is transparent to most applications that use specific protocols for
network communication. IPSec provides end-to-end security, meaning that the IP packets are encrypted or
signed by the sending entity, are unreadable en route, and can be decrypted only by the recipient entity. Due to a
special algorithm for generating the same shared encryption key at both ends of the connection, the key does not
need to be passed over the network.
You do not need to use public key technology to use IPSec; instead you can use the Kerberos version 5
authentication protocol or shared secret keys that are communicated securely by means of an out-of-band
mechanism at the network end points for encryption. However, if you use public key technology in conjunction
with IPSec, you can create a scalable distributed trust architecture in which IPSec devices can mutually
authenticate each other and agree upon encryption keys without relying on prearranged shared secrets, either
out-of-band or in-band. This, in turn, yields a higher level of security than IPSec without a PKI.
For more information about deploying IPSec solutions, see “Deploying IP Security” in Deploying Network
Services of this kit.
Smart Card Logon
Smart card logon is integrated with the Kerberos version 5 authentication protocol implemented in Windows
Server 2003. When smart card logon is enabled, the system recognizes a smart-card insertion event as an
alternative to the standard Ctrl + Alt + Del secure attention sequence to initiate a logon. The user is then
prompted for the smart card PIN code, which controls access to operations performed by using the private key
stored on the smart card. In this system, the smart card also contains a copy of the certificate of the user (issued
by an enterprise CA). This allows the user to roam within the domain.
Smart cards enhance the security of your organization by allowing you to store extremely strong credentials in
an easy-to-use form. Requiring a physical smart card for authentication virtually eliminates the potential for
spoofing the identities of your users across a network. In addition, you can also use smart card applications in
conjunction with virtual private networks and certificate mapping, and in e-commerce. For many organizations,
the potential to use smart cards for logon is one of the most compelling reasons for implementing a public key
infrastructure.
For more information about deploying smart cards, see “Deploying Smart Cards” in this book.
740 Chapter 16 Designing a Public Key Infrastructure
Encrypting File System Use and Recovery
The Windows Server 2003 Encrypting File System (EFS) allows users and services to encrypt their data to
prevent others who authenticate to the system from viewing the information. However, EFS also provides for
data recovery if another means is needed to access this data — for example, if the user who encrypted the data
leaves the organization, or if the original encryption key is lost. To support this requirement, EFS allows
recovery agents to configure public keys that are used to enable file recovery. The recovery key only makes
available the randomly generated file encryption key, not a private key of the user. This ensures that no other
private information is accidentally revealed to the recovery agent.
Note
You do not need to have a public key infrastructure to use Windows
Server 2003 Encrypting File System. However, the use of public keys
improves the manageability of EFS. In a Windows domain environment,
it is recommended that EFS be used in conjunction with a PKI.
For more information about EFS, see the Distributed Services Guide of the Windows Server 2003 Resource Kit
(or see the Distributed Services Guide on the Web at http://www.microsoft.com/reskit).
Wireless (802.1x) Authentication
A growing number of organizations and facilities such as airports and hotels are implementing wireless network
access. This creates the challenge of ensuring that:

Only authenticated users can access the wireless network.

Data transmitted across the wireless network cannot be intercepted.
Public key infrastructures, in conjunction with the IEEE 802.1x standard for port-based network access control,
support both of these goals by providing centralized user identification, authentication, dynamic key
management, and accounting to provide authenticated network access to 802.11 wireless networks and to wired
Ethernet networks.
For more information about deploying a wireless network, see “Deploying a Wireless LAN” in this book.
Defining Certificate Requirements 741
Determining Certificate Requirements for
Users, Computers, and Services
After you have identified the security technologies that you need to implement to meet the business needs of
your organization, you need to identify the categories of users, computers, and services that will use these
technologies and for which you need to provide certificate services. For example, certificate use might be based
on job function, location, organizational structure, or a combination of these three, or all computers or users in
the organization might use certain certificate applications.
For each of the groups that you have identified, you need to determine:

The types of certificates to be issued. This is based on the security application requirements of
your organization and the design of your PKI infrastructure.

The number of users, computers, and applications that need certificates. This number can
include as few as one or as many users, computers, or applications as are in an entire
organization.

The physical location of the users, computers, and applications that need certificates.
Different certificate solutions might be required for users in remote offices or for users who
travel frequently than are required for users in the headquarters office of an organization. Also,
requirements can differ based on geography. For example, you might want to restrict users in
one country/region from using their certificates to access data in an organizational business unit
in another country/region.

The level of security that is required to support the users, computers, and applications
that need certificates. Users who work with sensitive information typically require higher
levels of security than other members of the organization.

The number of certificates required for each user, computer, and application. In some
cases, one certificate can meet all requirements. Other times, you need multiple certificates to
enable specific applications and meet specific security requirements.

The enrollment requirements for each certificate that you plan to issue. For example, do
users have to present one or more pieces of physical identification, such as a driver’s license, or
can they simply request a certificate electronically?
Note
For a worksheet to assist you in identifying user certificate requirements,
see “Summary of User Certificate Requirements” (DSSPKI_1.doc) on the
Windows Server 2003 Deployment Kit companion CD (or see “Summary
of User Certificate Requirements” on the Web at
http://www.microsoft.com/reskit).
742 Chapter 16 Designing a Public Key Infrastructure
Documenting Certificate Policies and
Practices
Designing a public key infrastructure involves configuring certificates and certification authorities, developing
support procedures, and establishing a system of checks and balances for administrative authority. Only by
effectively addressing both the technical and administrative issues related to your public key infrastructure can
you ensure that your certificate services provide the level of security that your organization requires
It is helpful to record the decisions that you make as you design your PKI by creating certificate policy
statements and certificate practice statements. These documents assist you in planning and in communicating
with individuals and businesses outside your organization. For many organizations and certificate uses,
certificate policy statements and certificate practice statements are considered legal documents or legal
disclaimers.
In general, the IT department is responsible for setting and maintaining PKI policies and practices. However,
because of the legal, financial, and tactical uses of PKIs, representatives from outside the IT department, such as
human resources, finance, legal, and marketing, might also be involved in establishing certificate policies.
A certificate policy is a set of rules that indicates the applicability of a certificate to a particular group of clients
or applications that have common security requirements. Certificate policy statements generally include the
following types of information:

How users are authenticated to the CA.

Legal issues, such as liability, that might arise if the CA is either compromised or used for
something other than its intended purpose.

The intended purpose of the certificate.

Private key management requirements, such as storage on smart cards or other hardware
devices.

Whether the private key can be exported or archived

Requirements for users of the certificates, including what users must do in the event that their
private keys are lost or compromised.

Requirements for certificate enrollment and renewal.

Minimum length for the public key and private key pairs.
Important
You can implement many of the decisions that you document in your
certificate policy statements by creating a CAPolicy.inf file and copying it
to the system directory of the CA before the CA is installed or renewed.
For more information about CAPolicy.inf file contents and configuration,
see the Distributed Services Guide of the Windows Server 2003
Resource Kit (or see the Distributed Services Guide on the Web at
http://www.microsoft.com/reskit).
Defining Certificate Requirements 743
A certificate practice statement is a statement of the practices that IT uses to manage the certificates that it
issues. It describes how the certificate policy of the organization is interpreted in the context of the system
architecture of the organization and its operating procedures. The IT department is responsible for preparing and
maintaining the certificate practice statement.
A certificate practice statement usually includes the following types of information:

Positive identification of the CA (including CA name, server name, and DNS address).

The certificate policies that are implemented by the CA and the certificate types that are issued.

The policies, procedures, and processes for issuing, renewing, and recovering certificates.

Cryptographic algorithms, cryptographic service providers (CSPs), and key length used for the
CA certificate.

Physical, network, and procedural security for the CA.

The certificate lifetime of each certificate issued by the CA.

Policies for revoking certificates, including conditions for certificate revocation, such as
employee termination and misuse of user rights.

Policies for CRLs, including where to locate CRL distribution points and how often CRLs are
published.

A policy for renewing the certificate of the CA before its expiration.
It is best to create a certificate practice statement for each CA in your public key infrastructure. The certificate
practice statement associated with a CA can incorporate multiple certificate policies. Also, to consolidate
information, the certificate practice statement for a subordinate CA can reference common or general
information in the certificate practice statement of a parent CA.
For an outline to assist you in creating a certificate practice statement, see “Certificate Practice Statement
Outline” (DSSPKI_2.doc) on the Windows Server 2003 Deployment Kit companion CD (or see “Certificate
Practice Statement Outline” on the Web at http://www.microsoft.com/reskit).
Important
In some situations, such as when digital signatures are used on binding
contracts, the certificate practice statement can also be considered a
legal statement about the level of security that is provided and the
safeguards that are being used to establish and maintain the security
level.
744 Chapter 16 Designing a Public Key Infrastructure
Example: Defining Certificate Requirements
An organization decides to implement a public key infrastructure because a number of business units within the
organization are using certificate services independently. The business units use similar infrastructures that
include many of the same components — such as CAs and certificate templates — and have similar goals.
Therefore, the organization develops a PKI with a central corporate root that also allows individual business
units to implement certificate services for their specific needs.
The organization chooses to use certificate services for the following:

E-mail

Internet authentication

Encrypting File System

Software code signing

Smart card logon
In addition, they identify the following requirements:

All users throughout the organization are required to use certificates in order to secure e-mail
traffic.

Individual business units need to use Internet authentication to facilitate the sharing of data on
their local networks with their joint venture partners.

All users are able to use Encrypting File System.

Developers and network administrators must use software code signing for the custom
applications and scripts of the organization.

Administrators are required to log on using a smart card before they can perform certain tasks,
such as administering domain controllers.
The organization then divides these requirements into the following security classifications:

Medium security, which includes the e-mail and EFS certificates.

Internal high security, which includes the software code signing and smart card logon
certificates, and serves the needs of network administrators and developers.

External high security, which includes the Internet authentication certificates and meets the
need of the organization to share information with joint venture partners.
Defining Certificate Requirements 745
Figure 15.4 shows an example of the User Certificate Requirements worksheet that the organization created to
summarize these classifications.
Figure 15.4 Example of a User Certificate Requirements Worksheet
For a worksheet to assist you in documenting your certificate requirements, see “User Certificate Requirements”
(DSSPKI_1.doc) on the Windows Server 2003 Deployment Kit companion CD (or see “User Certificate
Requirements” on the Web at http://www.microsoft.com/reskit).
After they have planned the trust relationships for the internal CA infrastructure and extended external CA
infrastructure, the organization can design its certificates and certificate management processes. Administrators
must examine the security and user requirements to develop a secure certificate services solution. For more
information about designing certificates and configuring CAs, see “Creating a Certificate Management Plan”
later in this chapter.
746 Chapter 16 Designing a Public Key Infrastructure
Designing Your CA Infrastructure
To support the certificate-based applications of your organization, you must establish a framework of linked
CAs that are responsible for issuing, validating, renewing, and revoking certificates as needed. The goal in
establishing a CA infrastructure is to provide reliable service to users, manageability for administrators, and
flexibility to meet both current and future needs, while maintaining an optimum level of security for the
organization.
Figure 15.5 shows the steps involved in designing your CA infrastructure.
Figure 15.5 Designing Your CA Infrastructure
Designing Your CA Infrastructure 747
Planning Core CA Options
Before you can establish a CA infrastructure that meets the security needs and certificate requirements for your
organization, you need to make decisions about a number of core CA options that are available. Planning the
CA infrastructure for your organization involves making decisions about the following:

Location of the root certification authorities.

Internal versus third-party CAs.

Requirements for CA capacity, performance, and scalability.

Your Active Directory structure.

Your PKI management model.

CA types and roles.

Use of hardware cryptographic service providers.

Number of CAs required.
Designing Root CAs
A CA infrastructure consists of a hierarchy of CAs that trust one another and 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 certification authorities to publish and manage certificates within the organization. Before you
establish a CA hierarchy, you must determine the following:

Who designates the root certification authority in the organization. For example, determine
whether this is the responsibility of central IT, divisional IT departments, or a third-party
organization.

Where the root certification authority is to be located.

Who manages the root certification authority.

Whether the role of the root CA is only to certify other certification authorities, or also to serve
certificate requests from users.
After you have made these determinations, you can define the roles for any additional certification authorities,
including who manages them and what trust relationships they have with other CAs. For more information
about CA roles, see “Defining CA Roles in the Trust Hierarchy” later in this chapter.
748 Chapter 16 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 certification authority
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 infrastructure of the organization.

Can be expanded to include additional functionality and users at relatively little extra cost.
The disadvantages associated with using internal CAs include:

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 use of third-party CAs include:

They typically involve a high per-certificate cost.

They might require the development of two different management standards, one for internally
issued certificates and one for commercially issued certificates.

They allow less flexibility in configuring and managing certificates.
Designing Your CA Infrastructure 749

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.
You might need to use both internal and third-party CAs. For information about using a combination of internal
and third-party CAs in your organization, see “Extending Your CA Infrastructure” later in this chapter.
Evaluating CA Capacity, Performance, and Scalability
Organizations must agree upon a definition of acceptable CA performance. To determine the appropriate
number of CAs and the best configuration for your CA infrastructure, you need to evaluate and address the
factors in your organization that impact CA capacity, performance, and scalability. These include:

The number of certificates that you need to issue and renew.

The key lengths of the issuing CA certificates.

The type of hardware that is used for your CAs.

The number and configuration of the client computers that you need to support.

The quality of your network connections.
A stand-alone Windows Server 2003 CA supports more than 35 million certificates per physical CA without
any degradation of performance.
An individual departmental certification authority running on a server with a dual processor and 512 megabytes
(MB) of RAM can issue more than 2 million standard-key-length certificates per day. Even with an unusually
large CA key, a single stand-alone CA with the appropriate hardware is capable of issuing more than 750,000
user certificates per day.
Using a greater number of small CAs with strategically located CRL distribution points reduces the risk that
your organization might be forced to revoke and reissue all its certificates if a large CA is compromised.
However, using a greater number of CAs might increase your administrative overhead.
For many organizations, the primary limitations to CA performance are the amount of physical storage available
and the quality of the clients’ network connectivity to the CA. If too many clients attempt to access your CA
over slow network connections, autoenrollment requests can be delayed.
Another significant factor is the number of roles that a CA server performs on the network. If a CA server is
operating in more than one capacity in the network — for example, if it also functions as a domain controller —
it can negatively impact the capacity and performance of the CA. It can also complicate the delegation of
administration for the CA server. For this reason, unless your organization is extremely small, use your CAs
only to issue certificates.
750 Chapter 16 Designing a Public Key Infrastructure
Some hardware components impact PKI capacity and performance more than others. When you are selecting the
server hardware for your CAs, consider the following:

Number of CPUs. Large CA key sizes require more CPU resources. The greater the number of
CPUs, the better the performance of the CA. CPU power is the most critical resource for a
Windows Server 2003 certification authority.
Note
Because of the architecture of their databases, Windows Server 2003
certification authorities are CPU-intensive and use a substantial amount
of the disk subsystem. However, other hardware resources can also
impact the performance of a CA when the system is put under stress.

Disk performance. In general, a high-performance disk subsystem allows for a faster rate of
certificate enrollment. However, key length impacts disk performance. With a shorter CA key
length, the CPU has fewer calculations to perform and, therefore, it can complete a large
number of operations. With longer CA keys, the CPU needs more time to issue a certificate and
this results in a smaller number of disk input/output (IO) operations per time interval.

Number of disks. You can improve performance slightly by using separate physical disks for
the database and log files. You can improve performance significantly by placing the database
and log files on RAID or striped disk sets. In general, the drive that contains the certification
authority database is used more than the drive hosting the log file.
Note
Using separate logical disks does not provide any performance
advantages.

Amount of memory. The amount of memory that you use does not have a significant impact
on CA performance, but must meet general system requirements

Hard disk capacity. Certificate key length does not affect the size of an individual database
record. Therefore, the size of the CA database increases linearly as more records are added. In
addition, the higher the capacity of the hard disk, the greater the number of certificates that a
CA can issue.
Tip
Plan for your hard disk requirements to grow over time. In general, every
certificate that you issue requires 17 kilobytes (KB) in the database and
15 KB in the log file.
Designing Your CA Infrastructure 751
The type of hardware that your clients use can also impact performance. When you are selecting or evaluating
the capabilities of the hardware for your CA clients, consider the following:

Key length. The greater the key length of a requested certificate, the greater the impact on the
CPU of the server hosting the CA.

Network bandwidth. Assuming that the CA is not serving in more than one capacity, a 100megabit network connection is sufficient to prevent performance bottlenecks.
As you plan your CA infrastructure, you also need to ensure that your design is flexible enough to accommodate
changes to your organization. For example, you need to be able to accommodate:

Changes in the functionality that you require from your public key infrastructure.

Growth or decline in demand for certificates.

The addition or removal of locations that CAs need to serve.

The effect of revocation. Revoking large numbers of certificates can take several minutes and
increase the size of the database.
Using multiple CAs is an excellent way to ensure that your infrastructure can support enterprise scalability. The
use of multiple CAs, even for organizations with minimal certificate requirements, provides the following
advantages:

Greater reliability. If you need to take an individual CA offline for maintenance or backup,
another CA can service its requests.

Scalability. Increases in demand, either from new users or from new applications, can be
accommodated more easily.

Distributed administration. Many organizations distribute security administration across a
number of IT administrators to prevent one individual or team from controlling the entire
security technology infrastructure of the organization.

Improved availability. Users in remote offices can access a CA that is local to them rather
than accessing a CA across slow Wide Area Network (WAN) links.
Note
You can reorganize your CA infrastructure by adding or removing a CA
and its associated users from a CA hierarchy. However, you cannot
move a subset of users on a single CA to a new CA without forcing the
users to re-enroll with the new CA.
752 Chapter 16 Designing a Public Key Infrastructure
Integrating the Active Directory Infrastructure
Your CA infrastructure is independent of the domain structure of your Windows environment. For example, one
CA can service requests from multiple domains, or multiple CAs can serve a single domain. CA hierarchies
with stand-alone CAs can even span multiple Active Directory forests.
If possible, take your PKI requirements into account when you design your Active Directory infrastructure.
Active Directory and PKI technology impact each other in the following ways:

Enterprise CAs are bound to the forest. As a result, enterprise CAs can only issue certificates
to computers and users in the forest. In addition, you cannot change the name of the CA or the
computer after it is deployed. Moreover, the computer cannot be removed from the domain or
forest. Because much of the security of an organization is established at the forest level, the
security of an enterprise CA is connected to the forest in which it is located. For this reason,
each forest requires its own enterprise CAs.
Note
If certificates from stand-alone CAs are published to Active Directory,
these stand-alone CAs cannot be renamed or removed from the forest
without their certificates becoming invalid. However, you can rename
stand-alone CAs that belong to workgroups without impacting the status
of their certificates.

Certificate storage affects the size of your directory. If you store certificates in user objects,
the size of the directory increases and replication time might increase. Because the
userCertificate attribute contains data about all the user certificates, the addition of a certificate
to that multivalued attribute causes Active Directory to replicate attribute data for all
certificates.

Complications such as failure to recognize the user or the certificate can occur. This
happens if you do not apply a consistent naming structure for both your distinguished names
(also known as DNs) and your user principal names (UPNs).

Enterprise CAs rely on the existence of an Active Directory schema. If your schema is
based on Windows 2000 Active Directory, you might need to extend it to support Windows
Server 2003 Certificate Services functionality, such as version 2 certificate templates. For more
information about version 2 templates, see “Selecting Certificate Templates” later in this
chapter.
For certificates with a long life, the availability of the CA services themselves is much less important than the
availability of the directory that holds the certificates and the certificate revocation lists. If you integrate your
CAs with Active Directory, your certificates and CRLs are automatically published to the directory and
replicated throughout the forest as part of the global catalog.
Designing Your CA Infrastructure 753
Note
If you use Active Directory to publish and replicate information about
CRLs throughout your organization, be sure to review Active Directory
replication schedules and policies in order to ensure that this data is
distributed in a timely manner.
Windows Server 2003 Certificate Services functions whether Active Directory in your organization is based on
Windows 2000 or Windows Server 2003. It also functions if your organization is operating in mixed mode.
Configuring Public Key Group Policy
If you have an Active Directory environment, Group Policy allows you to link certificate services to groups of
users or computers based on their domains or organizational unit membership. You must configure public key
Group Policy in order to perform the following tasks:

Add trusted root certificates for groups of computers. You can define the following:

Which root CAs users can trust when verifying certificates.

Whether users are allowed to trust additional CAs of their own choosing.

The purposes for which certificates issued by each CA can be used.
Enterprise root CAs within your domain forest are automatically added to these policies.

Distribute certificate trust lists for computers and users. For more information about
certificate trust lists, see “Evaluating Factors That Affect Extended Trusts” later in this chapter.

Enable autoenrollment. For more information about autoenrollment, see “Selecting a
Certificate Enrollment and Renewal Method” later in this chapter.

Designate EFS recovery agent accounts. You can define an EFS recovery policy within the
scope of the policy object. If a recovery policy is defined, it is populated with the certificates of
the recovery agents.
In many organizations, users and computers are already organized into domains and organizational units that are
based on the organization structure, location, and job function. If your organization has not already created an
Active Directory domain structure, the best way for you to take advantage of Public Key Group Policy is to
define the groups of users and computers that will use your Certificate Services and communicate this
information to the Active Directory and Group Policy administrators, so that they can address your public key
requirements in their planning.
For more information about how to plan for the use of Group Policy, see “Designing a Resource Authorization
Strategy” in this book.
754 Chapter 16 Designing a Public Key Infrastructure
Defining PKI Management and Delegation
It is important to define a PKI management model early in the process of designing your CA infrastructure. This
PKI management model must complement your existing security management delegation plan and help you to
meet Common Criteria requirements for role separation. To ensure that a single individual cannot compromise
PKI services, it is best to distribute management roles across different individuals in your organization. This
involves deciding which individuals are to perform each of the following tasks:

Creating or modifying existing CAs

Managing certificate templates

Issuing cross certificates

Issuing or revoking user certificates

Configuring and viewing audit logs
You can use discretionary access control lists (DACLs) to manage CA permissions and delegate CA
management tasks.
Windows Server 2003 includes the following CA management roles:

Service Manager. Configures and manages Certificate Services for local users, assigns
certificate managers, and renews CA certificates.

Certificate Manager. Issues and revokes certificates.

Auditor. Audits the actions of local administrators, service managers, and certificate managers.
The extent to which you separate roles depends on the level of security that you require for a particular service.
Assign the fewest possible rights to users in order to achieve the greatest level of security. For example, you can
adopt the following rules:

No user can assume the roles of both CA Administrator and Certificate Manager.

No user can assume the roles of both User Manager and Certificate Manager.
If you need stricter guidelines, you can include the following:

No user can assume the roles of both Auditor and Certificate Manager.
To facilitate this delegation process, you need to understand how various PKI administrative roles align with
Windows Server 2003 administrative roles. Table 15.1 lists the Windows Server 2003 administrative roles that
correspond to each PKI administrative role.
Designing Your CA Infrastructure 755
Table 15.1 PKI Administrative Roles and Their Corresponding Windows Server 2003
Administrative Roles
PKI Administrative
Role
Windows Server 2003
Administrative Role
Description
PKI Administrator
Configures, maintains, and
renews the CA.
User
Backup Operator
Performs system backup
and recovery.
Backup Operator on the
server on which the CA is
running
Audit Manager
Configures, views, and
maintains audit logs.
Local Administrator on
the server on which the
CA is running
Key Recovery
Manager
Requests retrieval of a
private key stored by the
service.
User
Certificate Manager
Approves certificate
enrollment and revocation
requests.
User
User Manager
Manages users and their
associated information.
Account Operators (or
person delegated to
create user accounts in
Active Directory)
Enrollee
Requests certificates form
the CA
Authenticated Users
Table 15.2 lists the actions that each PKI administrative role can perform.
Table 15.2 Actions Performed By PKI Administrative Roles
Action
Enroll
ee
CA
Admin
Certificate
Manager
Audit
Manager
Backup
Operator
Local
Server
Admin
Install a CA
Configure a
CA
Policy and
exit module
configuratio
n
Stop/start
service
Change
configuratio
n
Assign user
roles
(continued)
756 Chapter 16 Designing a Public Key Infrastructure
Table 15.2 Actions Performed By PKI Administrative Roles (continued)
Action
Enroll
ee
CA
Admin
Certificate
Manager
Audit
Manager
Backup
Operator
Local
Server
Admin
Establish
user
accounts
Maintain
user
accounts
Configure
profiles
Renew CA
keys
Define key
recovery
agent(s)
Define
officer roles
Enable role
separation
Issue/Appro
ve
certificates
Deny
certificates
Revoke
certificates
Unrevoke
certificates
Renew
certificates
Enable,
publish, or
configure
CRL
schedule
Configure
audit
parameters
Audit logs
Back up
system
Restore
system
(continued)
Designing Your CA Infrastructure 757
Table 15.2 Actions Performed By PKI Administrative Roles (continued)
Action
Enroll
ee
CA
Admin
Certificate
Manager
Audit
Manager
Backup
Operator
Local
Server
Admin
Read CA
properties,
CRL
Request
certificate
Read CA
database
Read CA
configuratio
n
information
Read
issued,
Revoked,
pending
certificates
Note
As you delegate roles and responsibilities, be sure to keep track of the
permissions that you configure on certificate directories. Distributing
access to a PKI to a number of individuals creates greater security risks.
Defining CA Types and Roles
To plan your CA infrastructure, you need to understand the different types of CAs available with Windows
Server 2003 and the roles that they can play. Windows Server 2003 Certificate Services supports the following
two types of CAs:

Enterprise

Stand-alone
Enterprise and stand-alone 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 a policy CA) 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.
758 Chapter 16 Designing a Public Key Infrastructure
Enterprise vs. Stand-Alone 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 only available 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.
Stand-alone CAs do not require Active Directory and do not use certificate templates. If you use stand-alone
CAs, all information about the requested certificate type must be included in the certificate request. By default,
all certificate requests submitted to stand-alone CAs are held in a pending queue until a CA administrator
approves them. You can configure stand-alone 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 stand-alone CAs with automatic issuance enables you to issue
certificates at a faster rate than you can by using enterprise CAs. However, unless you are using autoissuance,
using stand-alone 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 2000 or Windows Server 2003 accounts, and when the volume of certificates to be issued and
managed is relatively low.
You must use stand-alone CAs to issue certificates when you are using a third-party directory service or when
Active Directory is not available.
Note
You can use both enterprise and stand-alone certification authorities in
your organization.
Table 15.3 lists the options that each type of CA supports.
Designing Your CA Infrastructure 759
Table 15.3 Options for Enterprise vs. Stand-Alone CAs
Option
Enterprise
CA
Stand-alone
CA
Publish certificates in Active Directory and use
Active Directory to validate certificate requests.
Take the CA offline.
Configure the CA to issue certificates
automatically.
Allow administrators to approve certificate
requests manually.
Use certificate templates.
Authenticate requests to Active Directory.
Root CAs
A root CA is the CA that is at the top of a certification hierarchy and must be trusted unconditionally by clients
in your organization. All certificate chains terminate at a root CA. Whether you use enterprise or stand-alone
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. Windows Server 2003 only allows you to designate
a self-signed CA as a root CA. 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 upon which you base your certification authority 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 certification authority 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 have been 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.
For more information about using a third-party CA as the root CA, see “Extending Your CA Infrastructure”
later in this chapter. For more information about disconnecting CAs from the network, see “Using Offline CAs”
later in this chapter.
760 Chapter 16 Designing a Public Key Infrastructure
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 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 geographical location of the CA to distinguish different end-entity populations. A
policy CA can be online or offline.
Note
Most organizations use one root CA and two policy CAs — one to
support internal users, the second 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.
Using Offline CAs
Securing your CA hierarchy is a critical task. If an intruder can gain access to a CA, either physically or by
means of the network, he or she might retrieve the private key of the CA 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.
Designing Your CA Infrastructure 761
To ensure the reliability of your CA infrastructure, specify that any non-issuing 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 stand-alone Windows 2000 or Windows Server 2003 and configuring it
as a stand-alone CA.

By physically removing the computer from the network.

By shutting down the CA service.

By shutting down the computer.
Caution
Shutting down a CA computer prevents auditing from taking place.
Therefore, if a CA computer is compromised, a hardware failure does not
generate an audit notification.
Make sure that you keep CAs in a secure area with limited access.
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.
Because they can operate offline, it is a good idea to use stand-alone CAs for root and intermediate CAs.
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.
Important
In general, the CRL and Authority Information Access (AIA) paths of an
offline CA have to be modified before the first certificate is issued
because the CRL and AIA paths, by default, point to the local http server
and the local file system. Because the CA is offline and not accessible to
other members of a network, the functionality of the CA must be
separated from CRL and AIA distribution.
762 Chapter 16 Designing a Public Key Infrastructure
Because offline CAs process a small number of certificate requests at infrequent intervals, the administrative
costs of maintaining offline CAs is low.
The client-side certificate validation process is not affected when a CA is offline because the client verifies the
validity of the certificate by checking the certificate chain and the CRL. You cannot store both sources on the
offline CA because clients need access to the CRL and AIA paths that are part of the certificate.
Important
Taking a root CA offline does not reduce its importance, so be sure to
use reliable hardware for offline root CAs. A hardware failure on an
offline CA prevents you from publishing CRLs or issuing certificates to
new subordinate CAs.
Using Hardware CSPs
Hardware CSPs can support a wide range of cryptographic operations and technologies. Keys stored in tamperresistant hardware crypto-devices are more secure than keys stored on local computer hard disks. Therefore,
keys stored in hardware cryptographic devices can have key lifetimes that are longer than keys stored by
software CSPs on hard disks.
Note
Another advantage to using hardware CSPs is that the key material is
kept outside the memory of the computer and within the hardware
device. This makes it impossible to access the key of the CA by means
of a memory dump.
If you determine that a hardware CSP is too costly, consider using smart cards for key storage. When you store
cryptographic keys on a smart card, no one in your organization can issue or revoke certificates without the
appropriate smart card together with the correct personal identification number (PIN).
If you choose to use hardware cryptographic service providers for CA private key storage, you must ensure that
the hardware device is physically secured, or at least back up the operator cards or tokens. You might, for
example, keep it in a highly secured area in the computer room of your company, or lock it in a safe.
Designing Your CA Infrastructure 763
Determining 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:

Do you require more than one CA? If you are only supporting 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 CAs.

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.
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. For more information about using
more than one root CA, see “Extending Your CA Infrastructure” later in this chapter.

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.
764 Chapter 16 Designing a Public Key Infrastructure

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.
Note
You cannot install more than one CA on a server.
Selecting a Trust Model
The Windows Server 2003 PKI is based on a hierarchical CA model that is comprised of well-defined trust and
CA naming standards. This type of CA trust model provides scalability, easy administration, and consistency
with a growing number of third-party CA products.
In a hierarchical CA model, multiple CAs are organized into clearly defined parent-child relationships. Child
CAs are certified by parent CA-issued certificates, which bind the public key of a CA to its identity.
With a hierarchical CA model, you minimize the number of root CAs that you need in order to verify
certificates. At the same time, hierarchical CAs allow you great flexibility in the number of certificate-issuing
subordinate CAs that you can use.
The basic types of CA trust hierarchies include:

Rooted trust model. In a rooted trust model, a CA is either a root or a subordinate, and you can
use offline root CAs for the highest level of security.

Network (or cross-certification) trust model. In a network trust model, every CA is both a
root and a subordinate.

Hybrid trust model. Hybrid trust models combine elements of both the rooted and network
trust models.
Your PKI trust hierarchy must be based on one of these three trust models.
Designing Your CA Infrastructure 765
Whether you choose to apply a rooted, network, or hybrid trust model to your CA infrastructure, you need to
base your trust structure on the business requirements of your organization and on the way your organization
delegates responsibility for IT administration. In this way, your trust model might be based on one or a
combination of the following:

Quality of identification

Organizational structure

User location
Rooted Trust Model
In a rooted trust model, the root CA is the trust anchor and has a self-signed certificate. The root CA issues a
certificate to all direct subordinate CAs, if needed, which, in turn issue certificates to their subordinate CAs. A
subordinate CA is trusted cryptographically, based on the signature of its parent.
Figure 15.6 illustrates the rooted trust model.
Figure 15.6 Rooted Trust Model
766 Chapter 16 Designing a Public Key Infrastructure
Numerous products and services offered by major software vendors, including Microsoft, support rooted trust
hierarchies. You can add a new CA to a rooted trust hierarchy by enrolling it to a CA anywhere in the trust
hierarchy. If you create a new trust hierarchy, it only needs to trust the root CA of the new PKI in order to trust
all the subordinate CAs in the new hierarchy.
A rooted trust model enables you to compartmentalize risks, management, and certificate processing. Rooted
trust hierarchies are more scalable and easier to administer than other hierarchies because each CA serves a
single role within the hierarchy and is not operationally dependent on other CAs.
Any CA in a rooted trust hierarchy is either a root or a subordinate but never both. Each CA is responsible for
processing requests and issuing certificates signed by its own key; each CA is responsible for revoking
certificates and publishing CRLs to accessible locations; and each CA can be managed separately by different
personnel in different parts of an organization.
Because CAs in a rooted trust hierarchy can be online or offline, rooted trust hierarchies allow great flexibility
in the ways in which you can deploy and manage a PKI. You can protect the private key of a CA by taking the
CA offline. Because offline CAs are typically the root and/or policy CAs that only issue certificates to other
CAs, taking the CA offline does not impact other parts of the hierarchy.
Because most protocols deliver a chain of certificates that terminates in a trusted root CA, rooted trust
hierarchies provide a straightforward means by which CAs can determine whether a certificate can be trusted.
Note
If the certificate of a root CA expires, all certificates that are issued by the
root CA or by its subordinate CAs also expire. For more information
about managing certificate lifetimes, see “Selecting Certificate Security
Options” later in this chapter.
Network Trust Model
If your organization has multiple, distributed IT departments, you might not be able to establish a single, trusted
root. In this situation, you can implement a network trust model, in which all CAs are self-signed and trust
relationships between CAs are based on cross-certificates. Cross-certificates are special certificates that are used
to establish complete or qualified one-way trusts between otherwise unrelated CAs. For more information about
the use of cross-certificates and how to manage cross-certified relationships, see “Selecting an Extended CA
Infrastructure Configuration” later in this chapter.
A network trust model can be viewed as a hierarchy because a cross-certificate is essentially the same as a
subordinate CA certificate in a rooted trust model. The cross-certifying CA is the issuer and the cross-certified
CA is the subject.
Designing Your CA Infrastructure 767
Because a cross-certificate is a logical subordination of one CA to another CA, a network trust model is in effect
a hierarchy, with the added property that a root CA is also a subordinate CA in the cross-certifying PKI.
Unlike the rooted trust model, in which a global directory such as Active Directory is not required, a global
directory is essential in a network trust hierarchy. Without a global directory, cross-certificates need to be
preinstalled on all clients of the PKI; otherwise there is no way to discover them.
Figure 15.7 shows an example of a network trust model.
Figure 15.7 Network Trust Model
The trusts in Figure 15.7 are bidirectional, which means that CA1 issued a cross-certificate of trust to CA2 and
CA2 issued a cross-certificate of trust to CA1. It is also possible to rescind trust for a CA by revoking its crosscertificate.
Cross-certification does not need to be bidirectional, and a cross-certifying CA does not need the cooperation of
the CA being certified. For example, CA1 can cross certify CA2, without CA2 cross certifying CA1. In such a
case, clients of CA1 trust CA2 and CA3, while clients of CA2 and CA3 do not trust CA1. To do this, CA1
creates a cross-certificate without the knowledge of CA2, because all that CA1 needs is the public key
certificate of CA2. This is known as unilateral cross-certification, where one CA cross-certifies another CA but
not the reverse.
Bidirectional cross-certificates are usually preferred, although with this model you need to manage a greater
number of cross-relationships as the number of cross-certificates increases.
Full trust between cross-certified CAs also means that the client trusts all certificates issued by the other CA,
regardless of the purpose of the certificate. In a native Windows Server 2003 environment, however, you can
filter by certificate types. You can also limit trust between CAs by means of qualified subordination, which can
be implemented in the form of name constraints, policy constraints, policy mapping, and path constraints. For
more information about these methods, see “Extending Your CA Infrastructure” later in this chapter.
768 Chapter 16 Designing a Public Key Infrastructure
Cross-certification enables you to create bridges between separate PKIs without either PKI being directly
subordinate to the other. Because cross-certification is an indirect subordination of one PKI to another, the trust
point does not change relative to either PKI. In fact, bidirectional cross-certification models the way in which
companies form relationships; that is, each side participates in establishing the relationship. A network trust
model, however, is much more difficult to maintain and troubleshoot than a rooted trust model.
Note
Use a network trust model only in conjunction with name constraints. For
more information about name constraints, see “Name Constraints” later
in this chapter.
Hybrid Trust Model
Some organizations might find a pure rooted trust model too restrictive, because no single CA can serve as the
root for all other CAs. At the same time, a pure network model can become prohibitively complex if too many
different CAs are involved. If you use a hybrid approach, however, you can cross-certify only certain CAs and
thus use the benefits of both the rooted and network trust models.
Trust Hierarchy Based on Quality of Identification
A trust hierarchy based on quality of identification enables an organization to configure CAs to issue certificates
to specific groups of users. This type of trust hierarchy is ideal for organizations in which different identification
and authentication requirements are applied to different groups of users, computers, and activities.
For example, an organization requires employees to appear in person to provide identification such as a driver’s
license or passport to a security officer, who checks an employee database to ensure that the individual is
authorized, before they can receive appropriate credentials. However, because computers cannot assert an
identity, managers in the organization are responsible for ensuring that computer names are correct and that
computers are authorized to have a certificate. Because the organization requires CAs for employee certificates
and computer certificates and each requires a different form of identification, the organization chooses to create
a trust hierarchy based on quality of identification.
In a trust hierarchy based on quality of identification, the CAs subordinate to the root CA are organized
according to the quality of identification required for the certificate to be issued. The subordinate CAs use
certificates signed by the root CA in order to issue certificates to users, computers, services, or another CA.
Designing Your CA Infrastructure 769
A typical CA hierarchy based on quality of identification includes two or three issuing CAs for each of the
following:

Employee certificates

Computer certificates

Contractor certificates, if applicable. These certificates might require the same identification
that employee certificates require, but contain an issuer statement stating that the individual is
not a full-time employee.
Trust Hierarchy Based on Organizational Structure
Although a two- or three- tier trust hierarchy based on the quality of identification is sufficient for most
organizations, some organizations might need to deploy a three-tier CA trust hierarchy based on the
administrative structure of the organization.
In a trust hierarchy based on organizational structure, issuing CAs are configured to support different
organizational divisions, such as permanent employees and contractors. The issuing policy, for example, might
be based on the organization of user accounts, so that stronger security measures are applied to independent
contractors, temporary employees, or external business partners.
Figure 15.8 shows a rooted trust hierarchy based on organizational structure.
Figure 15.8 Rooted Trust Hierarchy Based on Organizational Structure
770 Chapter 16 Designing a Public Key Infrastructure
Design your trust hierarchy according to organizational structure if your certificate requirements vary according
to organizational units; for example, all employees receive certain certificates, all partners receive a different set
of certificates, and so on. Do not use this type of design if you can define too many different groups of
requirements; in this case, a trust hierarchy based on certificate usage is more appropriate.
Trust Hierarchy Based on Location
Some organizations might find it necessary to implement a three-tier trust hierarchy based on location. This
configuration allows regional administrators to manage the certificate requirements for users in a defined area
such as a continent, country/region, or locale. Figure 15.9 shows a CA trust hierarchy based on location.
Figure 15.9 Trust Hierarchy Based on Location
Depending on the nature of your business, you might need to issue certificates based on location to comply with
legal requirements — for example, if you perform work for a government agency — or other local regulations.
Designing Your CA Infrastructure 771
Defining CA Roles in the Trust Hierarchy
After you have designed the trust hierarchy for your organization, you must define the roles for your root,
policy, and issuing CAs.
The root CA, for example, might be used to sign, certify, and/or revoke subordinate CAs. Intermediate or policy
CAs might serve internal or external customers, or, in larger organizations, might serve more specialized
functions or locations. Issuing CAs and RAs might be defined according to the clients that they serve or the
certificates that they issue.
You might choose to select some or all of the following roles for your intermediate and issuing CAs:

Intermediate CA. Certifies subordinate CAs to issue certificates.

Rudimentary CA. Issues certificates for the most basic operations, such as user authentication
without an identity check.
Note
Stand-alone CAs are primarily used in intermediate and rudimentary
roles.

Basic security CA. Issues certificates, based on an Active Directory identity check, to users
and computers that do not have special security requirements.

Medium security CA. Issues certificates to users and computers that meet special security
requirements and whose identities are validated in Active Directory.

High security CA. Issues certificates to users or computers that meet especially high security
requirements, and whose identities must be verified by means of the examination of physical
credentials.
Note
Enterprise CAs are primarily used for basic, medium, and high security
roles.
Keep the following considerations in mind as you define CA roles:

Use a three-tier hierarchy with policy CAs only if necessary.

Third-party CAs can form all or part of a Windows Server 2003 CA trust hierarchy.

Some third-party products might require other CA trust models that might not be interoperable
with rooted CA hierarchies. Windows Server 2003 and most commercial CAs support rooted
CA hierarchies.
772 Chapter 16 Designing a Public Key Infrastructure
Establishing a CA Naming Convention
Before you configure CAs in your organization, you must establish a CA naming convention. Names for CAs
cannot be more than 64 characters in length. You can create a name using any Unicode character, but you might
want to use the ANSI character set if interoperability is a concern. The CA name does not have to be identical to
the name of the computer.
The name that you specify when you configure a server to be a CA becomes, in Active Directory, the common
name of the CA, and is reflected in every certificate that the CA issues. For this reason, it is important that you
do not use the fully qualified domain name (FQDN) for the common name of the CA. This way, malicious users
who obtain a copy of a certificate cannot identify and use the fully qualified domain name of the CA to create a
potential security vulnerability.
Note
You cannot change the name of a server after Certificate Services has
been installed without invalidating all the certificates issued by the CA.
To change the server name after Certificate Services has been installed,
you must uninstall the CA, change the name of the server, reinstall the
CA, and reissue all the certificates issued by the CA. You do not have to
reinstall a CA if you rename a domain; however, you will have to
reconfigure the CA to support the name change.
Selecting a CA Database Location
When you install a CA in your organization, you must specify a location for the database and log files of the
CA. You must also indicate whether you want to store the configuration information for the CA. Storing the CA
configuration information is helpful for backing up and, if necessary, restoring your CA.
Designing Your CA Infrastructure 773
You can choose to copy the naming information and the certificate for the CA to the file system (the
configuration directory is automatically shared by means of a share named certconfig).
Note
You can change the location of the database and log files manually at a
later time. However, you cannot perform this task by using the user
interface.
Windows Server 2003 uses the JET database engine for the CA database. As with any JET database, it is a good
idea to place the database and its log files on different physical disk drives, in order to improve fault tolerance
and performance. By default, all these files are located in the certlog subdirectory of the system directory.
Tip
Use a separate RAID for both the database and log files for the highest
level of fault tolerance between backup intervals.
The CA database consists of the files listed in Table 15.4.
Table 15.4 CA Database Files
Database file
Purpose
<CA name>.edb
The CA store
edb.log
The transaction log file for the CA store
res1.log
Reservation log file to store transactions if disk space is
exhausted
res2.log
Reservation log file to store transactions if disk space is
exhausted
edb.chk
Database checkpoint file
Note
You can determine the location of the database files for a CA by typing
certutil -databaselocations at a command prompt or by looking in
the Certificate Services snap-in user interface.
774 Chapter 16 Designing a Public Key Infrastructure
Example: Designing a CA Infrastructure
After an organization defines its certificate requirements, it creates a linked hierarchy of certification authorities
to enable it to distribute certificates as needed, and to validate or reject certificates as appropriate.
In creating this CA infrastructure, the organization takes the following elements into account:

The security administration model of the organization. For example, security administration
is managed centrally from the headquarters of the organization, but individual business units
create and support their own security requirements as needed for individual projects and
business relationships. Some units operate autonomously, but report back to corporate IT.

The Active Directory infrastructure of the organization. Because the organization has a
single-forest logical structure, the CA infrastructure design is simple. The existing single-forest
structure allows them to set up CAs, based on geography and bandwidth, to serve clients in
multiple domains. For example, one or more common CAs support clients in offices on
opposite coasts.

Potential use of a third-party CA. The organization is concerned about IT costs and also
prefers to manage its own security infrastructure. It addresses both concerns by creating and
administering its own CA infrastructure. When joint venture business partners deploy PKIs, it is
possible to integrate the two CA infrastructures without having to rely on a third-party CA.
For more information about using third-party CAs to extend the CA infrastructure, see
“Extending Your CA Infrastructure” later in this chapter.
Although the organization deploys Active Directory, it places a stand-alone root CA in a workgroup, rather than
in the domain, for increased security. Also, it keeps this root CA offline and in a secure location that can only be
accessed by an administrator who is authenticated by means of a smart card.
Directly below the root CA, the organization adds three policy CAs. One CA signs all certificates that have been
issued to meet the high security standards of the organization, including software code signing, smart card
logon, and Internet authentication certificates. The second CA signs all certificates that have been issued to meet
the medium security standards of the organization, such as e-mail and EFS certificates. The third signs
certificates for the CAs that issue certificates to external partners. These are also offline.
Figure 15.10 shows the CA infrastructure for the organization.
Designing Your CA Infrastructure 775
Figure 15.10 Example of a CA Infrastructure of an Organization
Table 15.5 summarizes the configuration of these CAs.
776 Chapter 16 Designing a Public Key Infrastructure
Table 15.5 CA Configuration
CA
Name
State
Role
Domain
Root CA
RtCA01
Offline
Stand-alone
None
Internal medium security policy
PolCA01
Offline
Stand-alone
None
Internal high security policy
PolCA02
Offline
Stand-alone
None
External high security policy
PolCA03
Offline
Stand-alone
None
Internal medium security issuing IsCA01
1
Online
Member
server
Corp
Internal medium security issuing CA06
2
Online
Member
server
Corp
Internal medium security issuing CA07
3
Online
Member
server
Corp
Internal high security issuing 2
CA08
Online
Member
server
Corp
Internal high security issuing 3
CA09
Online
Member
server
Corp
External high security issuing 1
CA01
Online
Member
server
Corp
Extending Your CA Infrastructure
You can use a rooted CA hierarchy to enable many PKI applications. However, you might find that your PKI
needs are too complex to be met by a simple rooted hierarchy. For example, you might need to extend your CA
infrastructure to accommodate joint ventures, mergers, geographic, or other business requirements.
Figure 15.11 shows the steps involved in extending your CA infrastructure.
Extending Your CA Infrastructure 777
Figure 15.11 Extending Your CA Infrastructure
778 Chapter 16 Designing a Public Key Infrastructure
Evaluating Factors That Affect Extended
Trusts
Extending and refining your trust hierarchy is a critical step in the process of creating a secure PKI, and it
involves complex decisions. It is important to define appropriate and inappropriate uses for certificates in your
organization before you extend your CA infrastructure. Without proper planning, you might grant business
partners and users more trust than you intend.
If you want to link your established Windows Server 2003 trust hierarchy with an external PKI, a number of
factors can impact interoperability. Before you extend your CA infrastructure, evaluate the following features
and standards in both PKIs:

Standards support

Algorithm support

CRL distribution points

Authority information access (AIA)

Authority key identifier (AKI)

Certificate extensions

Key length

Extended key usage (EKU)

Directory integration
Determine whether any other PKIs with which you need to establish trust support these features and standards,
and how you can accommodate differences. Addressing these issues when you design your PKI can help you to
ensure the extensibility and interoperability of your PKI environment.
Standards Support
A number of technical standards provide a basis for interoperability between Windows Server 2003 and other
PKI applications. To promote third-party interoperability with the Windows Server 2003 API, Microsoft
supports the following standards:

PKIX. Defines interoperable PKI standards for the Internet.

X.509. Describes the standard format of a certificate.

PKCS. Provides a standard for public key message exchanges.

TLS. Provides a secure and authenticated channel between hosts on the Internet above the
transport layer.
Extending Your CA Infrastructure 779

S/MIME. Serves as a standard for secure e-mail across the Internet.

Kerberos authentication protocol. Provides a symmetric key framework for authentication in
large networks.

PC/SC. Serves as a standard for integrating smart cards and smart card readers.
Most PKI vendors have adopted many or all of these PKI standards. Different vendors, however, can implement
the standards in different ways. While it might be possible to link external PKI implementations to yours, this
might involve making some changes to your existing design. For this reason, it is strongly recommended that
you evaluate the external PKI to determine whether it meets all your critical requirements.
Algorithm Support
It is important for a PKI to interoperate with many different hardware vendors and to provide a hardware
abstraction layer so that applications do not have to know where keys are stored.
Windows Server 2003 uses CryptoAPI to abstract hardware-based key management from applications, and it
uses the PC/SC standard instead of PKCS#11 to communicate with smart cards and readers. Many third-party
CAs have their own cryptographic APIs and use PKCS#11 to interface to hardware tokens such as smart cards.
Because Windows 2000 and Windows Server 2003 require hardware devices to support Plug and Play and
power management features, and PC/SC includes support for these ease-of-use features, Windows Server 2003
does not support PKCS#11.
Note
The Windows Server 2003 PKI can use third-party CSPs, and can enroll
users for certificates that have keys that were generated by third-party
CSPs.
CRL Distribution Points
The CRL distribution point (CDP) extension in a certificate identifies how revocation information for the
certificate can be obtained. If a CRL distribution point is not always available, certificate chain building can be
delayed, causing inconvenience for the user. If a CRL is not available at the distribution point that has been
specified in the certificate, CRL retrieval might even fail and the certificate will be considered invalid.
Tip
Publish CDP URLs for all CAs so that users who need to know whether
or not issued certificates have been revoked can find that information.
780 Chapter 16 Designing a Public Key Infrastructure
You need to compare any third-party CRL support with the Windows Server 2003 CRL support. For example,
the third-party PKIs might not support the Windows Server 2003 CRL process, which includes the use of delta
CRLs. Conversely, the Windows Server 2003 PKI might not support the methods of the third-party PKI for
processing CRL information. Your extended PKI deployment plan needs to account for these differences.
In general, follow these guidelines when you configure the CDP extension:

If available, use Active Directory to support internal corporate clients.

Use an externally referenced and trusted Lightweight Directory Access Protocol (LDAP)
directory to support business partners and customers.

Consider using HTTP distribution points, especially for certificates that will be used externally.
Authority Information Access
The Authority Information Access (AIA) extension is a pointer to the most currently published CA certificate of
a CA. The AIA extension helps clients find CA certificates dynamically during chain building. The Windows
Server 2003 PKI uses this extension to assist in building trust chains to validate certificates.
It is recommended that you publish AIA URLs for all PKIs for which users might need to retrieve up-to-date
CA certificates. Whether a CA is online or offline, and whether it is a root, intermediate, or issuing CA, using
the AIA extension minimizes the likelihood that PKI clients will encounter unverified certificate chains or
revocation data. Such encounters can result in unsuccessful VPN connections, failed smart card logons, or
unverified e-mail signatures.
Some third-party PKIs do not provide the AIA extension. In this case, parent certificates need to be distributed
to domain clients so that the certificates are available before the chain building process begins. Cross-certificates
must also be available locally on domain clients, because there is no information in a certificate specifying
where it can be found.
Authority Key Identifier
The Authority Key Identifier (AKI) extension provides a means to identify the public key of the CA that
validates the signature on a CRL. This identification is based on either the subject key identifier (SKI) or the
issuer name and serial number from the certificate issued by the CRL issuer. The AKI extension is useful in
cases when a CRL issuer has more than one signing key.
An organization that expects its PKI certificates to be used by other Windows Server 2003 PKIs must populate
the Authority Key Identifier extension with a unique key identifier and an issuer name and serial number. The
Windows Server 2003 PKI attempts to construct certificate chains by using the issuer name and serial number in
the AKI first, and then the subject key identifier.
Note
By default, Windows Server 2003 does not automatically add issuer
names and serial numbers to the AKI extension. This data must be
added manually by means of Certutil.exe, although in most cases it is not
necessary to do so.
Extending Your CA Infrastructure 781
Certificate Extensions
Not all certificate extensions are universally recognized. If a CA does not recognize a certificate extension in a
request and it has been marked critical, it rejects the certificate. Unless you intend to limit the use of the
certificate to a specific application that understands the critical extension, avoid putting critical extensions in
certificates because it limits interoperability.
Key Length
When different PKIs support different minimum and maximum key lengths, an interoperability problem results.
Be sure that your internal PKI and the external PKI support the necessary encryption keys.
Extended Key Usage
The Extended Key Usage (EKU) extension indicates the purposes for which the public key contained in the
certificate can be used. The Windows Server 2003 PKI uses the EKU extension to indicate certificates that
support special functions, such as IPSec and EFS file encryption backup. The EKU extensions of other
organizations might be used for different purposes.
Directory Integration
Windows Server 2003 PKI certificates can be published to any directory or repository, although the default CA
exit module only supports Active Directory. However, by default, a Windows Server 2003 PKI relies on Active
Directory and the LDAP for authentication, including smart card logons and certificate autoenrollment, as well
as for certificate management.
With Microsoft Certificate Services, certificates issued by a third-party CA can be associated with a Windows
Server 2003 user account stored in Active Directory. This is possible because applications such as Internet
Explorer and Internet Information Services (IIS) can be used to authenticate a user to an account stored in
Active Directory, based on the UPN name information in a certificate. The account to which the certificate maps
provides information about user access rights on the server. This is an extremely powerful feature for Webbased applications and third-party CAs because it combines strong authentication by means of public key
technology with the native authorization model of Windows Server 2003. For example, to enable extranet and
remote access scenarios without requiring the application and certificate to manage access rights, administrators
can use certificates from partner companies and map them to accounts in Active Directory by means of one-toone or many-to-one mappings.
For more information about using one-to-one and many-to-one mapping, see “Mapping Certificates to User
Accounts” later in this chapter. Also, for more information about certificate mapping, see the Microsoft
Knowledge Base link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources.
782 Chapter 16 Designing a Public Key Infrastructure
Selecting an Extended CA Infrastructure
Configuration
You can use one of three configurations to create an extended CA trust infrastructure:

Third-party root CA. Use a third-party CA as a root CA for a new extended CA hierarchy
shared between two organizations.

New root CA. Establish your own new root CA to combine separate CA hierarchies for two
organizations.

Cross-certification and qualified subordination. Keep the existing CA hierarchies separate,
but use cross-certification and qualified subordination to implement as much or as little trust as
needed between the two organizations.
There are advantages and disadvantages to each approach. If you need to extend your CA infrastructure to
include third-party PKIs, you need to evaluate the requirements of your organization to determine the method
that is most appropriate for you.
Using Third-Party Root CA Configuration
Building a new public key hierarchy from an existing third-party root CA is an appropriate solution if you want
to cross-certify with multiple business partners simultaneously. The third-party root CA is used to build a new
public key hierarchy designed specifically to serve the needs of multiple organizations. Figure 15.12 shows an
example of an extended CA infrastructure built from an existing root CA. In this example, organization A and
organization B maintain their existing PKIs and share a new PKI that serves the specific needs of their business
relationship.
Extending Your CA Infrastructure 783
Figure 15.12 Extended CA Infrastructure Built from an Existing Third-Party Root CA
The advantage to this approach is that you can off-load responsibility for maintaining the new infrastructure to
an organization that specializes in this type of service. The intermediate and issuing CAs that you create on your
side of the shared infrastructure can be administered separately from your existing internal PKI. In this way, the
functions of the external PKI cannot compromise the internal PKI, and the organizations that share the extended
infrastructure do not have to share transitive trust between their existing PKIs.
The disadvantage to this approach is that it involves the creation of a new, separate infrastructure with its own
administrative requirements. Although much of this administration is off-loaded to a third party, this approach
involves considerable additional cost. The costs can multiply each time you add a new business relationship that
requires a separate shared PKI infrastructure.
You need to plan for an extended PKI based on an existing root CA in the same way that you plan for your
existing internal PKI, in that you must decide where to locate intermediate and issuing CAs, how to manage
them, how to protect them, and so on. In this case, you must work with your business partner and the root CA
provider to make these decisions.
784 Chapter 16 Designing a Public Key Infrastructure
Third-party CAs can form all or part of a CA trust hierarchy. To ensure that third-party CAs provide
interoperability with your existing infrastructure, test all proposed interoperability scenarios in your lab.
Note
Some PKIs require CA trust models that are not interoperable with
rooted CA hierarchies. Windows 2000 and most commercial CAs support
rooted CA hierarchies.
Adding Trusted Root Certificates to Group Policy
If a stand-alone CA is not a domain member buts runs as a member of a workgroup, the root CA certificate must
be added manually to the domain Group Policy. In contrast, when you install a stand-alone root CA on a
computer that is a domain member, the certificate of the CA is added to the Trusted Root Certification
Authorities Group Policy for the domain.
You can also add certificates for other root CAs to Trusted Root Certification Authorities Group Policy
manually. These root CAs then become trusted root CAs for the computers within the scope of the Group
Policy. For example, if you want to use a third-party CA as a root CA in a certification hierarchy, you must add
the certificate for the third-party CA to the Trusted Root Certification Authorities Group Policy.
Using a New Root CA Configuration
You or your partner organization can create a new root CA to establish an extended CA infrastructure that
supports your business requirements. The structure of this extended CA infrastructure is similar to that of an
extended infrastructure based on a third-party rood CA. With a new root CA configuration, however, you and
your partner organization must create a security management infrastructure, and must take responsibility for
administering and maintaining the extended PKI. If one organization assumes this responsibility, the other
organization must trust that its partner will protect the security interests of both parties.
This option can be more cost-effective than using a third-party root CA. In addition, you can use Windows
Update to distribute new root certificates, improving reliability and decreasing costs.
The planning considerations for a new root CA–based extended infrastructure are similar to those that apply to
your existing internal PKI. You and your partner organization are responsible for creating administrative
policies for the root CA and enforcing the integrity of the new root.
Extending Your CA Infrastructure 785
Using a Cross-Certification Configuration
With the cross-certification method for extending the CA infrastructure, neither party creates a separate PKI;
instead, cross-certificates, accompanied by qualified subordination, enable communication between existing
public key infrastructures of two organizations to the degree of trust that their business relationship dictates.
Cross-certification creates a shared trust between two CAs that do not share a common root CA. These CAs
exchange cross-certificates that allow their organizations to communicate. In this way, the organizations do not
have to create and manage additional root CAs. Cross-certification might be the best option if a common root
CA for both PKIs does not exist.
Figure 15.13 shows an example of an extended CA infrastructure based on cross-certification between the root
CA of organization 1 and a subordinate CA in organization 2.
Figure 15.13 Extended CA Infrastructure Based on Cross-Certification
The advantages to using cross-certification to extend the PKI include low cost and a high degree of flexibility,
as you can cross-certify at any level in the hierarchy. For example, if a division of organization 2 wants to share
information with all of organization 1, the division can cross-certify with the root CA of organization 1. This,
however, creates a security risk, as it exposes resources in parts of the organization that are not part of the
business relationship. On the other hand, if a division of organization 1 and a division of organization 2 want to
share information, the two divisions can cross-certify CAs that are lower in the CA hierarchy. This option is
more secure, as the other divisions of the organizations are not unnecessarily exposed.
Cross-certification requires greater administrative overhead than other methods for extending the CA
infrastructure, and entails the risk that outsiders might unintentionally be given access to internal resources. If an
organization becomes involved in many cross-certification relationships with different levels of trust and
different applications, the management overhead can be significant.
786 Chapter 16 Designing a Public Key Infrastructure
Limiting Unplanned Trusts
When you extend your CA trust infrastructure beyond the boundaries of the PKI of your organization, you can
inadvertently create unplanned trust relationships.
Unplanned trusts that can occur include:

Allowing certificates to be used for unintended applications

Allowing external certificates to be used for longer than intended

Enabling trust with the extended business partners of a business partners
For example, if company A trusts company B by means of an unconstrained cross-certificate, and company B
trusts company C, then company A unintentionally trusts company C. Equally serious problems can occur when
company A and company B cross-certify, and company A does not realize that company B does not have the
same level of control over the manner in which its certificates are issued and used.
To limit the creation of unplanned trust relationships and the potential security risks that they pose, you can use
CA constraints to define limits on your cross-certificate relationships. Constraints in Windows Server 2003 can
be based on:

Use and path length (basic constraints)

Names

Issuance policy

Application policy

Policy mapping
Implement these constraints when you configure your CA and end user certificates. For more information about
defining constraints, see “Using Qualified Subordination” later in this chapter.
Using Certificate Trust Lists to Limit Unplanned Trusts
You can use certificate trust lists (CTLs) to limit unplanned trusts. CTLs are the primary means of limiting
unplanned trust relationships in Windows 2000 environments.
A CTL is a predefined list of certificates that is signed by a trusted entity. The CTL includes either hashes of
certificates or a list of the actual certificate names. In most cases, the CTL is a list of hashed certificate contexts.
The CTL allows you to limit the purposes for which certificates issued by an external CA can be used, and the
validity period of those certificates.
Extending Your CA Infrastructure 787
Windows Server 2003 certificate trust lists allow you to do the following:

Create trust certificates from specific CAs without requiring broader trust for the root
CA. For example, you can use certificate trust lists on an extranet to trust certificates issued by
certain commercial CAs. If you map certificates that are issued to an account stored in Active
Directory, you can grant appropriate permission to users who need access to restricted extranet
resources. This is possible because they have certificates issued by the trusted commercial CAs.

Restrict the permitted use of certificates issued by trusted CAs. For example, you can use a
certificate trust list on an extranet to restrict the permitted use of certificates to applications
such as secure mail.

Control the period of time in which third-party certificates and CAs are valid. For
example, the CA of a business partner can have a lifetime of five years and issue certificates
with lifetimes of one year. However, you can create a certificate trust list with a lifetime of six
months to limit the time that certificates issued by the CA of the business partner are trusted on
your extranet.
You might use a CTL to allow users to trust certificates that are issued by a commercial CA and restrict the
permitted uses for those certificates. You might also use CTLs to control trust on an extranet for certificates that
are issued by CAs that are managed by your business partners.
Note
After a CTL is defined, it must be applied to client computers by means
of Group Policy.
Example: Selecting an Extended CA
Infrastructure Configuration
Organizations frequently enter into joint ventures, which can involve the sharing of confidential information,
such as engineering data that stored is on an internal network. To facilitate this type of data sharing, an
organization can initiate a cross-certified relationship that allows some, but not all, employees of another
organization to access data on its network.
One way to enable this cross-certified relationship is to create a subordinate CA to a high security Issuing CA.
This subordinate CA is then used to facilitate the joint venture relationship. Although it is possible to crosscertify directly with a corporate high security CA, the advantage of using a separate CA specifically for the joint
venture is that it allows you to restrict the capabilities of the people who work for the other partners in the joint
venture. They cannot, for example, use their certificates for unintended purposes or to access portions of the
network that are not relevant to the joint venture.
Figure 15.14 illustrates the position of the new CA in the CA infrastructure of one organization.
788 Chapter 16 Designing a Public Key Infrastructure
Figure 15.14 Extended CA Infrastructure
Creating the CA alone does not enable the new joint venture operations. To enable this sharing, before the CAs
are created, administrators must configure the cross-certificates that qualify the trust relationship between the
two organizations. These cross-certificates define where, in the first organization, holders of the certificates
belonging to the second organization can and cannot go, and which applications they can and cannot use. For
information about how to implement these namespace and application limits, see “Using Constraints and Policy
Mapping” later in this chapter.
Defining Certificate Configuration
Options
After your CA infrastructure is in place, you can begin to define the certificate configuration options that you
need to meet the requirements of your users, as well as the security needs of your organization. Figure 15.15
shows the steps involved in defining certificate configuration options.
Defining Certificate Configuration Options 789
Figure 15.15 Defining Certificate Configuration Options
Selecting Certificate Templates
The certificate services that you deploy and the security requirements that are specific to your organization
impact the types of certificates that you issue. You can issue multiple types of certificates to meet a variety of
security requirements.
The certificate templates available with an enterprise CA in Windows Server 2000 and Windows Server 2003
provide the default contents of all certificates that can be requested from a Windows enterprise CA. These
certificate templates are stored in Active Directory and cannot be used with stand-alone CAs.
790 Chapter 16 Designing a Public Key Infrastructure
Certificate templates can serve a single purpose or multiple purposes. Single-purpose templates generate
certificates that can be used for a single application. For example, the Smart Card Logon certificate template is
designed for smart card logon only. Multipurpose templates generate certificates that can be used for a number
of applications, such as Secure Sockets Layer (SSL), S/MIME, and EFS. For example, a user certificate can be
used for both user authentication and EFS encryption.
Both Windows 2000 and Windows Server 2003 support single-purpose and multipurpose templates. However,
Windows 2000 and Windows Server 2003 Standard Edition only support version 1 templates, which have readonly attributes that cannot be customized or extended. Windows Server 2003, Enterprise Edition supports
version 2 templates, which allow you to create new certificate templates, clone an existing template, and replace
templates that are already in use.
Important
If you are already using version 1 templates, you can upgrade them to
version 2 templates. However, the domain admins in your top level
domain must have full access control permissions on the version 1
templates in order to complete this upgrade. Domain administrators do
not need to have full access control over the templates after the upgrade
has been completed.
Both version 1 and version 2 certificate templates include the following information:

Intended user of the certificate.

CA that issued the certificate.

Serial number that uniquely identifies each certificate.

Public key value for the user identified in the subject field.

Validity period of the certificate.

Extensions, if any, which apply to the certificate, including additional information that can
define certificate purposes, restrictions, and management.

Digital signature of the CA, which verifies the relationship of the certificate to the issuing CA.
Note
You can also create your own certificate templates.
Defining Certificate Configuration Options 791
Before the certificates are issued, you need to determine the following critical information:

Certificate key length

Certificate validity period

Optional certificate extensions
Note
Certificate templates, in conjunction with the CA policy module, allow you
to define certificate policy for CA certificates.
In addition, version 2 templates allow you to configure the following:

Customized enrollment policies

Policies related to validity periods

Policies related to application usage

Policies related to key usage

Policies related to key archiving

Certificate authorization

Domain authentication

Certificate administrators

Signed enrollment agents

Key creation

Key and CSP types

Certificate contents
Important
You must upgrade the schema in an Active Directory forest to Windows
Server 2003 in order to support version 2 templates. You do not need to
upgrade all domain controllers to Windows Server 2003 to perform a
schema upgrade.
Certificate templates can only be used when the server that is running Certificate Services is an enterprise CA.
Enterprise CAs can issue a variety of certificate types based on the templates. You can configure each enterprise
CA to issue only specific types of certificates. Table 15.6 lists the different types of version 1 certificate
templates that are available, and the purposes for each.
792 Chapter 16 Designing a Public Key Infrastructure
Table 15.6 Version 1 Certificate Templates
Certificate template name
Certificate purposes
Issued to
Administrator
Code signing, Microsoft trust list
signing, EFS, secure e-mail, client
authentication
Users
Authenticated Session
Client authentication
Users
Basic EFS
Encrypting File System
Users
CEP Encryption
Act as a registration authority
Users
Code Signing
Code signing
Users
Domain Controller
Client authentication, server
authentication
Computers
EFS Recovery Agent
File recovery
Users
Enrollment Agent
(Computer)
Certificate request agent
Computers
Exchange Enrollment
Agent (Offline Request)
Certificate request agent
Users
Exchange User Signature
Secure e-mail, client
authentication
Users
Exchange User
Secure e-mail, client
authentication
Users
IPSEC
IP Security
Computers
IPSEC (offline request)
IP Security
Computers
Root Certification
Authority
Identify the root CA
Computers
Router
Client authentication
Computers/rou
ters
Smartcard Logon
Client authentication
Users
Smartcard User
Client authentication, secure email
Users
Subordinate CA
All
Computers
Trust List Signing
Microsoft trust list signing
Users
User
Authentication, secure e-mail, and
EFS
Users
User Signature
Secure e-mail, client
authentication
Users
WebServer
Server authentication
Computers
Table 15.7 lists the version 2 certificate templates that are available in Windows Server 2003 Advanced Server
and the purposes for each.
Defining Certificate Configuration Options 793
Table 15.7 Version 2 Certificate Templates
Certificate template name
Certificate purposes
Issued to
CA Exchange
CA encryption
Computer
Cross certification
authority
Qualified subordination
Computer
Directory E-mail
Replication
Directory replication
Users
Domain Controller
Authentication
Client authentication, server
authentication
Users
Key Recovery Agent
Key recovery
Users
Note
When you select and modify templates, create function-based names for
the templates, such as domainA_e-mail or legal_signing. Function-based
names help users to select the appropriate certificate for the task that
they need to perform.
Delegating Administration of Certificate Templates
Although the majority of CA-related tasks are performed by administering the CA itself, certain tasks, including
the administration of certificate templates, are controlled through Active Directory.
To delegate the administration of certificate templates:
1.
Right-click the Certificate Templates node in the Certification Authority snap-in and select
Manage.
2.
Double click a certificate template.
3.
Under the Security tab, check the Allow boxes for the Read and Write permissions.
For more information about certificate templates, see the Distributed Services Guide of the Windows
Server 2003 Resource Kit (or see the Distributed Services Guide on the Web at
http://www.microsoft.com/reskit).
794 Chapter 16 Designing a Public Key Infrastructure
Selecting Certificate Security Options
The security requirements for your certificates are based on the following four critical factors:

Risk of attack. The security of your network, the value of the network resources protected by
the CA trust chain, and the cost of initiating an attack all impact the security requirements for
your certificates.

The degree to which you trust your certificate users. In general, the less you trust your users,
the shorter the certificate lifetimes and CRL lifetimes, and the tighter the control over renewals.
For example, you might trust temporary users less than you trust normal business users, and
therefore you might set shorter lifetimes on the certificates of temporary users and require
stricter controls for their renewal.

The amount of administrative effort that you are willing to devote to certificate renewal
and CA renewal. For example, to reduce the administrative effort required to renew CAs, you
can specify long, safe lifetimes for your certification trust hierarchies.

The business value of the certificate. For example, you place tighter restrictions on
certificates used to validate critical data such as purchase contracts than you place on
certificates for routine e-mail.
The standard settings for certificates issued by Microsoft Certificate Services meet most security needs.
However, you might want to specify stronger security settings for certificates that are used by certain user
groups. For example, you can specify longer private key lengths and shorter certificate lifetimes for certificates
used to provide security for valuable information.
To ensure that your certificates meet the security requirements of your organization, you need to configure the
following:

The cryptographic algorithms and private key lengths for CAs and issued certificates.

The amount of time for which the certificates and their keys are valid.

Certificate renewal and permitted renewal frequency.
Selecting Cryptographic Algorithms and Key Lengths
Windows 2000 and Windows Server 2003 support several well-known cryptographic algorithms that are also
supported by other PKI products. When you install a Windows Server 2003 CA, you can select CA key lengths
from 384 bits to 16,384 bits, depending on the CSP that you select. In a typical deployment, user certificates
have 1,024-bit keys and root CAs have 4,096-bit keys.
Key length is determined in part by the cryptographic algorithm that you select. Table 15.8 lists the algorithms
that Windows Server 2003 supports and their minimum and maximum key lengths.
Defining Certificate Configuration Options 795
Table 15.8 Windows Server 2003 Algorithms and Key Lengths
Algorithm
Minimum Key Length
Maximum Key Length
RSA
384-bit
16,384-bit
DSA
512-bit
1,024-bit
In most cases, the default key length provides an acceptable balance between security and CA performance.
However, to provide the maximum possible protection without degrading CA performance, select the largest
keys that are practical for CAs. Keys that are at least 1,024 bits long are the best choice for CA certificates.
Keep in mind that generating large keys can place a high load on computer processors and might also increase
the amount of time needed for signing operations to excessive levels.
Note
Key length has a minimal impact on the size of a certificate. However, it
can be a significant consideration for smart card deployments because of
the space constraints of the card.
In general, public and private key lengths do not impact interoperability as long as both environments support a
common range of key lengths. If one PKI supports large public keys and another does not, however, the two
cannot exchange symmetric keys or sign and verify data.
Note
While key exchange and digital signature operations performed between
PKIs do not require the same public and private key lengths, symmetric
key algorithms do. In addition, if different key lengths are used, both key
lengths must be supported in both environments.
When PKIs do not support the same key lengths, some applications cannot decrypt data that other applications
have encrypted. In addition, the PKIs might not be able to establish secure communications channels between
applications if the applications cannot agree on symmetric key lengths, as required by protocols such as SSL and
TLS.
If a PKI uses public/private keys based on an algorithm such as RSA, all PKI operations can be accomplished
with only one key pair. However, single key pairs might not meet the security requirements of your organization
or its choice of algorithm. For this reason, Windows Server 2003 supports both single key pairs and dual key
pairs. A good PKI is flexible enough to allow as many or as few key pairs as are required by applications.
If one PKI operates according to the number of keys that applications use, it can impact interoperability with
other PKIs. For example, an e-mail application could sign a message with a signature-only key and include the
associated certificate in a message sent to a recipient without also sending an encryption certificate as part of the
message. The recipient might then be unable to discover the encryption certificate of the sender to reply with an
encrypted message back to the sender.
796 Chapter 16 Designing a Public Key Infrastructure
Establishing Certificate and Key Lifetimes
A number of factors impact certificate lifetimes, such as the type of certificate, the security requirements of your
organization, the standard practices in your industry, and government regulations. In general, longer keys
support longer certificate lifetimes and key lifetimes.
When establishing certificate and key lifetimes, you must consider how vulnerable your keys are to compromise
and what the potential consequences of compromise are. The following factors impact the lifetimes that you
choose for certificates and keys:

The length of private keys for certificates. Because longer keys are more difficult to break,
they justify longer safe key lifetimes.

The security of the CAs and their private keys. In general, the more secure the CA and its
private key, the longer the safe certificate lifetime. CAs that are operated offline and stored in
locked vaults or data centers are the most secure.

The strength of the technology used for cryptographic operations. In general, stronger
cryptographic technology supports longer key lifetimes. You can extend key lifetimes if you
enhance private key storage by using smart cards and other hardware cryptographic service
providers. Some cryptographic technologies provide stronger security, as well as support for
stronger cryptographic algorithms. For example, you might use smart cards for user logon or
FIPS 140-1 Crypto Cards for secure mail and secure Web browsers.

The vulnerability of the CA certification chain to attack. In general, the more vulnerable
your CA hierarchy is to attack, the longer the CA private keys and the shorter the key lifetimes
required.

The users of your certificates. Organizations typically trust their own employees more than
they trust employees of other organizations. If you issue certificates to external users, you might
want to shorten the lifetimes of those certificates.

The number of certificates that have been signed by a dedicated CA. The more public the
CA public key that is used to sign an issued certificate, the more vulnerable it becomes to
attempts to break its key.
An expiration date is defined for each certificate at the time that it is issued. An enterprise CA issues certificates
with lifetimes that are based on the certificate template for the requested certificate type.
Most certificate templates specify a lifetime of one year. However, the following version 1 certificate templates
specify a lifetime of two years:

CEP Encryption (offline request)

Enrollment Agent

Enrollment Agent (computer)
Defining Certificate Configuration Options 797

Enrollment Agent (offline request)

IPSec

IPSec (offline request)

Router (offline request)

Web Server
The following certificate templates specify a lifetime of five years:

Domain Controller

Subordinate certification authority
The lifetimes of certificates issued by stand-alone CAs are determined by system registry settings for the CA.
The certificates for enterprise root CAs and enterprise stand-alone root CAs have a default lifetime of two years.
However, you can specify a different lifetime for the CA during installation. The parent CA that approves the
certificate request and issues the certificate determines the lifetime of a subordinate CA certificate.
Creating a Certificate Renewal Strategy
CAs continue to issue and renew certificates until they reach the end of their established lifetimes. Certificates
expire when the issuing CA reaches the end of its established lifetime, unless:

They are renewed with a new key pair to extend their lifetime.

They are revoked before the expiration date is reached.

They are considered to have expired because an issuing CA is unavailable to verify their
validity.
Certificate lifetimes impact the security of your PKI for the following reasons:

Over a period of time, encryption keys become more vulnerable to attack. In general, the longer
the period of time that a key pair is in use, the greater the risk that the key can be compromised.
To mitigate this risk, you must establish maximum allowable key lifetimes and renew
certificates with new key pairs before these limits are exceeded.

When a CA certificate expires, all subordinate CAs that depend upon this CA for validation
also expire.

When a CA certificate is renewed, all certificates that have been issued by the CA must also be
renewed. All certificates issued by the CA expire when the certificate of the CA is renewed,
regardless of whether or not the key pair is also renewed.
798 Chapter 16 Designing a Public Key Infrastructure
To reduce the risk of a private key becoming compromised, the private key and public key sets for certificates
can be renewed each time the certificates are renewed, instead of when the keys reach their maximum lifetimes.
You can renew CAs by assigning them a new key pair or by using the existing key pair. If you create a new key
pair and the original certificate has not yet expired, it must have a new Subject Key Identifier (SKI) and a
separate CRL. Renewing certificates with new key sets is not possible for some hardware-based CSPs, either
because key storage limits prohibit this or because key generation takes a long time.
Note
For more information about configuring certificate renewal, see
“Selecting a Certificate Enrollment and Renewal Method” later in this
chapter. For more information about the impact of certificate renewal on
the use of certificate revocation lists, see “Establishing Certificate
Revocation Policies” later in this chapter.
Certificate lifetimes affect the number of certificate renewal requests that are transmitted across your network.
For users in remote offices who are connecting to the network across slow links, you might want to lengthen
certificate lifetimes to reduce the number and frequency of these requests.
To create a certificate renewal strategy, determine the following:

Which certificates, if any, are you allowed to renew?

How often can a certificate be renewed before its key is retired?
In general, certificates with stronger keys that are used less frequently and that are less available to potential
hackers can justify longer lifetimes and at least one renewal. Certificates with average key lengths and shorter
lifetimes can be renewed more frequently — but not beyond the validity date for the certificate that authorizes
the CA that issued the certificate. This is called nested validity or nested expiration.
Nesting Certificate Lifetimes
In addition to defining certificate lifetimes for your Windows Server 2003 CAs, you need to confirm that
certificate lifetimes and renewals do not extend beyond the lifetimes of the CAs that are above them in the
hierarchy.
By default, the certificate for the root CA has a longer lifetime than certificates for the other CAs in the
hierarchy. This is because a Windows Server 2003 CA cannot issue certificates with a lifetime that extends
beyond the validity period of its own certificate. If the lifetime specified for a requested certificate type exceeds
the expiration date of the certificate of the CA, the CA truncates the lifetime of the issued certificate to match
the expiration date for its own certificate.
Defining Certificate Configuration Options 799
For example:

If the end date of a Windows Server 2003 root CA certificate is January 2, 2012, no Windows
Server 2003 child CA in the chain below the root can issue a certificate with a date that is past
January 2, 2012.

If a Windows Server 2003 intermediate CA has a certificate end date of January 2, 2008, no
Windows Server 2003 child CA can issue certificates with an end date that is past January 2,
2008.

If a Windows Server 2003 issuing CA has a certificate end date of January 2, 2004, no
certificate that the CA issues can have an end date that is past January 2, 2004.

If the end date of a Windows Server 2003 CA certificate is January 2, 2004, and it receives a
request to issue a one-year certificate on August 1, 2002, the CA issues the one-year certificate
with an end date of July 31, 2003. However, if the CA receives a request to issue a one-year
certificate on August 1, 2003, the CA issues the certificate with an end date of January 2, 2004.

A Windows Server 2003 CA with a certificate lifetime of five years with an end date of
January 2, 2007, can issue one-year certificates until January 2, 2006, or two-year certificates
until January 2, 2005. After January 2, 2005, the CA does not issue two-year certificates. It
truncates the validity end date to January 2, 2007. Likewise, after January 2, 2006, the CA
truncates the validity end date of both one-year and two-year certificates to January 2, 2007.
The more nesting you have in your certification hierarchy, the shorter the certificate lifetimes become.
Configure your certificate life cycles in such a way as to avoid short certificate lifetimes and certificate renewal
cycles. If you specify long lifetimes for CAs and later discover that the CAs are not secure, you can renew CAs
in the certification hierarchy with shorter lifetimes to reduce the potential security risks.
Note
For a worksheet to assist you in preparing your certificate life cycle plan,
see “Windows Server 2003 Certificate Life Cycle Plan” (DSSPKI_3.doc)
on the Windows Server 2003 Deployment Kit companion CD (or see
“Windows Server 2003 Certificate Life Cycle Plan” on the Web at
http://www.microsoft.com/reskit).
800 Chapter 16 Designing a Public Key Infrastructure
Using Qualified Subordination
Many of the certificates that you issue can be used without any further customization. However, you might want
to limit the scope of your certificates, whether they are intended to validate a subordinate CA, to cross-certify an
external CA, or to enable an end user application. You can limit the scope of a certificate by:

Defining the namespaces for which a subordinate CA will issue certificates.

Specifying the acceptable uses of certificates issued by a qualified subordinate CA.

Creating trust between separate certification hierarchies.
Qualified subordination restricts the certificates issued by the qualified subordinate CA, or by CAs that chain
through the qualified subordinate CA, that are acceptable to your organization. You accomplish this by defining
the following in the Policy.inf file:
Note
The Policy.inf file is different from the CAPolicy.inf file. The Policy.inf file
impacts qualified subordination, whereas the CAPolicy.inf file impacts the
CA certificate.

Basic constraints. Define the certification path length required and allowed for policy
identifiers and policy mapping.

Name constraints. Define the range of namespaces that are permitted or excluded by the
qualified subordinate CA and its subordinates.

Issuance policies. Define the extent to which your organization trusts the identity presented in
a certificate. These policies are identified in a certificate by object identifiers.

Application policies. Define the applications that can be used in conjunction with certain
certificates.
In addition, if you are attempting to connect two different PKIs, whether within your organization or with a
third-party, you need to use policy mapping to achieve equivalency between the policy constraints that you have
defined and the policy constraints defined in the other PKI. The use of constraint extensions and policy mapping
allows you to control certificate usage more effectively, and to administer your certificates more effectively.
Qualified subordination allows you to ensure that specific constraints are applied when a CA issues or an
application uses a certificate. These constraints ensure that all certificates issued by the CA apply the policy
restrictions that you have defined.
Defining Certificate Configuration Options 801
By definition, your root CA applies all policies. You can use intermediate CAs to issue certificates that enable
different levels of security, such as High Security, Medium Security, and so on. The security policies that you
define are identified by means of object identifiers. When certain object identifiers are applied to a CA
certificate, all certificates below that CA in the hierarchy must also have a subset of those object identifiers. If
you create a certificate chain with no valid policy, any certificates that are issued are considered invalid.
However, if you create a certificate chain with no policy object identifiers at all, then the certificates that you
issue are considered to match the “any policy” object identifier. Figure 15.16 shows how policy is applied to
CAs.
Figure 15.16 How Policy Is Applied to CAs
The policies and constraints of each qualified subordinate CA are a subset of the policies and constraints of the
parent CA.
802 Chapter 16 Designing a Public Key Infrastructure
Using Basic Constraints
Basic constraints allow an application to determine whether a certificate is a CA certificate, which can then be
used by the certificate chain engine to build certification paths, or an end-certificate, which cannot.
You can also use basic constraints to limit the maximum number of CA certificates that can be included in a CA
path. For example, setting a path length of zero in the basic constraints section of the CAPolicy.inf file allows
only certificates issued by that specific CA to be included in the CA path. A path length of two allows only a
total of three CA certificates in a certification path. In the latter case, any certification paths that include more
than three CAs are discarded.
Use basic constraints if you do not want to trust additional CAs that are created lower in the CA hierarchy of
your organization. You can also use basic constraints in cross-certified relationships if you trust your business
partner and the certificates from all their existing CAs, but you do not want to trust certificates from any
additional CAs that they authorize.
Using Name Constraints
Name constraints allow you to designate which namespaces are either permitted or excluded for certificates
issued by a qualified subordinate CA. When the qualified subordinate CA receives a request, it compares the
names present in the subject and the subject alternate name fields to the configured name constraints, to
determine whether the namespace is permitted or excluded. As you design your PKI, you need to decide which
individual clients and business units are able to enroll for and use certain certificates. For many organizations,
the selected users, computers, and services are members of specific Active Directory domains and subdomains.
You can base name constraints on any of the following types of name formats:

X.500 Directory name. Distinguished names identify users and resources on the network in
Active Directory. This allows you to constrain a qualified subordinate CA to permit or exclude
users in Active Directory by using the distinguished names of the users. Active Directory also
uses distinguished names to create and reference groups of objects in the directory, such as
users and computers. The distinguished names of these object groups can also be used as name
constraints, allowing you to constrain a qualified subordinate CA to permit and exclude
certificate issuance for entire groups in the directory.

DNS domain name. You can apply the DNS namespaces that your network uses for name
resolution as name constraints for a qualified subordinate CA. When the qualified subordinate
CA receives a certificate request, it compares the DNS name associated with the computer
requesting the certificate to its DNS name constraints and decides whether or not to issue a
certificate. You can specify a DNS name constraint as a DNS host name, such as
host1.example.microsoft.com, or as a DNS namespace, wherein all DNS host names are
permitted or excluded, such as .example.microsoft.com.
Defining Certificate Configuration Options 803

E-mail and user principal name. You can specify e-mail and UPN name constraints for an
individual subject, such as [email protected], or you can specify constraints for all
subjects whose e-mail names or UPNs end in a specific name, such as @example.contoso.com.
Typically, you need to specify e-mail or UPN name constraints for all subjects whose e-mail
addresses and UPNs end in a specific name.

Universal Resource Identifier (URI). URIs are used to identify resources on the Internet by
means of identifiers such as URL, FTP, HTTP, telnet, mailto, news, and gopher. When
validating the URI names in a certificate request, the qualified subordinate CA ignores the
protocol element in the URI, such as http:// or ftp://, and uses the domain or host names only.

IP address. IP address name constraints follow the formatting conventions specified in RFCs
791 (IPv4) and 1883 (IPv6). The IP addresses contained in the certificate requests made to a
qualified subordinate CA are compared to the IP addresses in the name constraints of the
qualified subordinate CA.
You can configure name constraints to result in the following outcomes:

Permitted. The certificate request contains all names that are listed as permitted in the CA
name constraints extension of the issuer.

Not permitted. The certificate request contains a name that is not listed as permitted in the
name constraints extension of the issuer.

Excluded. The certificate request contains a name that is listed as excluded in the name
constraints extension of the issuer.
A CA certificate can contain name constraints that are applied to all certificate requests made to the CA. Each
request is compared to the list of permitted and excluded names to determine whether the name in the certificate
is considered permitted, not permitted, excluded, or not defined. When you include name constraints in a CA
certificate, the following rules are applied to the subject name and alternate subject name fields:

Excluded namespaces take precedence over permitted namespaces. A qualified subordinate
CA will not issue a certificate to a user within an excluded namespace even if the user is also
within a permitted namespace. For example, a user might be within the permitted Active
Directory namespace .xyz.com but also within the excluded DNS namespace .uvw.xyz.com. The
excluded DNS namespace overrides the permitted Active Directory namespace and the
certificate request of the user fails.

If the name constraints extension exists in a CA certificate, all name constraints must be
present in the appropriate format. Any name formats that are not included are considered to
be wild cards that match all possibilities. For example, if the DNS name constraint is absent, the
entry is treated as DNS=“”.
804 Chapter 16 Designing a Public Key Infrastructure

All name constraints are considered, even if they are not specified. No precedence is
applied to the listed name constraints. For this reason, name constraints that are not present are
treated as wildcards. For example if you only restrict the DNS name space, the Name
Constraints extension sets the remaining name constraints to allow all name spaces.

Name constraints are applied to the Subject Name extension and any existing Subject
Alternate Name extensions. For example, if a user can be identified by a DNS domain name
and an alternate e-mail name, name constraints apply to both.

Name constraints apply to all names contained in a certificate request. Each name in the
subject or subject alternate name extensions must match at least one of the name constraints
listed for that name type. A certificate request that includes a subject name or subject alternate
name that does not match a listed name type is rejected.

Name constraints are not case sensitive. For example, .xyz.com is treated the same as
XYZ.COM or xYz.Com.
Important
Name constraint validation is performed on the CA, not on the client.
However, you must have Windows XP and Windows Server 2003 clients
in order to use name constraints.
Using Issuance Policies
You can use issuance policies to define the extent to which your organization trusts the identity presented in a
certificate. For example, you can set an issuance policy stipulating that you only trust certificates that were
issued during a face-to-face meeting with a network administrator, such as when a smart card certificate is
issued.
An object identifier must describe every issuance policy that you define. The inclusion of an issuance policy
object identifier in an issued certificate indicates that the certificate was issued in a manner that meets the
issuance requirements associated with the issuance policy object identifier.
Note
Issuance policy is only available on Windows Server 2003 CAs.
Windows 2000 does not provide issuance policy.
Defining Certificate Configuration Options 805
You can use a specific certificate template to define one or more issuance policy object identifiers that need to
be included in any certificates issued. Windows Server 2003 includes four predefined issuance policies:

All Issuance (2.5.29.32.0). The all issuance policy indicates that the issuance policy contains
all other issuance policies. Typically, this object identifier is only assigned to CA certificates.

Low Assurance (1.3.6.1.4.1.311.21.8.x.y.z.1.400). The low assurance object identifier is used
to represent certificates that are issued with no additional security requirements.
Note
The x.y.z portion of the object identifier is a randomly generated numeric
sequence that is unique for each Windows Server 2003 forest.

Medium Assurance (1.3.6.1.4.1.311.21.8.x.y.z.1.401). The medium assurance object identifier
is used to represent certificates that have additional security requirements for issuance. For
example, a smart card certificate that is issued in a face to face meeting with a smart card issuer
might be considered a medium assurance certificate and contain the medium assurance object
identifier.

High Assurance (1.3.6.1.4.1.311.21.8.x.y.z.1.402). The high assurance object identifier is used
to represent certificates that are issued with the highest security. For example, the issuance of a
key recovery agent certificate might require additional background checks and a digital
signature from a designated approver because a person holding this certificate can recover
private key material from a Windows Server 2003, Enterprise Edition CA.
In addition, you can create your own object identifiers to represent custom issuance policies. For example, two
organizations involved in a purchaser/seller relationship can define custom object identifiers to represent digital
signature certificates for specific purchase amounts. In such a case, an object identifier can be defined for
purchase between $100,000 and $500,000 and another object identifier can be defined for purchases greater than
$500,000. Applications can then use these object identifiers to recognize whether a person had the appropriate
signing authority for a specific volume purchase.
806 Chapter 16 Designing a Public Key Infrastructure
Applying Policy Mapping
In many cases, the administrators of two PKIs define their own policies and object identifiers. In some cases
these policies are identical, but in most cases there are small differences between them. For example, one
organization might stipulate that one physical form of identification is sufficient to grant a certificate request,
while a second organization requires three forms of physical identification to grant a similar request. In these
cases, you need to negotiate with the administrators of the other PKI to define terms of equivalence before the
cross-certified relationship can be established. This is called policy mapping.
Policy mapping enables interoperability between two organizations that apply similar issuance and application
policies, but have deployed different object identifiers. If the policy object identifier (for example, 1.2.3.4) of
one company represents a specific function, and the policy object identifier of another company (for example,
11.22.33.44) represents the same function, they can be mapped, so that 11.22.33.44 and 1.2.3.4 are
interchangeable.
The qualified subordinate CA that contains this mapping is called the issuer CA and the subordinate CA whose
policies have been mapped is called the subject CA. In mapping some or all of the policies of the subject CA to
the policies of the issuer, the issuer CA effectively subordinates the subject CA. The result of this mapping is
that users and computers in the issuer CA trust hierarchy can use their own certification paths to validate
certificates from users and computers in the subject CA trust hierarchy. The separate trust hierarchy can be
within the same intranet or in separate PKI environments over an extranet.
To apply policy mapping
4.
Identify the trust hierarchy with which you want to establish a trust relationship.
5.
Establish equivalence in the assurance levels used by the two trust hierarchies involved in the
trust relationship.
6.
Obtain the issuance and application policy object identifiers used in both trust hierarchies
involved in the trust relationship.
7.
Map the issuance and application policy object identifiers in the separate trust hierarchies, and
define their policy constraints in the CA certificate request for the qualified subordinate CA that
you are installing in your trust hierarchy.
8.
Install the qualified subordinate CA with the policies, policy mappings, and policy constraints
in your trust hierarchy.
Defining Certificate Configuration Options 807
Constraining Policy Mapping
You can refine policy mapping by setting parameters for how the issuance policy defined in qualified
subordination affects other CAs below the qualified subordinate CA. These parameters can help to limit
unplanned trust relationships. The following two settings define this relationship:

Require explicit policy. Specifies the number of certificates that can exist in the hierarchy
below a certificate before an explicit policy must exist. For example, if the explicit policy is
configured with a setting of three, the defined issuance policy must exist for three layers of the
hierarchy. The CA on which the qualified subordination is defined is the first level.

Inhibit policy mapping. Specifies the number of additional certificates that can appear in the
path before policy mapping is no longer permitted. For example, an inhibit policy mapping
value of three restricts the policy mapping to only three levels of CAs below the qualified
subordinate CA.
Using Application Policies
Certificates provide important information that is not specific to an application. However, you might need to
define which applications can be used in conjunction with certain certificates. Application policy allows you to
ensure that certificates are only used with the applications that you specify.
An application can also be written to accept only certificates that contain specific application policies. When the
application receives signed information from a user, the application reviews the certificate associated with the
private key used to sign the information, and ensures that the application policy extension contains the object
identifiers required by the application.
Application policies are similar to the Extend Key Usage (EKU) extension in a certificate, as both use one or
more object identifiers to prescribe how the public key in a certificate must be used. Windows Server 2003
supports Extend Key Usage to support PKIs that use this extension, but application policies are used in place of
EKU.
808 Chapter 16 Designing a Public Key Infrastructure
Application policy is Microsoft specific and is treated much like Extended Key Usage. If a certificate has an
extension containing an application policy and also has an EKU extension, the EKU extension is ignored. If,
however, a certificate has only an EKU extension, the EKU extension is treated like an application policy
extension. If a certificate has an application policy extension and an EKU property, the effective policy for the
certificate is the common policy between the EKU property object identifiers and the application policy object
identifiers.
Note
If you are issuing certificates that include both application policy and
EKU extensions, ensure that the two extensions contain identical object
identifiers.
Using Constraints and Policy Mapping
The method or methods that you use to limit unplanned trust depend in large part on the security challenges that
you must address in your organization.
For example, use name constraints to limit unplanned domain-based trusts. If your organization has more than
one domain — such as companyA.com and subdomain.companyA.com — you might only want crosscertificates to map to CAs in the companyA.com domain and not to CAs in the subdomain.companyA.com
domain. On the other hand, if you have five different domains and want your cross-certificates to apply to three
of them, path constraints provide a more flexible solution.
Use path constraints if transitive trusts create problems for your organization — for example, if you have an
environment in which users can freely install subordinate CAs and you do not have strong security guidelines
governing CA creation and management.
Policy constraints are the most useful of the constraint options, both internally and externally. Name and path
constraints might not provide you with sufficient protection in certain cross-certified relationships if the security
standards of your business partners are not as strong as yours. For example, organization A might have a policy
that all user certificates must be approved manually by an administrator, while organization B approves
certificate requests automatically as long as the user has an e-mail account. The security administrators for
organization A must ensure that the certificates that users in organization B use to access resources meet the
higher security standards that are necessary in organization A. They can accomplish this by using policy
constraints.
Use policy mapping if the organization that you are cross-certifying with has policies that are similar to those of
your organization. Policy mapping is less useful when the policies of your organization are stricter than the
policies of the other organization, or vice versa. If this is the case, use policy constraints to restrict your trust
relationship instead of using policy mapping.
Defining Certificate Configuration Options 809
Example: Configuring Certificates
After an organization has defined its certificate requirements, internal PKI configuration, and external
infrastructure, it needs to determine the certificate lifetimes, encryption key lengths, renewal policies, and other
restrictions, if any, that apply to the use of each type of certificate. Figure 15.17 shows the certificate design
decisions of one organization.
Figure 15.17 Example of a Windows Server 2003 Certificate Lifecycle Plan Worksheet
810 Chapter 16 Designing a Public Key Infrastructure
For a worksheet to assist you in documenting your certificate lifecycle plan, see “Windows Server 2003
Certificate Lifecycle Plan” (DSSPKI_3.doc) on the Windows Server 2003 Deployment Kit companion CD (or
see “Windows Server 2003 Certificate Lifecycle Plan” on the Web at http://www.microsoft.com/reskit).
All certificates are issued by Windows Server 2003 CAs. The certificates for the people working for the
business partners (for the extranet) can be issued by the Windows Server 2003 CA or by the CA of the business
partner. CTLs allow the extranet domain to trust the certificates of the business partners. Where appropriate,
stand-alone CAs provide flexible lifetimes for CAs. The renewal of certificates with new keys limits the amount
of time that keys are in use and reduces the risk of key compromise.
This organization does not have unusual security requirements that require the use of one cryptographic
algorithm over another. Therefore, they chose to accept the default cryptographic algorithms that have been
established for each type of certificate and CA.
The certificates issued to the business partners of this organization are constrained by namespace, by path
length, and to specific applications. In addition, the corporation uses policy mapping to specify the
authentication procedures required of business partner users who are issued certificates to access the resources
of the first organization.
Creating a Certificate Management
Plan
After you have configured certificates for your organization, you need to create a plan for managing certificates
throughout their lifetimes.
Figure 15.18 shows the process for creating a certificate management plan.
Creating a Certificate Management Plan 811
Figure 15.18 Creating a Certificate Management Plan
812 Chapter 16 Designing a Public Key Infrastructure
Selecting a Certificate Enrollment and
Renewal Method
To enable enrollment, you need to specify the enrollment and renewal processes for your certificates.
Enrollment involves either configuring permissions to establish which security principals have Enroll
permissions for specific templates (in the case of enterprise CAs) or appointing a certificate administrator who
reviews each certificate request and issues or denies the request based on the information provided.
Microsoft Certificate Services supports the ability to process certificate requests manually, if administrative
approval is required, or automatically, if no approval is necessary. The following enrollment and renewal
methods are available:

Certificate autoenrollment and renewal. Allows you to automatically issue certificates that
enable PKI applications, such as smart card logon, EFS, SSL, and S/MIME, to users and
computers within an Active Directory environment. Certificate autoenrollment is based on a
combination of Group Policy settings and certificate templates, which allows you to enroll
computers when they start up and to enroll users when they log on to their domain.
Note
To use autoenrollment, you need a Windows Server 2003 domain
controller, a Windows XP Professional client, and a Windows
Server 2003 Advanced Server enterprise CA.

Certificate Request Wizard and Certificate Renewal Wizard. Available from the
Certificates console, you can use the Certificate Request Wizard to request a certificate from an
active enterprise CA on behalf of a user, computer, or service.
Note
This option can only be used for Windows 2000, Windows Server 2003,
and Windows XP users, computers, and services.
Creating a Certificate Management Plan 813

Web Enrollment Support pages. Contain Active Server Pages and ActiveX controls that
provide a Web-based user interface to a CA. By default, the Web Enrollment Support pages are
automatically installed on the computer on which the CA is installed, but you can also install
the Web Enrollment Support pages on another Windows Server 2003 computer. You can also
customize Web Enrollment Support pages. For example, you can limit user options or provide
additional links to online user instructions and user support information.
Note
You can use Web Enrollment Support pages on stand-alone CAs to
issue most of the same types of certificates that enterprise CAs can
issue, with the exception of certificates for smart card logon and for
autoenrollment, which must be issued and renewed by an enterprise CA.
The Web Enrollment Support pages that are installed on stand-alone
CAs do not use certificate templates, so all information about the
certificate, including information about the requester (and, if asking for a
specific application, a correct object identifier), must be specified in the
certificate request.

Smart card enrollment station. Advanced version of the Web Enrollment Support pages that
allows trusted administrators or security personnel to enroll for smart card certificates on the
behalf of other users. For more information about using the smart card enrollment station, see
“Planning a Smart Card Deployment” in this book.
To select the certificate enrollment and renewal processes that are appropriate for your organization, you need to
consider the following:

The users, computers, and services for which you intend to provide services. Determine
whether they are internal or external to the organization. Identify the operating systems they are
running and determine whether or not they are connected to Active Directory.

The operating system that your clients are using. Clients running Windows Server 2003 and
Windows XP can use the Certificate Request Wizard, autoenrollment, or the smart card
enrollment station. Windows 2000 supports the Certificate Request Wizard but does not support
smart card autoenrollment. Autoenrollment and the smart card enrollment station also require
Active Directory. Most other clients can use their Web browsers to access Web-based
enrollment and renewal services.

The policies that you establish in order to manage certificate distribution. This includes
both the procedural policies that you establish for your PKI, and the Group Policy settings that
you use to implement those policies.

The type of CA that is issuing the certificates. For example, you must have a Windows 2000
or Windows Server 2003 enterprise CA to use the smart card enrollment station. Only Windows
Server 2003 CAs support smart card autoenrollment.
814 Chapter 16 Designing a Public Key Infrastructure
Selecting certificate enrollment and renewal processes involves making decisions about the following:

Automatic versus manual requests

Automatic versus manual approval

An enrollment and renewal user interface

CA certificate renewal
Selecting Automatic vs. Manual Requests
Whether you choose to generate certificate requests automatically or manually depends on the types of
certificates that you intend to use and the number and type of clients that you enroll. For example, if you want
all users or computers to use a certain type of certificate, it is not practical for you to require that each certificate
be requested individually. Although rolling out a new certificate to all users or computers at one time can
generate a large amount of network activity, you can control that activity by deploying the certificate requests
for each organizational unit one at a time.
On the other hand, you might want to have users or an administrator request certain high-security certificates,
such as those used for digital signing or administrative tasks, only when needed. This can improve
administrative control over these certificates — particularly if certificate use is not limited by a user or computer
OU, or security group membership.
You can improve control over your certificates by using one of the following options to limit user certificate
requests:

Restrict access to specific templates. Configure the discretionary access control list (DACL)
for each template so that only the required security principals have Enroll and Read permissions
for particular templates.

Automate the deployment of computer certificates. Configure Group Policy to automatically
assign the necessary computer certificates by adding the certificate template to the Automatic
Certificate Request Settings option in Group Policy.
Tip
Autoenrollment is most useful for issuing and renewing computer and
IPSec certificates.
Creating a Certificate Management Plan 815
Selecting Automatic vs. Manual Approval
Users can request a certificate from a Windows Server 2003 CA either manually or automatically. This request
is held until an administrator approves it, if manual approval is required, or until the verification process is
completed. When the certificate request has been approved, the autoenrollment process installs the certificate
automatically, or automatically renews the certificate on behalf of the user, based on the specifications in the
certificate template.
Most of the time, you choose the same method for certificate approval that you choose for certificate requests —
but not always. For example, if you have the appropriate Group Policy and DACL restrictions on your
certificate templates, you might decide to approve automatically a certificate request that was generated
manually. Conversely, in some cases, it is appropriate to manually approve certificate requests that are
automatically generated.
Note
You can use strong authentication to enhance the security associated
with autoenrollment. With strong authentication, the certificate template
uses a specify policy object identifier to require an additional signature
on the certificate request. For example, you can set a policy that requires
the use of a smart card to provide a stronger authentication method for
autoenrollment requests, or you can require approval for automatic
certificate requests, so that administrators must approve pending
requests.
However, in general:

For routine and high volume certificates, such as e-mail certificates, automatic approval is the
best option for certificate approval as long as the certificate requester has already been
authenticated with a valid set of domain credentials.

When a high degree of administrative oversight is required, such as for software code signing
certificates, consider processing certificate requests manually. By using the Certificate Request
Wizard, you can evaluate every certificate request individually — or you can delegate this
responsibility to another administrator.
Selecting an Enrollment and Renewal User Interface
The user interface that you select for certificate request and approval processing depends on whether you choose
automatic or manual certificate request and approval methods. If you decide to use autoenrollment for both
certificate requests and certificate approval, you must use a minimal user interface.
816 Chapter 16 Designing a Public Key Infrastructure
However, if all or part of the enrollment process is manual, you must decide between using the Web Enrollment
Support pages or the Certificate Request Wizard. The Web Enrollment Support pages are the easier interface for
users to use. Users can perform the following tasks from the Web Enrollment Support pages:

Request and obtain a basic user certificate.

Request and obtain other types of certificates by using advanced options.

Request a certificate by using a certificate request file.

Renew certificates by using a certificate renewal request file.

Save a certificate request to a file.

Save the issued certificate to a file.

Check on pending certificate requests.

Retrieve a CA certificate.

Retrieve the latest certificate revocation list from a CA.

Request smart card certificates on behalf of other users (for use by trusted administrators).
However, administrators might prefer to use the Certificate Request and Renewal Wizard. You can start the
wizard from the Certificates snap-in. Because the wizard is linked to the Certificates snap-in, you can also create
custom snap-ins that you can distribute to certification authority administrators to whom you have delegated
specific roles.
Unless an organization uses firewalls between one part of the organization and another, you can use the
Certificates snap-in or the Web interface interchangeably. If a firewall exists between the CA and the requesting
client, you must request certificates by means of the Web Enrollment Support pages or ensure that port 135 and
a dynamic port above 1024 is open for MMC DCOM communication.
Whether you choose to use the Web Enrollment Support Pages or the Certificate Request and Renewal Wizard,
you might need to prepare documentation that describes how users can request a user certificate, what users can
expect after they request the certificate (for example, automatic enrollment or a delay pending administrator
approval), and how they can use the certificates after they receive them.
Creating a Certificate Management Plan 817
Using CA Certificate Renewal
When a CA has issued and supports a large number of certificates, the quality of service and user satisfaction
can decline. However, enrollment and renewal are relatively infrequent activities that can be anticipated and
therefore planned for well in advance. Many organizations fail to plan for certificate renewal because this
activity does not occur until some point well into the future.
When the certificate of a CA expires, the CA can no longer provide certificate services. To provide
uninterrupted certificate services, use the Certificates console to renew the CA certificate before its expiration
date. The interval that is required for CA renewal depends on the certificate lifetime of the CA.
After you renew a CA, the CA continues to issue certificates by using the new CA certificate, and the cycle
starts over. Unexpired certificates that were issued by the pre-renewal CA continue to be trusted until they
expire or are revoked.
You can use the standard enrollment and renewal methods that are available in Windows Server 2003 to renew
your CAs and certificates. You can renew certificates with the same private key and public key set or with new
private and public keys. However, if you have special needs, you can develop custom certificate enrollment and
renewal applications for CAs.
Caution
Do not renew certificates with the same private and public key sets if the
renewal period exceeds the maximum safe key lifetime. The safe key
lifetime is based on your choice of key lengths. Longer keys allow for
longer safe key lifetimes.
The Windows Server 2003 Certificate Services Entry module supports industry-standard certificate requests by
using remote procedure call (RPC) requests or HTTP requests. You can develop custom applications that make
certificate requests to Certificate Services CAs. For more information about developing custom applications on
Windows Server 2003 Certificate Services, see the Microsoft Platform SDK link on the Web Resources page at
http://www.microsoft.com/windows/reskits/webresources.
818 Chapter 16 Designing a Public Key Infrastructure
Mapping Certificates to User Accounts
After you have decided how you are going to distribute your certificates, you must decide how to get the
certificates to the intended clients, whether they are computers, internal users, or external users. You need to use
certificate mapping for many types of certificates, such as those used for smart card logons.
If you have Active Directory, you can map certificates to clients based on their domain or organizational unit
membership.
You must decide how you define subject and issuer name information in certificates because this directly
impacts applications that use PKIs. For example, if a certificate does not contain the e-mail address name as part
of the Subject or Subject Alternative name, some older e-mail applications cannot accept the certificate for
digitally signing or encrypting e-mail messages.
Certificate mapping allows you to provide a more secure method for user authentication. With certificate
mapping, you link a specific certificate to the account of a user. A server application can then use public key
technology to authenticate the user by means of this certificate.
When certificate mapping is enabled, users are authenticated in Active Directory on the authority of the mapped
certificates, and are granted rights and permissions based on the authentication.
You can map certificates to user accounts in the following ways:

One-to-one mapping. This creates an association between an individual certificate and a
corresponding user account in Windows 2000 or Windows Server 2003.

Many-to-one mapping. This creates an association for all certificates from a specific CA to a
Windows 2000 or Windows Server 2003 user account.
You can also use certificate mapping to authenticate external users who do not have an account in Active
Directory.
Using One-to-One Mapping
One-to-one mapping requires more administrative effort than many-to-one mapping. Use one-to-one mapping
when you have a relatively small number of clients. If you decide to use one-to-one mapping for a large number
of clients, develop custom Web enrollment pages by using Active Server Pages (ASP) technology to automate
the mapping process.
Creating a Certificate Management Plan 819
Using Many-to-One Mapping
Many-to-one mapping is useful for authenticating large numbers of users who require access to a given resource
on your network, such as an internal Web site. The CA that issues certificates to these users must be chained to
a trusted root for your site, domain, organizational unit (OU), or forest. You can then set rules that map all
certificates issued by that CA to a single user account in Windows Server 2003.
Mapping rules check the information that is contained in the certificates of users, such as user organization and
the issuing CA, to determine whether the information matches certain criteria. When the information in a user
certificate matches the criteria, the user is mapped to a specified user account. The permissions set on the user
account apply to all users who hold certificates issued from the trusted CA.
You can use separate many-to-one certificate mappings for different groups that require access to resources on
your network. You can configure user accounts that grant different sets of rights and permissions on the basis of
client ownership of valid certificates that match the mapping rules. For example, you can map your employees
to a user account that grants read access to the entire Web site. Then, you can map consultants and employees of
business partners to other user accounts that allow access only to non-confidential information and selected
proprietary information.
Selecting IIS vs. Active Directory Mapping
You can use either Internet Information Services (IIS) or Active Directory to create your mapping. When IIS
does the mapping, the certificate is compared to a list of rules that IIS maintains in its database until it finds a
rule that matches the account indicated. You can configure IIS mapping for each Web server. This type of
mapping is useful if you need only a limited number of mappings or a different mapping on each Web server.
In Active Directory mapping, when the IIS server receives a certificate from the user, it passes it on to Active
Directory, which maps it to a Windows 2000 or Windows Server 2003 user account. The IIS server then logs on
the account.
You can create an Active Directory mapping in one of two ways. You can rely on UPN mapping, or, if UPN
mapping is not possible, you can manually map a certificate to the account of a user.
Use Active Directory mapping when the account mappings are identical on all IIS servers. Active Directory
mapping is easier to maintain than IIS mapping because you only have to create the mapping in one location.
For more information about creating a mapping, see “Mapping certificates to user accounts” in Help and
Support Center for Windows Server 2003.
820 Chapter 16 Designing a Public Key Infrastructure
Establishing Certificate Revocation Policies
All certificates have specified lifetimes. However, in some situations, you might need to invalidate a certificate
before it has reached the end of its lifetime. Creating policies for certificate revocation involves the following
tasks:

Defining the conditions that warrant the revocation of a certificate.

Selecting a certificate revocation list publication location.

Selecting the type or types of CRLs that you intend to use.

Establishing schedules for the publication of CRLs.

Establishing a cached CRL validity period.
Defining Conditions for Certificate Revocation
Not all PKIs need to be supported by the publication of CRLs. For example, if your certificates provide only a
low- or medium- level of security and are unlikely to be misused, or if they have short lifetimes, there might not
be a need to create and distribute lists of revoked certificates. If, on the other hand, your certificates have a high
perceived value and a lifetime that is long enough to cause potential misuse, you need to create and distribute
certificate revocation lists on a regular basis.
Before you create certificate revocation schedules, define all the circumstances that justify the revocation of
certificates in your organization. For example, you might choose to revoke certificates for any of the following
reasons:

An unauthorized user has gained access to the private key of the certificate.

An unauthorized user has gained access to the CA. In this case, all the certificates that the CA
has published must be revoked and reissued.

Certificate criteria have changed; for example, an employee has moved to a different
department.

The certificate has been superseded. For example, you might decide to use a different
encryption protocol or a longer key.
Creating a Certificate Management Plan 821

The CA that issued the certificate is no longer operating.

The status of the certificate is on hold. When a certificate has been revoked, it cannot be
renewed. However, if the status of a certificate is questionable, you can revoke it and then
rescind the revocation if necessary, or re-revoke it for another reason.
Note
Use Certificate Hold sparingly because issues can develop involving the
period that the certificate was on hold. For example, if a certificate was
on hold for three hours but the hold is then removed, attempts to use the
certificate during the hold period can yield unexpected results.

Users misuse their security permissions or the private keys of users are compromised (a smart
card is lost, for example).

A computer is replaced or permanently removed from service, or the private key of the
computer is compromised.
Note
A root certificate cannot be revoked by means of a CRL because a root
CA is self-signed. A CRL includes only certificates that are issued by a
dedicated CA. The alternative is to revoke all the certificates issued by
the root CA. The CA certificate becomes obsolete if there are no more
valid certificates.
Selecting a CRL Publication Location
Selecting a location for CRL publication involves answering the following questions:

Are the certificate revocation lists needed internally, externally, or both?
CRLs have to be published where they can be accessed to validate or invalidate certificates. If
the PKI is within the firewall of the organization and certificates are published to Active
Directory, then LDAP can be used to publish CRLs. If the certificates are used outside the
organization or if there is no directory service, http can be used to publish CRLs to a Web
server because HTTP traffic can travel more reliably through a firewall than LDAP traffic.

Do you require multiple CRL publication locations for fault tolerance or to support greater
numbers of geographically diverse clients?
If the answer is yes, choose the domain controllers and Web servers that provide you with
greater coverage and improved response times. This way, if one CRL publication point
becomes unavailable, the information is available from other publication points.
Figure 15.19 shows this decision process.
822 Chapter 16 Designing a Public Key Infrastructure
Figure 15.19 Selecting a CRL Publication Location
Selecting a CRL Distribution Point
Because CRLs are valid only for a limited time, PKI clients need to retrieve a new CRL periodically. Windows
Server 2003 PKI applications look in the CRL distribution point extension for a URL that points to a network
location from which the CRL object can be retrieved. Because CRLs for enterprise CAs are stored in Active
Directory, they can be accessed by means of LDAP. In comparison, because CRLs for stand-alone CAs are
stored in a directory on the server, they can be accessed by means of HTTP, FTP, and so on as long as the CA is
online. Therefore, you should set the CRL distribution point after the CA has been installed.
The system account writes the CRL to its distribution point, whether the CRL is published manually or is
published according to an established schedule. Therefore you must ensure that the system accounts for CAs
have permission to write to the CRL distribution point.
Because the CRL path is also included in every certificate, you must define the CRL location and its access path
before deploying certificates. If an application performs revocation checking and a valid CRL is not available on
the local computer, it rejects the certificate.
Creating a Certificate Management Plan 823
You can modify the CRL distribution point by using the Certification Authority MMC snap-in. In this way, you
can change the location where the CRL is published to meet the needs of users in your organization. You must
move the CRL distribution point from the CA configuration folder to a Web server to change the location of the
CRL, and you must move each new CRL to the new distribution point, or else the chain will break when the
previous CRL expires.
Note
On root CAs, you must also modify the CRL distribution point in the
CAPolicy.inf file so that the root CA certificate references the correct
CDP and AIA paths, if specified.
If you are using certificates on the Internet, you must have at least one HTTPs-accessible location for all
certificates that are not limited to internal use.
Selecting a CRL Type
Windows Server 2003 includes two types of CRLs: base CRLs and delta CRLs. Base CRLs include a complete
list of revoked certificates, and therefore they can grow quickly in organizations that issue a large number of
certificates. Because updating base CRLs consumes a large amount of network bandwidth, you must weigh the
benefits of publishing expired certificates against the costs in terms of time and network resources. Base CRLs
must be published frequently to ensure that they remain current.
Delta CRLs enable you to simplify CRL management. A delta CRL contains information only about the
certificates that have been revoked after the last base or delta CRL was published; therefore the data in a delta
CRL is accurate throughout its lifetime. Because delta CRLs are smaller than base CRLs, they require less
bandwidth to replicate across the network, and they can be published more frequently, thereby enhancing the
security of your PKI. By combining base and delta CRLs, you can maximize the effectiveness of the CRLs in
your organization and reduce the management effort required.
Whether to use delta CRLs in conjunction with your base CRLs depends on the following factors:

Compatibility. Only Windows XP clients can recognize delta CRLs.

Volume. If you revoke a large number of certificates, your delta CRLs can approach base CRLs
in size. Therefore, it is not useful to use delta CRLs when large numbers of certificates are
revoked between base CRL publication dates.

Online status. It is best if delta CRLs are not used with offline CAs.
Figure 15.20 shows the process for selecting a CRL type.
824 Chapter 16 Designing a Public Key Infrastructure
Figure 15.20 Selecting a CRL Type
Establishing a CRL Publication Schedule
CAs publish CRLs listing the serial numbers of certificates that have been revoked according to an established
publication schedule. The frequency of publication is based on the number of changes that take place in a given
period of time, and how critical the need to maintain up-to-date revocation information is to your organization.
As you create your CRL policies, you need to specify publication schedules for CRLs. By default, enterprise
CAs publish CRLs weekly to Active Directory, and stand-alone and enterprise CAs publish CRLs weekly to a
directory on the CA server. For example, you can specify that certain CRLs are distributed to Web pages as well
as to Active Directory, and that certain CRLs are published daily instead of weekly.
If you use delta CRLs, a typical publication schedule might look like this:

Publish base CRLs every week.

Publish delta CRLs every day.
Creating a Certificate Management Plan 825
The CRL schedule for the certificates of your issuing CA must account for potential network and server
downtime. In addition, it must account for latency in Active Directory replication. For these reasons, make the
CRL publication schedule longer than the maximum replication latency.
Make sure that your publication schedule is shorter than the validity period of the CRL. With a validity period
of one week, your CRL will be up-to-date for most purposes. If you require an additional buffer to protect
against interruptions in communications, you can publish the CRL every two days.
Your strategy for renewing CAs also impacts your CRL publication strategy. If you choose to reuse the existing
key pair when you renew a certificate for a CA, the existing CRL covers certificates issued under both the old
and new CA certificates. If you choose to renew certificates by using a new key pair for the CA, you need to
issue one CRL for the certificates issued with the old key pair, and another CRL for certificates issued with the
new key pair. Although both old and new certificates were issued by the same CA, the validity of the older
certificates will be validated against one CRL, and the validity of the newer certificates will be validated against
the other CRL.
Note
CRLs are published for all CA keys. You cannot selectively publish a
CRL for only one CA key pair.
Setting the Cached CRL Validity Period
To reduce the amount of network bandwidth needed to retrieve CRLs, the CRL that is specified in the CRL
attribute of the certificate is cached on the client system using the certificate. You can control the schedule by
which the client retrieves updated CRLs by setting the CRL lifetime.
CRL publication and client use of the most recent CRL are independent. The client does not retrieve a new CRL
from its distribution point unless the lifetime of a matching cached CRL has expired. Therefore, when you set
the CRL validity period, be sure to balance the intended and actual CRL lifetime.
The only way to force a client to retrieve the latest CRL from the CRL distribution point before the CRL cache
on the client has expired is by clearing the CRL cache — a task that is difficult to perform in many networks.
826 Chapter 16 Designing a Public Key Infrastructure
Planning for Data Recovery and Key
Recovery
If public key pairs and certificates are lost due to system failure, it can be time consuming and expensive to
replace them and the data that they protect. For this reason, as part of your certificate management plan, you
need to evaluate the potential consequences of loss of public keys and the data that they secure, and create a
strategy for data and key recovery.
Data recovery is a process by which data is encrypted in such a way that more than one person can retrieve the
data in plaintext form. Data recovery does not always imply that private key recovery has occurred; however,
key recovery is one method for data recovery.
Use data recovery if you need to be able to recover data in your organization, but do not need to have access to
individual private keys of users.
The advantages of data recovery include:

It does not require a certification authority or PKI infrastructure.

Data recovery policies can be managed centrally by means of Active Directory.

Users do not have to manage certificates or private keys for data recovery.

Decryption can be limited to the user alone.
The disadvantages of data recovery include:

An administrative process must recover user data. Users cannot recover their own data.

You cannot define the scope of what data can be recovered by a data recovery agent and what
data cannot be recovered by a data recovery agent.

Data recovery occurs manually on a file-by-file basis.

Only data is recovered, and not the user keys. Therefore, after data recovery is completed, the
user must re-enroll for new certificates.

It is assumed that, when a key is lost, the certificate is compromised. Therefore, administrators
must revoke old certificates.

Stand-alone workstations or workstations in non-Active Directory environments cannot be
centrally managed.
Key recovery allows a trusted agent to gain access to user private keys. For this reason, it is best to use key
recovery only if your organization permits a person other than the original requester to have access to the private
key of another user.
Creating a Certificate Management Plan 827
Use key recovery if organization policy permits the retrieval of user private keys and certificates. Key archiving
and recovery implies that a person such as an administrator can gain access to the private keys of another user.
Even when policies and procedures are in place to protect against unauthorized key recovery, issues with nonrepudiation might still exist. If your organization does not permit a person other than the original requester to
have access to the private keys of another user, do not implement key archival and recovery.
The advantages of key recovery include:

Users do not have to re-enroll for certificates, change security settings, and so on.

Existing certificates do not have to be revoked.

Users do not have to recover any data or e-mail due to lost private keys.

All data encrypted by means of a public key in a certificate can be recovered after a private key
has been recovered.

Windows Server 2003 does not accept signing keys for archival and recovery.
The disadvantages of key recovery include:

User key recovery is a manual process that must be performed by administrators and users.

Key recovery allows administrative access to the private keys of users.

Non-repudiation assurance might not be available with key archival and recovery.

Key recovery does not work with hardware security tokens such as smart cards.
Note
Only a Windows Server 2003 Enterprise Edition CA can implement
Windows Server 2003 key recovery.
Windows Server 2003 includes a new certificate template to support the key recovery agent role. A Windows
Server 2003 CA can use only key recovery agent certificates that have been properly formatted and that have
not expired. To enable key recovery, you need to complete the following tasks:

Configure the key recovery agent template.

Configure the CA to allow key archiving.

Enroll and archive users.
Do not use either data recovery or key recovery if your organization wants to protect data from all parties except
for the original user.
828 Chapter 16 Designing a Public Key Infrastructure
Configuring the Key Recovery Agent Certificate
Before you configure a key recovery agent certificate, you must decide which users or groups can have Read
and Enroll permissions on the key recovery agent certificate template. By default, only an Enterprise
Administrator or a Domain Administrator can request a key recovery agent certificate. If you choose to change
these defaults, you need to configure the new Read and Enroll permissions on the template itself.
You must configure an enterprise CA to issue key recovery agent certificates.
When you have configured permissions on the key recovery agent template and authorized an enterprise CA to
issue key recovery agent certificates, a user with the appropriate permissions can request a key recovery agent
certificate.
You must also select an encryption key length for the key recovery agent certificate. An encryption key of 2,048
bits satisfies most security needs. Keys that are 8,192 bits or larger can take the client CSP several hours to
generate and can slow down public key operations on the CA when keys are archived.
You must mark the keys as exportable to enable the key recovery agent to export the private keys from the local
store of the workstation to a floppy disk or other medium for safe storage. It is also best to protect the key
recovery agent certificate private key with a strong password requirement. You can use a smart card as a key
recovery agent.
The default key recovery agent certificate template requires manual approval of requests for key recovery agent
certificates. It is best if a certificate manager manually approves all key recovery agent certificate requests. The
certificate manager might choose to use fewer key recovery agents than the number of available key recovery
agent certificates. In this way, no individual key recovery agent can decrypt all the private keys in the CA
database. The CA chooses the key recovery agent certificate randomly as a means to ensure that the key
recovery agent selection is not predictable.
Several cautions apply to key archiving. First, the default templates in Windows Server 2003 do not allow for
key archiving. You must create new version 2 templates, which are available only in Windows Server 2003,
Enterprise Edition, to support user enrollment with archiving.
Second, although you can configure the cryptographic service providers that are used for the private keys that
are to be archived, you can only archive keys that are generated by means of a Rivest-Shamir-Adleman (RSA)based CSP. The Digital Signature Standard (DSS) and Diffie-Hellman CSPs are not supported for key
archiving.
Creating a Certificate Management Plan 829
Establishing Key Recovery Agent Policies
Allowing someone other than the original user to recover keys presents a security risk. Although you trust your
administrators, there are limits to how much any individual can be trusted with the ability to recover other the
key pairs of other users. For example, your key recovery agent might leave the organization, taking a copy of
the key. Therefore it is recommended that you monitor key recovery plans carefully.
Consider limiting the time that any one individual serves as the key recovery agent, or consider dividing the
responsibility between several individuals and requiring that a smart card be used to perform key recovery tasks.
In addition, employ the following key recovery strategies:

If you know that a key has been compromised, revoke it immediately.

Do not recover keys or certificates that are used to secure high-value transactions or are
associated with high-value certificates.

Do not archive or recover private keys that are used for signing. This creates uncertainty in
situations in which non-repudiation is the primary concern.
If possible, recover encryption keys only after the original certificates have been revoked. Issue a new key at the
time of recovery. Revocation ensures that the user can still decrypt data with the old key but cannot encrypt new
data.
Educating Users
Although the process of certificate enrollment and use is nearly transparent to end users, it is important to
educate users about certificates and their use. Specifically, be sure to provide end users with the following
information:

How to use the certificate enrollment user interface and certificate-enabled applications.

The capabilities of certificates.

The limitations of certificates.

Inappropriate or ineffective uses for certificates.

How to evaluate certificates received from others.

The importance of retaining expired certificates.

What to do in the event of an error message or if certificates fail to function as expected.
830 Chapter 16 Designing a Public Key Infrastructure
Example: Creating a Certificate
Management Plan
A PKI cannot be effective and secure unless an organization implements a management plan that includes
strategies for enrolling and renewing certificates, mapping certificates to user accounts, revoking certificates and
distributing CRLs, and using key recovery.
Many organizations base their certificate enrollment and renewal methods on the level of security associated
with each type of certificate and the volume of certificate requests that they anticipate. For example, an
organization makes the following decisions regarding certificate enrollment and renewal:

Autoenrollment is the preferred enrollment method for e-mail and EFS certificate requests,
which represent the majority of their certificate activity. Only clients who have already been
authenticated by the network can request these certificates. The risks associated with the use of
these certificates are relatively low.

Manual approval is required for all certificates that are needed to perform network
administration and software development.

Manual approval is required for certificates that are issued to joint venture partners.
The basic user certificates of the organization (for e-mail and EFS) are distributed according to the domain
membership of a user.
The distribution of high-security certificates is enforced with a one-to-one mapping. This is intended to further
enforce the usage restrictions that have been placed on these certificates. Also, to improve the ability of the
organization to define which file shares and other resources are available to their joint venture partners, a manyto-one mapping to a single account in Active Directory restricts their joint venture certificates.
Similarly, organizations are concerned about the timeliness of CRLs associated with their high-security
certificates. Therefore, they decide to distribute CRLs for these CAs once a day, with delta CRLs published
every two hours, or as needed. Because network bandwidth and replication can impact the distribution of CRLs
and delta CRLs to their remote offices, they choose a less stringent publication schedule for their medium
security CAs — new CRLs are published once a week, and delta CRLs are published at the close of every
business day. Publishing at the end of the business day ensures that the updated information is replicated
overnight and is available on the next business day.
Deploying the PKI
After your public key design has been validated and refined by lab testing and pilot programs, you can deploy
the PKI in your production environment. A disciplined approach to deploying a PKI is absolutely essential in
order to establish the security of the applications that you are enabling. Figure 15.21 shows the PKI deployment
process.
Deploying the PKI 831
Figure 15.21 Deploying the PKI
Important
Advanced planning is critical to the success of your PKI. Therefore, it is
strongly recommended that you complete your PKI design before you
deploy your PKI.
832 Chapter 16 Designing a Public Key Infrastructure
Schedule Production Rollout
For large enterprise deployments, schedule the public key production rollout in stages. You can roll out different
portions of the infrastructure at different times as necessary to support your security goals and business needs.
For example, you might begin by deploying EFS and IPSec because you do not have to establish a large CA
hierarchy to take advantage of the security benefits of these features. You might place the next highest priority
on secure mail and smart card authentication. You can schedule the rollout of the secure mail infrastructure
before rolling out the smart card infrastructure, or you can choose to schedule the deployment of secure mail to
one group or site and simultaneously roll out the smart card infrastructure to another group or site.
Important
In many organizations, responsibility for the PKI deployment is
transferred from a high-level design team to a more tactically focused
implementation team at this time. If this is the case in your organization,
be sure to provide the implementation team with all the documentation,
including worksheets that you have created up to this point.
Install Certification Authorities
Most organizations require a CA hierarchy to provide the required certificate services to meet their security and
business needs. If you plan to use a CA hierarchy, you must install the root CA first and then install each
subordinate CA in the hierarchy. For example, to create a three-level CA hierarchy and trust chain, install CAs
on server computers in the following order:
1.
Root CA
2.
Intermediate CAs
3.
Issuing CAs
For more information about installing CAs, see “Installing and configuring a certification authority” in Help and
Support Center for Windows Server 2003.
Install Offline Root CAs
In addition to the configuration options that you selected for your offline root CA, configure the following
options when installing your offline root CA:

Select Certificate Services Web Enrollment Support. Hosting the Web Enrollment service
for an Offline Root CA on a separate system forces you to run both systems during the
enrollment or renewal of subordinate CAs, which requires you to enable network connectivity
between the two systems at that time.
Deploying the PKI 833

In the Public and Private Key Pair dialog box, leave the default CSP selection (Microsoft
Strong Cryptographic Provider) and default Hash selection (SHA-1). Increase the Key length
to meet your needs — for most root CAs, use the largest interoperable key length (4,096 bits).
Note
For the purposes of Microsoft CAs, the Strong and Enhanced CSPs are
considered equivalent. Both provide support for large key lengths (1024bit keys or greater). Also, it is recommended that you use a hardware
cryptographic service provider (CSP) or Hardware Security Module
(HSM) to enhance the security of the signing keys of the certification
authority.

If you are installing a stand-alone CA as the root CA, the CA identification data must be
entered manually. If you plan to publish the root CA certificate and CRL in your Active
Directory environment, you have to enter the namespace of your Active Directory forest as the
distinguished name suffix. In the CA Identifying Information dialog box, enter a customized
distinguished name if you plan to publish your offline CA to a directory other than Active
Directory. Use a customized distinguished name if you plan to use the offline CA as a trust
anchor outside the enterprise.
Note
The Common name for this CA field must be filled in, but the
customized field distinguished name suffix is optional. Your common
name and distinguished name for the CA must reflect the organization
and purpose of the CA to make the CAs easy for administrators and
users to identify. The name of the CA must be unique within the
organization, and possibly outside the organization as well. This
information is filled in automatically if your CA is joined to an Active
Directory–based domain.

When you are asked to enter the Data Storage Locations, format the paths as local paths (such
as C:\WINDOWS\System32\CertLog).
Note
Although it is generally good practice to place the Certificate Database
and Certificate Database log directories on a separate volume from the
system partition, you do not need to do this for a root CA. The only data
that is generated and must be stored concerns the certificates that
correspond to a few subordinate CAs.
834 Chapter 16 Designing a Public Key Infrastructure
Install Intermediate and Subordinate CAs
When installing Windows Server 2003 intermediate and issuing CAs, you can request the CA certificate from
an online CA, or you can save the certificate request to a request file and make the certificate request offline. If
you make an offline CA certificate request, the CA is not valid immediately upon installation. You must use the
Certification Authority MMC snap-in to import the certificate of the CA and complete the installation process
after the parent CA signs the CA certificate. You can also use the Certification Authority MMC snap-in to
import subordinate CA certificates that are issued by third-party parent CAs.
Publish the Offline CA Certificate
Use secure procedures to publish the certificate and certificate revocation list (CRL) of the offline root CA. You
only need to publish the certificate of the root CA one time. However, the CRL for the root CA must be
published at regular intervals that correspond to the CRL publication interval value configured in the Revoked
Certificates Properties of the root CA.
If the root CA is maintained in a secure location, such as a data center or vault, it is best if more than one
administrator or trusted person publishes the offline CRL within that location, as prescribed in the certificate
policy and certificate practice statements for your organization. After the CRL is published, you must transfer it
manually from the data center or vault to a location where it can be distributed to your CRL distribution points.
Publish the offline CRL at least several days before the previously issued CRL is set to expire. This allows you
to correct any hardware problems or publication failures in advance, ensuring that no interruption in service
happens when your offline CRLs are published and replicated to all CDP locations.
After the offline root CA is installed, configure the various constraint and policy options for certificates that the
offline CA issues. These extensions are necessary to ensure that the applications and clients that use the
certificates in the hierarchy can perform revocation and chain building as needed.
Apply CA Policy
If you intend to implement your certificate practice statement, you need to create and format a issuer policy
statement file, and place this file in the %windir% path of the root or subordinate CA before the CA is installed.
This file, named CAPolicy.inf, serves two purposes:

It provides basic information about the root CA, such as distribution points for the self-signed
certificate, and the object identifier (also known as OID) information.

It includes information for certificate renewal, such as the certificate lifetime of the self-signed
certificate.
Deploying the PKI 835
CAPolicy.inf is processed for root CA and subordinate CA installations and renewals. The CDP and AIA
extensions in CAPolicy.inf are used for root CA installations and renewals only. Subordinate CA certificates
inherit the CDP and AIA extensions of the issuing parent CA.
The CPS statement extension is applied when root CA certificates and subordinate CA certificates are requested.
The CAPolicy.inf mechanism can only be used to include a CPS statement extension in a CA certificate and not
an end-client certificate.
Important
When CAPolicy.inf is used to install a CA, it must also be used for
renewal; otherwise, the settings that have been defined might not be
retained when the CA keys are renewed.
For more information about creating and using CAPolicy.inf files, see “Installing and configuring a certification
authority” in Help and Support Center for Windows Server 2003.
Configure CDP and AIA Extensions
After a root or subordinate CA is installed, you must configure the Authority Information Access (AIA) and
CRL distribution point (CDP) extensions before the CA issues any certificates. The AIA extension specifies
where to find up-to-date certificates for the CA. The CDP extension specifies where to find up-to-date CRLs
that are signed by the CA. These extensions apply to all certificates that are issued by that CA.
Configuring these extensions ensures that this information is included in each certificate that the CA issues so
that it is available to all clients. This ensures that PKI clients experience the least possible number of failures
due to unverified certificate chains or certificate revocations that can result in unsuccessful VPN connections,
failed smart card logons, or unverified e-mail signatures.
Follow these guidelines when configuring CDP extension URLs:

Avoid publishing delta CRLs on offline root CAs. Because you do not revoke many certificates
on an offline root CA, a delta CRL is probably not needed.

Adjust the default LDAP:/// and HTTP:// URL locations on the Extensions tab of the
certification authority Properties page according to your needs. Do not remove the local CDP
location, however. The CA requires the local CDP location in order to publish the CRL to itself.
The CA uses the local CRL to validate all certificates before they are issued to users. The local
path does not show in the CDP extension of issued certificates.

Enable the publication of delta CRLs, regardless of whether delta CRLs are going to be
published, to allow for the potential use of delta CRLs in the future. Enable delta CRL
publication by selecting the Publish Delta CRLs to this location check box.
836 Chapter 16 Designing a Public Key Infrastructure

Publish both the LDAP and HTTP URLs for CDP locations to enable clients to retrieve CRL
data with HTTP and LDAP. If required, publish a CRL on an HTTP Internet or extranet
location so that users and applications outside the organization can perform certificate
validation.

Consider using Active Directory–based publication. An LDAP certificate revocation list URL
distributed by means of Active Directory is replicated in a fault-tolerant, distributed, highly
available manner. However, replication of CRL data among Active Directory domain
controllers introduces some latency.

For certificates that are to be validated by clients that use Active Directory, place the LDAP
CDP location first in the list to optimize client revocation checking. Windows clients always
retrieve the list of URLs in sequential order until a valid CRL is retrieved.

Provide an additional HTTP CDP location or an alternative LDAP path to CRLs for clients that
cannot use Active Directory or LDAP.
Follow these guidelines when publishing HTTP-based CRLs:

If you are providing an HTTP CDP location, use round robin DNS or Web server virtual names
to provide redundancy in the HTTP URL.

Use HTTP CDP locations to provide accessible CRL locations for non-Windows brand
operating system clients.

Place HTTP CDP URLs second in the list of the URLs in the CDP extension if the CRL is
distributed with Active Directory as well.
Configure Certificate Templates
By default, Windows Server 2003 enterprise CAs are enabled upon installation to issue a variety of types of
certificates. You can use the Certification Authority MMC snap-in to make the following modifications to this
default configuration:

Specify the certificate types that are to be issued by each CA.

Delete any default certificate templates that you do not want the CA to issue from the certificate
templates container.

Add additional certificate templates that the CA can issue.
You can configure CAs to support one or multiple security functions by:

Configuring root or intermediate CAs to issue subordinate certification authority certificates
only.

Configuring an issuing CA that supports secure Web communication services to issue
authenticated session, computer, and Web server certificates only.
Deploying the PKI 837

Configuring an issuing CA that supports general business users to issue user certificates only,
or configuring a CA that supports administrators to issue administrator certificates only.

Configuring an issuing CA that supports smart card enrollment to issue smart card logon and
smart card user certificates only.
The access control lists (ACLs) for each certificate template control the permissions needed to request
certificate types. An enterprise CA grants certificate requests only for users, computers, or services that have the
Enroll permission selected in the ACLs for that certificate template. The ACLs for certificate templates are
preconfigured to enable various default user accounts and security groups to enroll for certificate types.
You can use the Certificate Templates MMC snap-in to modify the ACLs for each certificate template. For
example, by default, only members of the Domain Administrators security group can request and obtain
enrollment agent certificates. However, to specify that only certain members of your security department can
request and obtain enrollment agent certificates, you can change the ACLs for the enrollment agent certificate
template. You can remove domain admins from the ACL and add the appropriate user accounts or security
groups.
For Windows Server 2003 stand-alone CAs, information about the certificate type must be included in the
certificate request because stand-alone CAs do not use certificate templates. You can use stand-alone CAs with
custom policy modules and custom certificate request applications to control the types of certificates that are
issued.
For more information about creating custom policy modules, see the MSDN Online and Microsoft Platform
SDK links on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources.
Configure Public Key Group Policy
You can use the Group Policy MMC snap-in to configure the following optional categories of public key Group
Policy for sites, domains, and organizational units:

EFS Recovery Agents. By default, the local Administrator user account for the first domain
controller installed in the domain is the EFS recovery account for that domain. You can specify
alternate encrypted data recovery agents for EFS by importing into the policy the EFS recovery
agent certificate for the appropriate alternate agent. You must first issue EFS recovery agent
certificates to the user accounts on the local computers that you want to use as alternate
recovery agents.

Automatic Certificate Enrollment. You can specify automatic enrollment and renewal for
computer certificates. When automatic enrollment is configured, the specified certificate types
are issued to all computers within the scope of the public key Group Policy. Computer
certificates issued by means of automatic enrollment are renewed from the issuing CA.
Automatic enrollment does not function unless at least one enterprise CA is on line to process
certificate requests.
838 Chapter 16 Designing a Public Key Infrastructure
In addition, you can use Group Policy to configure a number of CA trust options. Group Policy trust is
configured and enforced within a single domain only. This allows different users in different domains to trust
different root CAs.
When possible, manage trust of third-party root certification authorities by using Group Policy, and limit their
scope by using qualified subordination. Third-party root CAs can be constrained by namespace and purpose to
prevent unwanted trust and namespace violations within the organization.
Group Policy trust configuration is found in the computer policy for \Windows Settings\Security Settings\Public
Key Policies\Trusted Root Certification Authorities. Users inherit policy from the computer policy. You can
enable all computers and users to trust a root CA by adding the root CA certificate to Group Policy.
You can configure the following alternate trust options by selecting the Trusted Root Certification
Authorities node in the Domain Security Policy MMC snap-in:

Enable or disable the ability for users to trust root CAs on a per-user basis. Use this option
to disable users from trusting a root CA outside the Enterprise root trust, Group Policy, the
default computer store root CA list, and the list of root CA certificates provided by Windows
Update.

Allow both Enterprise CA trust and third-party CA trust or only Enterprise root trust.
You can disable trust of third-party root CAs in the domain outside the enterprise root CA trust,
including root certificates downloaded from the Windows Update. This disables user
installation of root CA certificates.
Note
Disabling third-party CAs can impact user access to applications such as
SSL-secured Web sites.
Configure CRL Publication
When you have updated the CDP extensions on the CA, you need to publish a new CRL so that all clients can
access the new CRL data. For more information about configuring CRL publication, see “Manage certificate
revocation” in Help and Support Center for Windows Server 2003.
Deploying the PKI 839
Modifying the Default Certificate Publication Period
Certificates that are revoked prior to expiration remain in a published base CRL for one full base CRL period
(defined by the CA) after they expire. Certificates that expire are no longer included in published CRLs after
one additional base CRL expires.
Although applications do not check CRLs for certificates that have expired, you might in some cases want to
maintain a public list of signing certificates that have been revoked. You can enable a registry setting on a CA to
ensure that revoked certificates that have expired are not removed from the CRL.
To modify the default CRL publication period for revoked and expired
certificates on a CA

At the command prompt, type:
certutil –setreg ca\CRLFlags +CRLF_PUBLISH_EXPIRED_CERT_CRLS
Ensuring Application Reliability
Many applications rely on CRL availability and fail if the CRL is inaccessible or out-of-date. Follow these
guidelines when publishing CRLs to ensure the reliability of your applications:

Configure the CRL to be valid for a long enough period of time to allow for the recovery of the
CA if there is a hardware or software failure.

Set a reasonable CRL overlap period to protect against CRL publication or replication failures.

Keep the private key of the CA and a copy of the CRL in a secure offline location so that you
can sign and publish a valid CRL manually by using Certutil.exe when a catastrophic failure
occurs.

Use Active Directory to publish CRLs whenever possible. This maximizes availability and
network performance. However, always consider the amount of time needed to replicate Active
Directory data between domain controllers.

Do not publish CRLs to Active Directory when the CRL publication period is shorter than the
replication convergence time for the Active Directory forest.

To prevent the use of a logon certificate, disable the account in Active Directory.
840 Chapter 16 Designing a Public Key Infrastructure
Controlling CRL Size
You can partition a base CRL to control its size. In this way, you can control the amount of data that is
replicated to Active Directory and the size of the data object that clients download when they perform
revocation checks on certificates. You partition base CRLs by renewing the CA key. This creates a partitioned
CRL for all certificates that are issued after the key is renewed.
The CRL increases by about 29 bytes for every certificate that is revoked, depending on the reasons that you
specify for the revocation. You might want to use a new key to renew the CA every time it reaches 100125 kilobytes (KB) in size, to minimize download times. This strategy is based on the assumption that
approximately 10 percent of the certificates that you issue are revoked before their natural expiration date. If
your actual or planned revocation rate is higher or lower than this, adjust your key renewal strategy as needed.
Removing Expired CRLs
By default, a CA maintains an expired CRL in the database and keeps it in the directory at the last known CDP
publication point.
As soon as the key for a CA expires, the CRL is published a final time and no additional changes are made to
that CRL. It is recommended that you maintain this CRL in the CA database to allow for long-term validation
and auditing. You can, however, remove the CRL to clean out the database.
To remove a CRL after a CA key expires

At the command prompt, type:
certutil –setreg ca\CRLFlags + CRLF_DELETE_EXPIRED_CRLS
Delegate CA Administration
Before you begin to issue certificates, you need to delegate CA administrator roles. For information about
defining CA administrator roles, see “Defining PKI Management and Delegation” earlier in this chapter.
You can assign CA Administrator and Certificate Manager permissions by using the Certification Authority
MMC snap-in. Other roles, users, and groups are specified in the consoles used to perform particular tasks, such
as Certificate Templates and Certificates. To change the roles of a user, you must change the security
permissions, group membership, or rights of the user.
Deploying the PKI 841
Configure Certificate Enrollment and
Renewal
Microsoft Certificate Services supports a variety of enrollment and renewal methods, such as the Certificate
Request Wizard or the Microsoft Certificate Services Web pages. However, if you deploy third-party certificate
services or custom certificate enrollment and renewal applications, you must perform any configuration required
for those services and applications.
Issue Certificates
You can issue certificates to users, computers, and services after the required certificate services are installed
and configured. Keep the following considerations in mind when you start to issue certificates:

Certificates are issued for computers within the scope of the Automatic Certificate Request
settings of the Group Policy. Domain Administrators can also manually request certificates for
local computers by using the Certificate Request Wizard or the Microsoft Certificate Services
Web pages. Consider scheduling manual enrollment in stages to help distribute the
administrative workload for computer enrollment.

Smart card administrators can start issuing smart card certificates by using the Smart Card
Enrollment Station available on the Microsoft Certificate Services Web pages. Consider
scheduling smart card enrollment in stages to help distribute the administrative workload for
smart card enrollment.
During the transition to smart cards, both smart card authentication and interactive logon with domain
credentials should be enabled. Because this weakens network security, configure user account policy to require
smart cards for interactive logon as soon as smart card users are trained and are using their cards.
Monitor the performance of certificate services closely as you start issuing certificates to ensure that CAs handle
the certificate load. To correct excessive load conditions, consider adding more issuing CAs or scheduling
certificate enrollment in smaller stages. Certificate renewal might also produce excessive load conditions.
Adding more CAs and scheduling certificate enrollment in smaller stages can also help distribute peak renewal
loads.
842 Chapter 16 Designing a Public Key Infrastructure
Additional Resources
These resources contain additional information and tools related to this chapter.
Related Information

The Distributed Services Guide of the Windows Server 2003 Resource Kit (or see the
Distributed Services Guide on the Web at http://www.microsoft.com/reskit) for more
information about public key features in Windows Server 2003 and using certificates in
conjunction with Encrypting File System.

“Deploying Smart Cards” in this book for more information about deploying smart cards.

The Software Development Kit (SDK) information in the MSDN Library link on the Web
Resources page at http://www.microsoft.com/windows/reskits/webresources for more
information about developing CAPICOM and other public key–enabled applications.

The Common Criteria link on the Web Resources page at
http://www.microsoft.com/windows/reskits/webresources for information about the Common
Criteria for Information Technology Security Evaluation.

The National Institute of Standards and Technology (NIST) link on the Web Resources page at
http://www.microsoft.com/windows/reskits/webresources for information about public
standards that apply to public key infrastructures.
Related Help Topics
For best results in identifying Help topics by title, in Help and Support Center, under the Search box, click Set
search options. Under Help Topics, select the Search in title only checkbox.

“Mapping certificates to user accounts” in Help and Support Center for Windows Server 2003
for information about creating a mapping.

“Manage certificate revocation” in Help and Support Center for Windows Server 2003 for
information about configuring CRL publication.

“Installing and configuring a certification authority” in Help and Support Center for Windows
Server 2003 for more information about creating and using CAPolicy.inf files.
Related Job Aids

“Summary of User Certificate Requirements” (DSSPKI_1.doc) on the Windows Server 2003
Deployment Kit companion CD (or see “Summary of User Certificate Requirements” on the
Web at http://www.microsoft.com/reskit).

“Certificate Practice Statement Outline” (DSSPKI_2.doc) on the Windows Server 2003
Deployment Kit companion CD (or see “Certificate Practice Statement Outline” on the Web at
http://www.microsoft.com/reskit).

“Windows Server 2003 Certificate Lifecycle Plan” (DSSPKI_3.doc) on the Windows
Server 2003 Deployment Kit companion CD (or see “Windows Server 2003 Certificate
Lifecycle Plan” on the Web at http://www.microsoft.com/reskit).