20 chapter 16 designing a public key infrastructure

8/2/2019 20 CHAPTER 16 Designing a Public Key Infrastructure

http://slidepdf.com/reader/full/20-chapter-16-designing-a-public-key-infrastructure 1/114

C H A P T E R 1 6

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

Chapter 16...........................................................................................................217

Overview of the PKI Design Process .....................................................................218

Defining Certificate Requirements .......................................................................223Designing Your CA Infrastructure .........................................................................234

Extending Your CA Infrastructure .........................................................................264

Defining Certificate Configuration Options ...........................................................276

Creating a Certificate Management Plan ..............................................................298

Deploying the PKI................................................................................................318

Additional Resources ...........................................................................................330

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.

Designing a Public Key

Infrastructure



218 Chapter 16 Designing a Public Key Infrastructure

Overview of the PKI DesignProcessOrganizations 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.



Deploying the PKI 219

Process for Designing a PKIDesigning 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

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.




Basic PKI ConceptsPublic 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:

Electronic credentials, consisting of public keys, which are used to sign and encrypt

data. Digital certificates provide the foundation of a PKI.

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.

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.

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.

Lists of certificates that have been revoked before reaching the

scheduled expiration date.

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.

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.

Digital certificates

One or more certification

Certificate policy and practice

Certificate

Certificate revocation lists

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




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.

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 PKIYou 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 andreceive 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.

Key archival and

Public key




• 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 RequirementsYou 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 securitythat 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




Determining Secure ApplicationRequirements

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, whilethe 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.




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 standardInternet 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.




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 theInternet. 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 securitycontext to determine what resources the client is allowed or not allowed to use on the server.




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 keyinfrastructure.

For more information about deploying smart cards, see “Deploying Smart Cards” in this book.




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 makesavailable 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.

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.

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.




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 userswho 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).




Documenting Certificate Policies andPractices

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 clientsor 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 thattheir 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).




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).




Example: Defining CertificateRequirements

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.

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.




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.




Designing Your CA InfrastructureTo 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, andflexibility 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




Planning Core CA OptionsBefore 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 CAsA 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 alsoto 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.




Selecting Internal CAs vs. Third-Party CAsDepending 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.




• 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 ScalabilityOrganizations 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.




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.

• 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.

• 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.

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.

Note

Using separate logical disks does not provide any performance

advantages.




The type of hardware that your clients use can also impact performance. When you are selecting or evaluatingthe 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

100-megabit 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.

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.




Integrating the Active Directory InfrastructureYour 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.

• 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 andreplicated throughout the forest as part of the global catalog.

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.

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.




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.

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.




Defining PKI Management and DelegationIt 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. Thisinvolves 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, assignscertificate 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.




Table 15.1 PKI Administrative Roles and Their Corresponding Windows Server 2003

Administrative Roles

PKI AdministrativeRole

DescriptionWindows Server 2003Administrative Role

PKI Administrator Configures, maintains, and

renews the CA.

User

Backup Operator Performs system backupand recovery.

Backup Operator on theserver on which the CA isrunning

Audit Manager Configures, views, andmaintains audit logs.

Local Administrator on theserver on which the CA isrunning

Key RecoveryManager

Requests retrieval of aprivate key stored by theservice.

User

Certificate Manager Approves certificateenrollment and revocationrequests.

User

User Manager Manages users and their associated information.

Account Operators (or person delegated to createuser accounts in ActiveDirectory)

Enrollee Requests certificates formthe 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 Enrollee

CAAdmin

CertificateManager

AuditManager

BackupOperator

LocalServer Admin

Install a CA

Configure aCA

Policy andexit moduleconfiguration

Stop/startservice

Changeconfiguration

Assign user roles

(continued)




Table 15.2 Actions Performed By PKI Administrative Roles(continued)

ActionEnroll

eeCA

AdminCertificateManager

AuditManager

BackupOperator

LocalServer Admin

Establish

user accounts

Maintainuser accounts

Configureprofiles

Renew CAkeys

Define keyrecoveryagent(s)

Defineofficer roles

Enable roleseparation

Issue/Approvecertificates

Denycertificates

Revokecertificates

Unrevokecertificates

Renewcertificates

Enable,publish, or configureCRLschedule

Configureaudit

parameters

Audit logs

Back upsystem

Restoresystem

(continued)




Table 15.2 Actions Performed By PKI Administrative Roles(continued)

ActionEnroll

eeCA

AdminCertificateManager

AuditManager

BackupOperator

LocalServer Admin

Read CA

properties,CRL

Requestcertificate

Read CAdatabase

Read CAconfigurationinformation

Readissued,

Revoked,pendingcertificates

Defining CA Types and Roles

To plan your CA infrastructure, you need to understand the different types of CAs available with WindowsServer 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.

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.




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, stand-

alone 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.

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

Note

You can use both enterprise and stand-alone certification authorities in

your organization.




Table 15.3 Options for Enterprise vs. Stand-Alone CAs

OptionEnterprise

CAStand-alone

CA

Publish certificates in Active Directory and useActive Directory to validate certificate requests.

Take the CA offline.

Configure the CA to issue certificatesautomatically.

Allow administrators to approve certificaterequests 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-aloneCAs, 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”





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.

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 isreplaced 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 CAsSecuring 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.

Note

Most organizations use one root CA and two policy CAs — one to

support internal users, the second to support external users.




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.

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 passwordchanges 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.

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.




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.

Using Hardware CSPsHardware CSPs can support a wide range of cryptographic operations and technologies. Keys stored in tamper-

resistant 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.

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.

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.

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 tonew subordinate CAs.

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 meansof a memory dump.




Determining Number of CAs RequiredAfter 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 distributedfunctionality 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.




• 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 relationshipsor 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.

Selecting a Trust ModelThe 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.

Note

You cannot install more than one CA on a server.




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 ModelIn 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




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.

Network Trust ModelIf 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 CAInfrastructure 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.

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.




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 cross-

certificate.

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.




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.

Hybrid Trust ModelSome 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 IdentificationA 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 usecertificates signed by the root CA in order to issue certificates to users, computers, services, or another CA.

Note

Use a network trust model only in conjunction with name constraints.

For more information about name constraints, see “Name Constraints”





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 statingthat the individual is not a full-time employee.

Trust Hierarchy Based on Organizational StructureAlthough 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




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 LocationSome 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.




Defining CA Roles in the Trust HierarchyAfter 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 policyCAs 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.

• 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.

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.

Note

Stand-alone CAs are primarily used in intermediate and rudimentary

roles.

Note

Enterprise CAs are primarily used for basic, medium, and high security

roles.




Establishing a CA Naming ConventionBefore 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.

Selecting a CA Database LocationWhen 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.

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. Youdo not have to reinstall a CA if you rename a domain; however, you will

have to reconfigure the CA to support the name change.




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).

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.

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 isexhausted

res2.log Reservation log file to store transactions if disk space isexhausted

edb.chk Database checkpoint file

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.

Tip

Use a separate RAID for both the database and log files for the highest

level of fault tolerance between backup intervals.




Example: Designing a CA InfrastructureAfter 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, toserve 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 beaccessed 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.

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.




Figure 15.10 Example of a CA Infrastructure of an Organization

Table 15.5 summarizes the configuration of these CAs.




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 issuing1

IsCA01 Online Member server

Corp


CA06 Online Member server

Corp


CA07 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 InfrastructureYou 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.




Figure 15.11 Extending Your CA Infrastructure




Evaluating Factors That Affect ExtendedTrusts

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.




• 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, thismight 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.

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.

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.




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.

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.




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 thatsupport 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 Web-

based 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-to-

one 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.

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.




Selecting an Extended CA InfrastructureConfiguration

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 ConfigurationBuilding 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.




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 thatrequires 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.




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.

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 ConfigurationYou 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.

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.




Using a Cross-Certification ConfigurationWith 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 CAsexchange 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.




Limiting Unplanned TrustsWhen 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.




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.

Example: Selecting an Extended CAInfrastructure 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 cross-

certify 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.

Note

After a CTL is defined, it must be applied to client computers by means

of Group Policy.




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 ConfigurationOptionsAfter 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.




Figure 15.15 Defining Certificate Configuration Options

Selecting Certificate TemplatesThe 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.




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 read-

only 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.

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.

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.




Before the certificates are issued, you need to determine the following critical information:

• Certificate key length

• Certificate validity period

• Optional certificate extensions

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

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.

Note

You can also create your own certificate templates.

Note

Certificate templates, in conjunction with the CA policy module, allow

you to define certificate policy for CA certificates.

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.




Table 15.6 Version 1 Certificate Templates

Certificate template name Certificate purposes Issued to

Administrator Code signing, Microsoft trust listsigning, EFS, secure e-mail, clientauthentication

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 EnrollmentAgent (Offline Request)

Certificate request agent Users

Exchange User SignatureSecure e-mail, clientauthentication

Users

Exchange User Secure e-mail, clientauthentication

Users

IPSEC IP Security Computers

IPSEC (offline request) IP Security Computers

Root CertificationAuthority

Identify the root CA Computers

Router Client authenticationComputers/routers

Smartcard Logon Client authentication Users

Smartcard User Client authentication, secure e-mail

Users

Subordinate CA All Computers

Trust List Signing Microsoft trust list signing Users

User Authentication, secure e-mail, andEFS

Users

User SignatureSecure e-mail, clientauthentication

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.




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-mailReplication

Directory replication Users

Domain Controller Authentication

Client authentication, server authentication

Users

Key Recovery Agent Key recovery Users

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).

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.




Selecting Certificate Security OptionsThe 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 thesecurity 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 LengthsWindows 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.




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.

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.

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 betweenapplications 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.

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.

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.




Establishing Certificate and Key LifetimesA 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 compromiseand 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 assupport 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)




• 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. Certificatesexpire 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.




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.

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.

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.




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 pastJanuary 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.




Using Qualified SubordinationMany 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:

• 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.

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).

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.




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 toCAs.

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.




Using Basic ConstraintsBasic 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 allowsonly 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 thenames 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 thedirectory.

• 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.




• 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 inthe 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 DNSnamespace .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=“”.




• 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.

Using Issuance PoliciesYou 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.

Important

Name constraint validation is performed on the CA, not on the client.

However, you must have Windows XP and Windows Server 2003clients in order to use name constraints.




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.

•

Medium Assurance (1.3.6.1.4.1.311.21.8. x.y.z .1.401). The medium assurance objectidentifier 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 digitalsignature 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.

Note

Issuance policy is only available on Windows Server 2003 CAs.

Windows 2000 does not provide issuance policy.

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.




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 thecross-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 policyconstraints in your trust hierarchy.




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 PoliciesCertificates 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 toensure 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.




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.

Using Constraints and Policy MappingThe 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 cross-

certificates 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.

Note

If you are issuing certificates that include both application policy and

EKU extensions, ensure that the two extensions contain identical

object identifiers.




Example: Configuring CertificatesAfter 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




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 ManagementPlanAfter 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.




Figure 15.18 Creating a Certificate Management Plan




Selecting a Certificate Enrollment andRenewal 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.

• 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

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.




• 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.

• 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 toActive 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 aWindows 2000 or Windows Server 2003 enterprise CA to use the smart card enrollment

station. Only Windows Server 2003 CAs support smart card autoenrollment.

Note

This option can only be used for Windows 2000, Windows

Server 2003, and Windows XP users, computers, and services.

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 thecertificate, including information about the requester (and, if asking for

a specific application, a correct object identifier), must be specified in

the certificate request.




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 RequestsWhether 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.




Selecting Automatic vs. Manual ApprovalUsers can request a certificate from a Windows Server 2003 CA either manually or automatically. This requestis 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.

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 InterfaceThe 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.

Tip

Autoenrollment is most useful for issuing and renewing computer and

IPSec certificates.

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, 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 thewizard 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.




Using CA Certificate RenewalWhen 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.

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.

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.




Mapping Certificates to User AccountsAfter 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 automatethe mapping process.




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 IISdoes 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 andSupport Center for Windows Server 2003.




Establishing Certificate Revocation PoliciesAll 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 differentencryption protocol or a longer key.




• 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.

• 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.

Selecting a CRL Publication LocationSelecting 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.

NoteUse 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.

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.




Figure 15.19 Selecting a CRL Publication Location

Selecting a CRL Distribution PointBecause 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.




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.

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 TypeWindows 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.

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.




Figure 15.20 Selecting a CRL Type

Establishing a CRL Publication ScheduleCAs 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 wellas 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.




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.

Setting the Cached CRL Validity PeriodTo 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.

Note

CRLs are published for all CA keys. You cannot selectively publish a

CRL for only one CA key pair.




Planning for Data Recovery and KeyRecovery

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.




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 non-

repudiation 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.

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.

Note

Only a Windows Server 2003 Enterprise Edition CA can implement

Windows Server 2003 key recovery.




Configuring the Key Recovery Agent CertificateBefore 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 keyarchiving.




Establishing Key Recovery Agent PoliciesAllowing 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 UsersAlthough 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.




Example: Creating a CertificateManagement 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 many-

to-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 PKIAfter 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.




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.




Schedule Production RolloutFor 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 CAhierarchy 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.

Install Certification AuthoritiesMost 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 CAsIn 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.

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.




• 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).

• 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.

• When you are asked to enter the Data Storage Locations, format the paths as local paths

(such as C:\WINDOWS\System32\CertLog).

Note

For the purposes of Microsoft CAs, the Strong and Enhanced CSPs

are considered equivalent. Both provide support for large key lengths

(1024-bit 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.

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.

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.




Install Intermediate and Subordinate CAsWhen 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 processafter 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 CertificateUse 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 PolicyIf 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.




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.

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 ExtensionsAfter a root or subordinate CA is installed, you must configure the Authority Information Access (AIA) andCRL 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 thecertification 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.

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.




• 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 brandoperating 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 TemplatesBy 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 thecertificate 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.




• 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 requestcertificate 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 areissued.

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 PolicyYou 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.




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. Thisdisables user installation of root CA certificates.

Configure CRL PublicationWhen 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.

Note

Disabling third-party CAs can impact user access to applications such

as SSL-secured Web sites.




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 certificateson 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.




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 100-

125 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 AdministrationBefore 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.




Configure Certificate Enrollment andRenewal

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 CertificatesYou 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 tohelp 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 renewalloads.




Additional ResourcesThese 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/webresourcesfor information about theCommon 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 TopicsFor 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

20 chapter 16 designing a public key infrastructure

Documents