Active Directory Certificate Services (AD CS) Public Key Infrastructure (PKI) Design Guide

Article
1/17/2024

The Windows Server® product line provides 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 the following configuration options:

Identifying Your AD CS Deployment Goals
Defining Certificate Requirements, Policies, and Practices
Designing the CA Infrastructure
Extending the CA Infrastructure
Defining Certificate Configuration Options
Creating the Certificate Management Plan
Planning the PKI Deployment

↑ Back to top

Identifying Your AD CS Deployment Goals

Before you design your public key infrastructure (PKI) and plan configuration options for certification authorities (CAs), certificates, extended trust relationships, and management 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 plan your PKI and CA configurations to issue and manage certificates for each of these business solutions, which in some cases can mean that your design must be able to support millions of users and high-volume digital signature transactions.

A Windows Server PKI can support a wide variety of security applications, including the following:

Digital signatures
Secure e-mail
Internet authentication
IP security
Smart card logon
Encrypting File System user and recovery certificates
Wireless 802.1X authentication
Authentication of network devices such as routers that do not have network accounts

Review this list and work with others in your organization to identify the business needs and applications that can be enhanced and enabled with digital certificates.

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, contracts, and purchase orders 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.

Secure e-mail

Many organizations need mail services that provide confidential communication, data integrity, and nonrepudiation. You can 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.

Internet authentication

On the Internet, client computers need a way to verify the identity of the servers that they are communicating with, and servers need a way to verify the identity of client computers.

When server authentication certificates are used, client computers can verify 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 computer. A server, in turn, can authenticate client computers by verifying the cryptographic signatures on their certificate, and any intermediate CA certificates, to a root CA installed in the trusted root store on the server. When the identity of the client computer is verified, the server can establish a security context to determine what resources the client computer is allowed or not allowed to use on the server.

IP security

Windows Server incorporates Internet Protocol security (IPsec), a suite of protocols that allows encrypted and digitally signed communication between two computers or between a computer and a router over a network that is not secure. The encryption is applied at the IP network layer. This means that IP packets are encrypted or signed by the sending entity, are unreadable during transfer, and can be decrypted only by the recipient.

You do not need to use public key technology to use IPsec. However, if you use public key technology in conjunction with IPsec, IPsec devices can authenticate each other and agree upon encryption keys without relying on prearranged shared keys. This, in turn, yields a higher level of security than IPsec without a PKI. For more information about deploying IPsec solutions, see Deploying IPSec.

Smart card logon

Smart card logon is integrated with the Kerberos version 5 authentication protocol implemented in Windows Server 2008. Using smart cards can 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 helps prevent spoofing of user identities across a network. In addition, you can also use smart card applications in conjunction with virtual private networks (VPNs) and certificate mapping, and in e-commerce. For more information about deploying smart cards, see Deploying Smart Cards.

Encrypting File System use and recovery certificates

By using Encrypting File System (EFS) in Windows Server 2008, users can encrypt their data to prevent other users from viewing the information. 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. For more information about EFS, see The Encrypting File System.

Wireless 802.1X authentication

The widespread use of wireless networks in organizations and public areas 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 certificates, 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, and dynamic key management to provide authenticated network access to 802.11 wireless networks and to wired Ethernet networks.

For more information about deploying a wireless network, see Wireless Networking.

Authentication of network devices

By using the Network Device Enrollment Service, your organization can issue certificates to software on routers and other network devices that are running without domain credentials. This capability is based on the Simple Certificate Enrollment Protocol (SCEP). SCEP was developed to support the secure, scalable issuance of certificates to network devices by using existing CAs. The protocol supports CA and registration authority public key distribution, certificate enrollment, certificate revocation, certificate queries, and certificate revocation queries. For more information about NDES, see AD CS: Network Device Enrollment Service.

↑ Back to top

Defining Certificate Requirements, Policies, and Practices

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 enrollment, validation, and revocation services.

In addition, you need to define service standards, support procedures, and a system for separating administrative authority; these are commonly detailed in two documents called a certificate policy statement and a certificate practice statement.

Only by effectively addressing both the technical and administrative issues related to your public key infrastructure (PKI) can you ensure that it provides the level of security that your organization requires.

Determining client certificate requirements

Certificate use can be based on job function, location, organizational structure, or a combination of these three.

For each of the groups that you identify, 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.
The groups, users, computers, and applications that need certificates.
- Certificates can be issued to as few as one user, computer, or application or as many as all users, computers, or applications in an entire 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. If you have users who use multiple computers, the use of credential roaming can significantly reduce the number of user certificates that you need to issue and manage.
The physical location of the users, computers, and applications that need certificates.
- Users in remote offices or users who travel frequently might require certificate solutions that are different from those of 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 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?

Documenting certificate policies

A certificate policy is a set of rules that indicates the applicability of a certificate to a particular group of clients or applications that have common security requirements. To create your certificate policy statement, you should include the following types of information:

How users are authenticated to the CA
Legal issues, such as liability, that might arise if the CA is either compromised or used for something other than its intended purpose
The intended purpose of the certificate
Private key management requirements, such as storage on smart cards or other hardware devices
Whether the private key can be exported or archived
Requirements for users of the certificates, including what users must do in the event that their private keys are lost or compromised
Requirements for certificate enrollment and renewal
Minimum length for the public key and private key pairs

Important: You can implement many of the decisions that you document in your certificate policy statements by creating a CAPolicy.inf file and copying it to the system directory of the CA before the CA is installed or renewed. For more information about CAPolicy.inf file contents and configuration, see Windows Server 2008 R2 CAPolicy.inf Syntax and CAPolicy.inf Syntax.

Documenting certificate practices

A certificate practice statement is a statement of the practices that an IT department uses to manage the certificates that it issues. A certificate practice statement should describe how the certificate policy of an 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.

Your certificate practice statement should include the following types of information:

Positive identification of the CA, including the CA name, server name, and Domain Name System (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 certificate revocation lists (CRLs), including the location of CRL distribution points and the frequency of CRL publication
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 PKI. 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 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.

For an outline to assist you in creating a certificate practice statement, see Internet X.509 Public Key Infrastructure: Certificate Policy and Certification Practices Framework RFC 2527 and EuroPKI Top Level Certification Authority Certificate Policy (CP) Statement.

↑ Back to top

Designing the CA Infrastructure

To support the certificate-based applications of your organization, you must establish a framework of linked certification authorities (CAs) that are responsible for issuing, validating, renewing, and revoking certificates as needed. The goal in establishing a CA infrastructure is to provide reliable service to users, manageability for administrators, and flexibility to meet both current and future needs, while maintaining an optimum level of security for the organization. The following diagram shows the steps involved in designing your CA infrastructure.

Plan Fundamental CA Options - These fundamental CA options will be used during the setup of individual servers as CAs.
Select a Trust Model - If you need to use multiple CAs, the decisions you make when selecting a trust model will determine how trust between these CAs will be ordered.
Define CA Roles in the Trust Hierarchy - When you have decided on the type of trust model you intend to develop, CAs must be configured to perform defined roles within the hierarchy.
Define PKI Management and Delegation Options - The public key infrastructure (PKI) management and delegation options you select will determine how secure and efficient your PKI will be.

Plan Fundamental CA Options

Before you can establish a certification authority (CA) infrastructure that meets the security needs and certificate requirements of 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:

Determine Critical Root CA Options
Select Internal CAs vs. External CAs
Plan for CA Capacity, Performance, and Scalability
Define CA Types and Roles
Use Offline CAs
Determine the Number of CAs Required
Integrate the Active Directory Infrastructure
Establish a CA Naming Convention
Select a CA Database Location

For additional security, you can also use hardware security modules (HSMs) to store keys for one or more of your CAs. There will be more information on HSMs later in this article.

Determine Critical Root CA Options

The root certification authority (CA) certifies other CAs to publish and manage certificates within the organization. Before you establish a CA hierarchy, you must answer the following questions:

Who will designate the root CA in the organization? For example, determine whether this is the responsibility of a central IT department, divisional IT departments, or other organization.
Where should the root CA be stored and how should it be protected? For example, some organizations keep their root CA offline except when it is needed to issue or renew a certificate for a subordinate CA. For enhanced security, some organizations might keep this CA, or its hard disk, in a secure location such as a vault.
Who will manage the root CA? Typically the most trusted network administrator manages the root CA, but some organizations might require at least two trusted administrators to provide the credentials needed to perform any administrative tasks on the root CA.
Will the root CA only certify other CAs or will it also respond to certificate requests from users? In smaller organizations, or when the highest levels of security are not needed, a root CA can also be used to issue user certificates. Otherwise, it is more secure to use the root CA only to issue and renew subordinate CA certificates.

After you have made these decisions regarding the root CA, you can define roles and practices for any additional CAs, including who manages the CAs and what trust relationships they have with other CAs.

Select Internal CAs vs. External CAs

Depending on the functionality that you require, the capabilities of your IT infrastructure and IT administrators, and the costs that your organization can support, you might choose to base your certification authority (CA) infrastructure on internal CAs, external CAs, or a combination of internal and external 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.

The advantages of using internal CAs include:

The organization can maintain direct control over its security policies.
The organization can align its certificate policy with its overall security policy.
Internal CAs can be integrated with the Active Directory infrastructure of the organization.
Internal CAs can be expanded to include additional functionality and users at relatively little extra cost.

The disadvantages of 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 external service providers.
The organization must accept liability for problems with the public key infrastructure (PKI).

External CAs

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

The advantages of using external CAs include:

Customers might have more confidence in secure transactions with the organization.
The organization can use certificate-based security technology while developing an internally managed PKI.
The external service provider might have more knowledge about the technical, legal, and business issues associated with certificate use.

The disadvantages of using external CAs include:

They typically involve a higher per-certificate cost than using an internal CA.
They might require the development of two different management standards, one for internally issued certificates and one for externally issued certificates.
They allow less flexibility in configuring and managing certificates.
The organization must have access to the external CAs in order to access the certificate revocation lists (CRLs).
Autoenrollment is not possible.
External CAs allow only limited integration with the internal directories, applications, and infrastructure of the organization.

You might need to use both internal and external CAs, which will be discussed later in this article.

↑ Back to top

Plan for CA Capacity, Performance, and Scalability

Organizations must agree upon a definition of acceptable certification authority (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 affect 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 Windows Server 2008–based enterprise CA on a dedicated server with a dual-core processor and 4 GB of RAM can process approximately 125 requests per second for 2,048 KB keys per second. For 1,024 KB keys, the same server setup can process approximately 155 requests per second. p>

Note: The number of requests that can be processed per second is lower if key archival is being used.

Using a greater number of small CAs with strategically located certificate revocation list (CRL) distribution points reduces the risk that your organization might be forced to revoke and reissue all 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 client computers' 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 affect 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 affect public key infrastructure (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 2008–based CA.
- Note: Because of the architecture of their databases, Windows Server 2008–based CAs are CPU-intensive and use a substantial amount of the disk subsystem. However, other hardware resources can also affect the performance of a CA when the system is put under stress.
Disk performance. In general, a high-performance disk subsystem allows for a faster rate of certificate enrollment. However, key length affects disk performance. With a shorter CA key length, the CPU has fewer calculations to perform; therefore, it can complete a large number of operations. With longer CA keys, the CPU needs more time to issue a certificate, resulting in a smaller number of disk input/output (I/O) 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 CA database is used more than the drive hosting the log file.
- Note: Using separate logical disks does not provide any performance advantages.
Amount of memory. The amount of memory that you use does not have a significant impact on CA performance, but must meet general system requirements.
Hard disk capacity. Certificate key length does not affect the size of an individual database record. Therefore, the size of the CA database increases linearly as more records are added. In addition, the higher the capacity of the hard disk, the greater the number of certificates that a CA can issue.
- Note: Plan for your hard disk requirements to increase over time. In general, every certificate that you issue requires 17 kilobytes (KB) in the database and 15 KB in the log file.li>

The type of hardware that your client computers use can also affect performance. When you are selecting or evaluating the capabilities of the hardware for your CA client computers, 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 PKI.
Growth or decline in demand for certificates.
The addition or removal of locations that CAs need to serve.
The effect of revocation. Revoking large numbers of certificates can take several minutes and increase the size of the database.

Using multiple CAs is an excellent way to ensure that your infrastructure can support enterprise scalability. The use of multiple CAs, even for organizations with minimal certificate requirements, provides the following advantages:

Greater reliability. If you need to take an individual CA offline for maintenance or backup, another CA can service its requests.
Scalability. Increases in demand, either from new users or from new applications, can be accommodated more easily.
Distributed administration. Many organizations distribute security administration across a number of IT administrators to prevent one individual or team from controlling the entire security technology infrastructure of the organization.
Improved availability. Users in remote offices can access a CA that is local to them rather than accessing a CA across slow wide area network (WAN) links.

Note: You can reorganize your CA infrastructure by adding or removing a CA and its associated users from a CA hierarchy. However, you cannot move a subset of users on a single CA to a new CA without forcing the users to re-enroll with the new CA.

↑ Back to top

Determine the Number of CAs Required

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

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

Note: You cannot install more than one CA on a server.

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 CA and one subordinate CA.

If you need more than one CA, how many root CAs do you require?

Generally, you should 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 the CA Infrastructure.

How many intermediate or policy CAs do you need?

Intermediate or policy CAs are useful when you need to enforce different security policies for different sets of certificates, such as certificates issued for high security applications and certificates issues for medium security certificates. For more information, see Define CA Roles in the Trust Hierarchy.

How many intermediate and issuing CAs 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 such as secure e-mail and network authentication. 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 certificate enrollment processing. 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 AD CS performance and usability requirements.
The need for flexible configuration. You can configure the CA environment, which includes key strength, physical protection, and protection against network attacks, to provide a balance between security and usability. For example, you can renew keys and certificates more frequently for the intermediate and issuing CAs that are at high risk for compromise, without requiring a change to established root trust relationships. Also, when you use more than one subordinate CA, you can turn off a subsection of the CA hierarchy without affecting established root trust relationships or the rest of the hierarchy.
The need for fault tolerance. If one enterprise CA fails, fault tolerance makes it possible for another issuing CA to provide users with uninterrupted service.

An enterprise CA is designed to provide natural fault tolerance in an Active Directory environment. If one enterprise CA does not work or is not available, client enrollment requests are automatically directed to the next available enterprise CA in the forest. No errors are generated and no user interaction is required..p>

For more information about using clustering to provide fault tolerance, see Configuring Certificate Services Clustering in Windows Server 2008.

↑ Back to top

Define CA Types and Roles

To plan your public key infrastructure (PKI), you need to understand the different types of certification authorities (CAs) available with Windows Server 2008 and then decide which CAs to use and the roles that they will serve in your organization.

In Windows Server 2008, Active Directory Certificate Services (AD CS) supports two types of CAs, based on how they will interact with a Windows domain or non-domain environment:

Enterprise CA
Stand-alone CA

Within a PKI, enterprise and stand-alone CAs can be:

Root CAs
Subordinate CAs

Subordinate CAs can further be configured to serve the following functions within the PKI:

Intermediate CAs (also referred to as a policy CA)
Issuing CAs

Before you create your PKI, you need to understand the type or types of CAs that you can use, so that you can define the specialized roles that each CA will assume. For more information, see Define CA Roles in the Trust Hierarchy.

Enterprise vs. stand-alone CAs

Use enterprise CAs if you want to integrate your CA with Active Directory Domain Services (AD DS). Enterprise CAs:

Publish certificates and certificate revocation lists (CRLs) to AD DS.
Use information stored in AD DS, including user accounts and security groups, to approve or deny certificate requests.
Use certificate templates to generate certificates based on attributes and data stored in AD DS 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 PKI is integrated with AD DS. 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 AD DS.

Use stand-alone CAs if you do not require AD DS integration and do not need or plan to 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 auto-issuance, using stand-alone CAs to issue large volumes of certificates can be labor-intensive 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 Server 2008 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 non-Microsoft directory service or when AD DS is not available.

Note: You can use both enterprise and stand-alone CAs in your organization.

Windows Server 2008 Stand-alone CA	Windows Server 2008 Enterprise CA
CA configuration can be published into Active Directory.	CA configuration is always published into Active Directory.
Certificate revocation lists (CRLs) and CA certificate must be manually published into Active Directory.	CRLs, Delta CRL, CA certificate, and cross certificates are automatically published to the forest where the CA configuration was registered. Certificates are automatically published into a directory service if this is specified on a per template level. Certificate publishing can be defined as an attribute on the template in Active Directory.
By default, certificate enrollment is available only by using CA Web enrollment or certreq.exe. You cannot use autoenrollment or interactively through the Certificates snap-in.	By default, certificate enrollment is possible by using CA Web enrollment, certreq, or the Certificates snap-in.
Certificate request processing is done by using Hypertext Transfer Protocol (HTTP) or Secure Hypertext Transfer Protocol (HTTPS).	Certificate request processing is done primarily by using RPC/Distributed Component Object Model (DCOM) or HTTP and HTTPS protocol.
Certificates are based on V1 templates with custom object identifier (also known as OID).	Also issues certificates that can be modified and duplicated, based on V2 templates and version 3 templates.
User must manually type identification information when they request a certificate.	User identification information is automatically retrieved from Active Directory, regardless of whether it is requested through CA Web enrollment or the Certificates snap-in.
Enrollment method (automatic or pending) is valid for all templates. You cannot apply a configuration to individual templates.	You can set the enrollment method individually on each template.
Certificate requests must be approved manually.	Certificates can be approved manually or automatically based on Active Directory authentication and access control.
Certificates are not published to a directory location, but to the client or the CA. without a custom-developed policy module.	Depending on the type of certificate, certificate are automatically enrolled into the requester's certificate store and published to Active Directory, based on template definition.
Does not support certificate publishing and object management based on Active Directory.	Supports certificate publishing and object management based on Active Directory.
Can be installed on a domain controller, member server, or stand-alone server (workgroup member).	Can be installed on a domain controller or member server. (The CA is registered as a forest resource.) It cannot be installed on a stand-alone server (workgroup member).

Establishing a root CA

A root CA is the CA that is at the top of a certification hierarchy and must be trusted unconditionally by client computers in your organization. All certificate chains terminate at a root CA. Whether you use enterprise or stand-alone CAs, you need to designate a root CA.

Because there is no higher certifying authority in the certification hierarchy, the subject of the certificate issued by a root CA is also the issuer of the certificate. Likewise, because the certificate chain terminates when it reaches a self-signed CA, all self-signed CAs are root CAs. Windows Server 2008 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 CA trust model. It guarantees that the subject public key belongs to the subject identity information that is contained in the certificates it issues. Different CAs might also verify this relationship by using different standards; therefore it is important to understand the policies and procedures of the root CA before choosing to trust that authority to verify public keys.

The root CA will be 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 non-Microsoft CA as the root CA, see Extending the CA Infrastructure. For more information about disconnecting CAs from the network, see Use Offline CAs.

Subordinate CAs

Any CAs that are not root CAs are subordinate CAs. 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, if used, are referred to as intermediate CAs. An intermediate CA is subordinate to a root CA, but also serves as a higher certifying authority to one or more subordinate CAs.

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

Note: Organizations with both internal and external users can have one root CA and two policy CAs—one to support internal users and the second to support external users.

↑ Back to top

Use Offline CAs

Securing your certification authority (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.

You can take a CA offline in any of the following ways:

Install and configure a stand-alone CA on a computer running Windows Server 2008 or Windows Server 2003.
Physically remove the computer from the network.
Shut down the CA service.
Shut down the computer.

It is a best practice to use stand-alone CAs for root and intermediate CAs. If you specify an offline CA on a server that is a member of a domain can cause problems with a secure channel when you bring the CA back online after a long offline period. This is because the computer account password changes every 30 days. You can prevent this by making offline CA computers members of a workgroup. Taking an enterprise CA offline for extended periods can cause also cause data in Active Directory Domain Services (AD DS) to become out of date.. Therefore, do not configure an enterprise CA as a root CA if you want it to be offline.

With offline CAs, you can still publish the CA's certificate and certificate revocation list (CRL) in AD DS. However, you must bring an offline CA online at regular intervals, based on your CRL publication schedule, to generate a new CRL for the CA. You must also bring the CA online to process certificate requests for subordinate CA certificates.

Important: The CRL and authority information access paths of an offline CA usually have to be modified before the first certificate is issued because the CRL and authority information access 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 authority information access distribution.

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

Taking a root CA offline does not reduce its importance, so be sure to use reliable hardware for offline root CAs. A hardware failure on an offline CA prevents you from publishing CRLs or issuing certificates to new subordinate CAs.

↑ Back to top

Integrate the Active Directory Infrastructure

Your public key infrastructure (PKI) is independent of the domain structure of your Windows environment. For example, one certification authority (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, consider your PKI requirements when you design your Active Directory Domain Services (AD DS) infrastructure. AD DS and PKI technology affect each other in the following ways:

Enterprise CAs are bound to the forest. As a result, enterprise CAs can only issue certificates to computers and users in the forest. In addition, you cannot change the name of the CA or the computer after it is deployed. Moreover, the computer cannot be removed from the domain or forest. Because much of the security of an organization is established at the forest level, the security of an enterprise CA is connected to the forest in which it is located. For this reason, each forest requires its own enterprise CAs.

Note: If certificates from stand-alone CAs are published to AD DS, 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 affecting the status of their certificates.

Certificate storage affects the size of your directory. If you store certificates in user objects, the size of the directory increases and replication time might increase. Because the userCertificate attribute contains data about all the user certificates, the addition of a certificate to this attribute causes AD DS 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 Active Directory Certificate Services (AD CS) functionality in Windows Server 2008, such as version 2 and version 3 certificate templates.

For certificates that will be valid for a long period of time, the availability of the CA services is much less important than the availability of the directory containing the certificates and the certificate revocation lists (CRLs). If you integrate your CAs with AD DS, your certificates and CRLs are automatically published to the directory and replicated throughout the forest as part of the global catalog.

Note: If you use AD DS 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.

AD CS in Windows Server 2008 functions whether AD DS in your organization is based on Windows 2003 or Windows Server 2008. 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 AD CS to groups of users or computers based on their domains or organizational unit (OU) membership. You must configure public key Group Policy in order to perform the following tasks:

Use credential roaming. Credential roaming allows X.509 certificates, certificate requests, and private keys specific to a user in AD DS to be stored independently from the user profile and used on any computer on the network. In addition, credential roaming policy in Windows Server 2008 makes it possible to roam stored user names and passwords as well as certificates and keys.
Manage path validation. Certificate path validation settings in Windows Server 2008 allow you to manage the settings for certificate path discovery and validation for all users in a domain. You can use Group Policy to easily configure and manage these certificate validation settings. The following are some of the tasks you can perform with these settings:
- Deploy intermediate CA certificates.
- Block certificates that are not trusted.
- Manage certificates used for code signing.
- Configure retrieval settings for certificates and CRLs.
Distribute certificates. In conjunction with other certificate-related Group Policy settings available in Windows Server 2008 domains, you can use Group Policy to distribute the following types of certificates to clients:
- Trusted root CAs. Implicitly trusted CAs, including all of the certificates in the Third-Party Root Certification Authorities store, plus root certificates from your own organization and Microsoft.
- Enterprise trust. A certificate trust list provides a mechanism for trusting self-signed root certificates from other organizations and limiting the purposes for which these certificates are trusted.
- Intermediate CAs. Certificates issued to subordinate CAs.
- Trusted Publishers. Certificates from CAs that are trusted.
- Untrusted Certificates. Certificates that you have explicitly decided not to trust because they are no longer valid for their intended purpose or because they are from a source that domain clients should not trust.
- Trusted People. Certificates issued to people or end entities that are explicitly trusted. Most often these are self-signed certificates or certificates explicitly trusted in an application such as Microsoft Outlook.
Designate Encrypting File System (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 OUs 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 AD CS and communicate this information to the AD DS and Group Policy administrators, so that they can address your public key requirements in their planning.

↑ Back to top

Select a CA Database Location

When you install a certification authority (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.

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 shared folder named certconfig).

Note: You can change the location of the database and log files manually at a later time. However, you cannot perform this task by using the user interface.

Windows Server 2008 uses the JET database engine for the CA database. As with any JET database, you should place the database and its log files on different physical disk drives to improve fault tolerance and performance. By default, all these files are located in the certlog subdirectory of the system directory.

Note: Use a separate RAID for both the database and log files for the highest level of fault tolerance between backup intervals.

The CA database consists of the files listed in the following table.

Database file	Purpose
<CA name>.edb	The CA store
edb.log	The transaction log file for the CA store
res1.log	Reservation log file to store transactions if disk space is full
res2.log	Reservation log file to store transactions if disk space is full
edb.chk	Database checkpoint file

You can determine the location of the database files for a CA by typing certutil -databaselocations at a command prompt or by viewing the Certification Authority snap-in.

↑ Back to top

Establish a CA Naming Convention

Before you configure one or more certification authorities (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 by using any Unicode character, but you should 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.

In Active Directory Domain Services (AD DS), the name that you specify when you configure a server to be a CA becomes 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 FQDN of the CA to create potential security vulnerability.

Note: You cannot change the name of a server after a CA has been installed without invalidating all the certificates issued by the CA. To change the server name after a CA has been installed, you must uninstall the CA, change the name of the server, reinstall the CA, and reissue all the certificates issued by the CA. You do not have to reinstall a CA if you rename a domain; however, you will have to reconfigure the CA to support the name change.

↑ Back to top

Use Hardware CSPs and KSPs

Use hardware cryptographic service providers (CSPs) and key storage providers (KSPs) if you want to increase the security of your certification authorities (CAs). Keys stored in tamper-resistant hardware cryptographic devices are more secure than keys stored on local computer hard disks. Therefore, keys stored in hardware cryptographic devices can have key lifetimes that are longer than keys stored by software CSPs on hard disks.

Note: Another advantage to using hardware CSPs and KSPs 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 surreptitious means.

If you determine that a hardware CSP or KSP 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 you should back up the operator cards or tokens. You might, for example, keep the device in a highly secured area of your company, or lock it in a safe.

↑ Back to top

Select a Trust Model

The Windows Server 2008 public key infrastructure (PKI) is based on a hierarchical certification authority (CA) model that is composed 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 other 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 flexibility in the number of certificate-issuing subordinate CAs that you can use.

Your PKI trust hierarchy must be based on one of these three trust models:

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.

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 also be based on one or a combination of the following:

Quality of identification
Organizational structure
User location

Rooted trust model

In a rooted trust model, the root CA is the trust anchor and has a self-signed certificate. The root CA issues a certificate to all direct subordinate CAs, if needed, which in turn issue certificates to their subordinate CAs. A subordinate CA is trusted cryptographically, based on the signature of its parent.

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 the new CA to a CA anywhere in the trust hierarchy. If you create a new trust hierarchy, the new CA 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 is 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 or policy CAs that only issue certificates to other CAs, taking the CA offline does not affect other parts of the hierarchy.

Because most protocols deliver a chain of certificates that terminates in a trusted root CA, rooted trust hierarchies provide a straightforward means by which CAs can determine whether a certificate can be trusted.

Note: If the certificate of a root CA expires, all certificates that are issued by the root CA or by its subordinate CAs also expire.

Network trust model

If your organization has multiple, distributed IT departments, you might not be able to establish a single, trusted root. In this situation, you can implement a network trust model, in which all CAs are self-signed and trust relationships between CAs are based on cross-certificates. Cross-certificates are special certificates that are used to establish complete or qualified one-way trusts between otherwise unrelated CAs.

A network trust model can be viewed as a hierarchy because a cross-certificate is similar to a subordinate CA certificate in a rooted trust model. The cross-certifying CA is the issuer and the cross-certified CA is the subject.

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 Domain Services (AD DS) 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 client computers of the PKI; otherwise there is no way to discover them.

The trusts in the illustration are bidirectional. This 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, client computers of CA1 trust CA2 and CA3, while client computers of CA2 and CA3 do not trust CA1. To do this, CA1 creates a cross-certificate without the knowledge of CA2 because CA1 only needs the public key certificate of CA2. This is known as unilateral cross-certification, where one CA cross-certifies another CA but the second CA does not cross-certify the first CA.

Bidirectional cross-certificates are usually preferred, although with this model you need to manage more cross-relationships as the number of cross-certificates increases.

Full trust between cross-certified CAs also means that the client computer trusts all certificates issued by the other CA, regardless of the purpose of the certificate. In a native Windows Server 2008 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.

Cross-certification enables you to create bridges between separate PKIs without either PKI being directly subordinate to the other. Because cross-certification is an indirect subordination of one PKI to another, the trust point does not change relative to either PKI. In fact, bidirectional cross-certification models the way in which companies form relationships; that is, each side participates in establishing the relationship. A network trust model, however, is much more difficult to maintain and troubleshoot than a rooted trust model.

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

Hybrid trust model

Some organizations might find a pure rooted trust model too restrictive because no single CA can serve as the root for all other CAs. At the same time, a pure network model can become prohibitively complex if too many different CAs are involved. If you use a hybrid approach, however, you can cross-certify only certain CAs and thus use the benefits of both the rooted and network trust models.

Trust hierarchy based on quality of identification

A trust hierarchy based on quality of identification enables an organization to configure CAs to issue certificates to specific groups of users. This type of trust hierarchy is ideal for organizations in which different identification and authentication requirements are applied to different groups of users, computers, and activities.

For example, an organization requires employees to appear in person to provide identification such as a driver's license or passport to a security officer, who checks an employee database to ensure that individuals are authorized before they can receive appropriate credentials. However, because computers cannot assert an identity, managers in the organization are responsible for ensuring that computer names are correct and that computers are authorized to have a certificate. Because the organization requires CAs for employee certificates and computer certificates and each requires a different form of identification, the organization chooses to create a trust hierarchy based on quality of identification.

In a trust hierarchy based on quality of identification, the CAs subordinate to the root CA are organized according to the quality of identification required for the certificate to be issued. The subordinate CAs use certificates signed by the root CA to issue certificates to users, computers, services, or another CA.

A typical CA hierarchy based on quality of identification includes two or three issuing CAs for each of the following:

Employee certificates
Computer certificates
Contractor certificates, if applicable. These certificates might require the same identification that employee certificates require but contain an issuer statement stating that the individual is not a full-time employee.

Trust hierarchy based on organizational structure

Although a two-tier 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.

Design your trust hierarchy according to organizational structure if your certificate requirements vary according to organizational units, such as if you need to provide certificates to partners that are different from those provided to employees. 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

↑ Back to top

Trust hierarchy based on location

Some organizations might find it necessary to implement a three-tier trust hierarchy based on location. This configuration allows regional administrators to manage the certificate requirements for users in a defined area such as a continent, country/region, or locale. The following illustration shows a CA 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.

↑ Back to top

Define CA Roles in the Trust Hierarchy

After you have designed the trust hierarchy for your organization, you must define the roles for your root and subordinate certification authorities (CAs).

The root CA, for example, might be used to sign, certify, or revoke subordinate CAs. Subordinate CAs that serve as intermediate or policy CAs might serve internal or external customers, or, in larger organizations, might serve more specialized functions or locations. Subordinate CAs that serve as issuing CAs might be defined according to the client computers that they serve or the certificates that they issue.

You might choose to select some or all of the following roles for your subordinate and issuing CAs:

Intermediate CA. Certifies subordinate CAs to issue certificates.
Rudimentary CA. Issues certificates for the most basic operations, such as user authentication without an identity check. Note: Stand-alone CAs are primarily used in intermediate and rudimentary roles.
Basic security CA. Issues certificates, based on an Active Directory identity check, to users and computers that do not have special security requirements.
Medium security CA. Issues certificates to users and computers that meet special security requirements and whose identities are validated in Active Directory Domain Services (AD DS).
High security CA. Issues certificates to users or computers that meet especially high security requirements, and whose identities must be verified by means of the examination of physical credentials. Note: Enterprise CAs are primarily used for basic, medium, and high security roles.

Consider the following as you define CA roles:

Use a three-tier hierarchy with policy CAs only if necessary.

Non-Microsoft CAs can form all or part of a Windows Server 2008–based CA trust hierarchy.
Some non-Microsoft products might require other CA trust models that are not interoperable with rooted CA hierarchies. Windows Server 2008 and most commercial CAs support rooted CA hierarchies.

The following table illustrates how enterprise, standalone, and offline CAs can be combined in one-, two, and three-tier PKI hierarchies. Depending on your organization's needs, these roles can be taken by a smaller or larger number of CAs.

CA type	Three-tier	Two-tier	One-tier
Offline root CA	Stand-alone CA	Stand-alone CA	Enterprise CA
Offline intermediate CA	Stand-alone CA
Issuing CA	Enterprise CA	Enterprise CA

↑ Back to top

Define PKI Management and Delegation Options

ItIt is important to define a public key infrastructure (PKI) management model early in the process of designing your certification authority (CA) hierarchy. This PKI management model must complement your existing security management delegation plan and help you to meet Common Criteria requirements for role separation. To ensure that a single individual cannot compromise PKI services, it is best to distribute management roles across different individuals in your organization. This involves deciding which individuals are to perform each of the following tasks:

Creating or modifying existing CAs
Managing certificate templates
Issuing cross-certificates
Issuing or revoking user certificates
Configuring and viewing audit logs

You can use discretionary access control lists (DACLs) to manage CA permissions and delegate CA management tasks.

Windows Server 2008 and Windows Server 2012 include the following built-in CA management roles:p>

CA administrator. Configures and maintains the CA. This is a CA role and includes the ability to assign all other CA roles and renew the CA certificate. These permissions are assigned by using the Certification Authority snap-in.
Certificate manager. Approves certificate enrollment and revocation requests. This is a CA role. This role is sometimes referred to as CA officer. These permissions are assigned by using the Certification Authority snap-in.
Restricted enrollment agent. Can enroll on behalf of specified clients for certificates based on specified certificate templates. Note: The restricted enrollment agent is not available on a Windows Server 2008 Standard–based CA. For more information, see Establish Restricted Enrollment Agents
Audit manager. 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 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.

In Windows Server 2008, you can restrict the ability of certificate managers to issue certificates by group and for specified certificate templates.

To facilitate this delegation process, you need to understand how various PKI administrative roles align with Windows Server 2008 administrative roles. The following table lists the Windows Server 2008 administrative roles that correspond to each PKI administrative role.

PKI administrative role	Description	Windows Server 2008 administrative role
PKI administrator	Configures, maintains, and renews the CA	User
Backup operator	Performs system backup and recovery	Backup operator on the server on which the CA is running
Audit manager	Configures, views, and maintains audit logs	Local administrator on the server on which the CA is running
Key recovery manager	Requests retrieval of a private key stored by the service	User
Certificate manager	Approves certificate enrollment and revocation requests	User
Restricted enrollment agent	Enroll for a certificate on behalf on another client; unlike a certificate manager, an enrollment agent can only process the enrollment request and cannot approve pending requests or revoke issued certificates	User
User manager	Manages users and their associated information	Account operators or person delegated to create user accounts in Active Directory Domain Services (AD DS)
Enrollee	Requests certificates from the CA	Authenticated users

The following table lists the actions that each PKI administrative role can perform.

Action	Enrollee	CA administrator	Certificate manager	Audit manager	Backup operator	Local server administrator
Install a CA						X
Configure a CA		X				X
Configure policy and exit modules		X
Stop and start the Active Directory Certificate Services (AD CS) service		X				X
Change CA configuration		X
Assign user roles		X
Establish user accounts		X				X
Maintain user accounts		X				X
Configure profiles		X				X
Renew CA keys						X
Define key recovery agents		X
Define officer roles		X
Enable role separation		X
Issue and approve certificates			X
Deny certificates			X
Revoke certificates			X
Reactivate certificates that have been revoked			X
Renew certificates			X
Enable, publish, or configure certificate revocation list (CRL) schedules		X
Configure audit parameters				X		X
Audit logs				X		X
Back up the system					X	X
Restore the system					X	X
Read CA properties and CRLs	X
Request certificates	X
Read CA databases		X	X	X	X
Read CA configuration information		X	X	X	X
Read issued, revoked, and pending certificates		X	X	X	X

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

↑ Back to top

Extending the CA Infrastructure

For many organizations, a single hierarchical public key infrastructure (PKI) based on the configuration options discussed in the previous section, will meet most or all of their certificate issuance and management requirements. However, some organizations have PKI requirements that are too complex to be met by a simple rooted hierarchy. For example, an organization might need to extend its certification authority (CA) infrastructure to accommodate joint ventures, mergers, geographic requirements, or other business requirements. If your organization finds a basic hierarchical PKI to be limiting, then you need to complete the following steps:

Identify Factors that Affect Extended Trust - A number of factors, such as standards support and the configuration options selected for the other CA can affect your ability to create a trust relationship with that CA. You need to examine all of these factors and assess their potential impact.
Select an Extended CA Trust Configuration - Even if the configuration and other characteristics of another PKI are compatible with yours, you need to decide on an extended CA trust configuration to link the two PKIs.
Limit Unplanned Trusts - When you link two PKIs, it is extremely important to define precisely the limits of the trust relationship between the two and the extent to which certificates issued in one PKI can be used in a second PKI.

The following illustration shows the steps involved in extending your CA infrastructure.

If you do not need to connect your PKI to another PKI, then you can skip this section and proceed to Defining Certificate Configuration Options.

Identify Factors that Affect Extended Trust

Extending and refining your trust hierarchy is a critical step in the process of creating a secure public key infrastructure (PKI), and it involves complex decisions. It is important to define appropriate and inappropriate uses for certificates in your organization before you extend your certification authority (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 2008 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
Certificate revocation list (CRL) distribution points
Authority information access
Authority key identifier
Other certificate extensions
Key length
Enhanced key usage
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 2008 and non-Microsoft PKI applications. To promote interoperability with the Windows Server 2008 API, Microsoft supports the following standards:

PKIX. Public Key Infrastructure X.509 (PKIX) defines interoperable PKI standards for the Internet.
X.509. X.509 describes the standard format of a certificate.
PKCS. Public Key Cryptography Standards (PKCS) provides a standard for public key message exchanges.
TLS. Transport Layer Security (TLS) provides a secure and authenticated channel between hosts on the Internet above the transport layer.
S/MIME. Secure/Multipurpose Internet Mail Extensions (S/MIME) serves as a standard for secure e-mail across the Internet.
Kerberos authentication protocol. The Kerberos authentication protocol provides a symmetric key framework for authentication in large networks.
PC/SC. Personal Computer/Smart Card (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 your PKI, you might need to make some changes to your existing design. For this reason, you should 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 the physical location where keys are stored.

Windows Server 2008 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 non-Microsoft CAs have their own cryptographic APIs and use PKCS #11 for communication with hardware tokens such as smart cards. Because Windows Server 2008 and Windows Server 2003 require hardware devices to support Plug and Play and power management features, and PC/SC includes support for these features, Windows Server 2008 does not support PKCS #11.

Note: The Windows Server 2008 PKI can use non-Microsoft cryptographic service providers (CSPs) and can enroll users for certificates that have keys that were generated by non-Microsoft CSPs.

CRL distribution points

The CRL distribution point extension in a certificate identifies how revocation information for the certificate can be obtained. If certificate revocation data is not available, certificate chain building can be delayed and might even fail, and the certificate will be considered invalid.

Note: Publish CRL distribution point URLs for all CAs so that users who need to know whether or not issued certificates have been revoked can find that information.

You need to compare any non-Microsoft CRL support with the Windows Server 2008 CRL support. For example, non-Microsoft PKIs might not support the Windows Server 2008 CRL process, which includes the use of delta CRLs. Conversely, the Windows Server 2008 PKI might not support the methods of the other vendor's PKI for processing CRL information. Your extended PKI deployment plan needs to consider these differences.

In general, follow these guidelines when you configure the CRL distribution point extension:

If available, use Active Directory Domain Services (AD DS) to support internal corporate client computers.
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 extension provides the location of the currently published CA certificate of a CA. The authority information access extension helps client computers find CA certificates dynamically during chain building. The Windows Server 2008 PKI uses this extension to assist in building trust chains to validate certificates.

It is recommended that you publish authority information access 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 authority information access extension minimizes the likelihood that PKI client computers 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 non-Microsoft PKIs do not provide the authority information access extension. In this case, parent certificates need to be distributed to domain client computers so that the certificates are available before the chain building process begins. Cross-certificates must also be available locally on domain client computers because there is no information in a certificate specifying its location.

Authority key identifier

The authority key identifier 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 or the issuer name and serial number from the certificate issued by the CRL issuer. The authority key identifier extension is useful when a CRL issuer has more than one signing key.

An organization that expects its PKI certificates to be used by other Windows Server 2008 PKIs must populate the authority key identifier extension with a unique key identifier and an issuer name and serial number. The Windows Server 2008 PKI attempts to construct certificate chains by using the issuer name and serial number in the authority key identifier first and then the subject key identifier.

Note: By default, Windows Server 2008 does not automatically add issuer names and serial numbers to the authority key identifier extension. This data must be added manually by means of the Certutil.exe command-line tool, although in most cases this information is not essential.

Certificate extensions

Not all certificate extensions are universally recognized. If a CA does not recognize a certificate extension in a request that has been marked critical, it rejects the certificate. Unless you intend to limit the use of the certificate to a specific application that can process the critical extension, avoid using 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.

Enhanced key usage

The extended key usage extension indicates the purposes for which the public key contained in the certificate can be used. The Windows Server 2008 PKI uses the extended key usage extension to indicate certificates that support special functions, such as Internet Protocol security (IPsec) and Encrypting File System (EFS) backup. The extended key usage extensions of other organizations might be used for different purposes.

Directory integration

Windows Server 2008 PKI certificates can be published to any directory or repository, although the default CA exit module supports only AD DS. However, by default, a Windows Server 2008 PKI relies on AD DS and the LDAP for authentication, including smart card logons and certificate autoenrollment, as well as for certificate management.

With Active Directory Certificate Services (AD CS), certificates issued by a non-Microsoft CA can be associated with a Windows Server 2008 user account stored in AD DS. 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 AD DS, based on the user principal name (UPN) information in a certificate. The account that the certificate is associated with provides information about user access rights on the server.

Note: This is an extremely powerful feature for Web-based applications and other vendors' CAs because it combines strong authentication by means of public key technology with the native authorization model of Windows Server 2008. 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 associate them with accounts in AD DS by means of one-to-one or many-to-one relationships.

Select an Extended CA Trust Configuration

You can use one of three configurations to create an extended certification authority (CA) trust infrastructure:

Non-Microsoft root CA. Use a non-Microsoft 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 the necessary trust between the two organizations.

There are advantages and disadvantages to each approach. If you need to extend your CA infrastructure to include non-Microsoft public key infrastructures (PKIs), you need to evaluate the requirements of your organization to determine the method that is most appropriate for you.

Using a non-Microsoft root CA configuration

Building a new public key hierarchy from an existing non-Microsoft root CA is an appropriate solution if you want to cross-certify with multiple business partners simultaneously. The non-Microsoft root CA is used to build a new public key hierarchy designed specifically to serve the needs of multiple organizations. The following illustration shows an example of an extended CA infrastructure created 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.

The advantage to this approach is that you can delegate 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 delegated to another organization, this approach involves considerable additional cost. The costs can multiply each time you add a new business relationship that requires a separate shared PKI.

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, such as deciding where to locate intermediate and issuing CAs, how to manage them, and how to protect them. In this case, you must work with your business partner and the root CA provider to make these decisions.

Non-Microsoft CAs can form all or part of a CA trust hierarchy. To ensure that non-Microsoft CAs provide interoperability with your existing infrastructure, test all proposed interoperability scenarios in your lab

Note: Some PKIs require CA trust models that are not interoperable with rooted CA hierarchies. Windows Server 2008 and most commercial CAs support rooted CA hierarchies.

Adding trusted root certificates to Group Policy

If a stand-alone CA is not a domain member but 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 non-Microsoft CA as a root CA in a certification hierarchy, you must add the certificate for the non-Microsoft CA to the Trusted Root Certification Authorities Group Policy.

Using a new root CA configuration

You or your partner organization can create a new root CA to establish an extended CA infrastructure that supports your business requirements. The structure of this extended CA infrastructure is similar to that of an extended infrastructure based on a non-Microsoft root 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 non-Microsoft 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.

Using a cross-certification configuration

With the cross-certification method for extending the CA infrastructure, neither organization creates a separate PKI; instead, cross-certificates, accompanied by qualified subordination, enable communication between existing PKIs of two organizations to the degree of trust that their business relationship dictates.

Cross-certification creates a shared trust between two CAs that do not share a common root CA. These CAs exchange cross-certificates that allow their organizations to communicate with each other. 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.

The advantages of using cross-certification to extend the PKI include low cost and more 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. However, this creates a security risk, as it exposes resources in parts of the organization that are not part of the business relationship. 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 those outside the organization 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.

Limit Unplanned Trusts

When you extend your trust infrastructure beyond the boundaries of a single public key infrastructure (PKI), 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 partner

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

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 Server 2008 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 2008 CTLs 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 CTLs on an extranet to trust certificates issued by certain commercial CAs. If you associate certificates that are issued to an account stored in Active Directory Domain Services (AD DS), you can grant appropriate permission to users who need access to restricted extranet resources. This is possible because the users have certificates issued by the trusted commercial CAs.
Restrict the permitted use of certificates issued by trusted CAs. For example, you can use a CTL on an extranet to restrict the permitted use of certificates to applications such as secure e-mail.
Control the period of time in which non-Microsoft certificates and CAs are valid. For example, the CA of a business partner can have a lifetime of five years and issue certificates with a lifetime of one year. However, you can create a CTL 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.

After a CTL is defined, it must be applied to client computers by means of Group Policy.

↑ Back to top

Defining Certificate Configuration Options

After configuration options for your certification authorities (CAs) are 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. The following steps will help you make available certificates with the configuration options that meet the needs of your organization:

Select Certificate Templates - Preconfigured certificate templates can significantly simplify the process of enabling certificates for specific applications. By understanding the certificate template options that are available, you can help ensure the reliability and manageability of certificates in your organization.
Select Certificate Issuance Options - Certificates are credentials, just as employee badges or passports, and therefore you need to protect them with the appropriate security configuration options.
Select Certificate Use Options - Many of the certificates that you issue can be used without any further customization. However, you might want to limit the scope of your certificates, and a number of constraint and policy options are available to help address these concerns.

Certificate issuance and use options will overlap, so settings discussed in the issuance section may have implications on certificate use, and settings in the use section may also have implications for certificate issuance.

Select Certificate Templates

The Active Directory Certificate Services (AD CS) role services that you deploy and the security requirements that are specific to your organization affect 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 certification authority (CA) in Windows Server 2008 and Windows Server 2003 provide the default contents of all certificates that can be requested from a Windows–based enterprise CA. These certificate templates are stored in Active Directory Domain Services (AD DS) 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), Secure/Multipurpose Internet Mail Extensions (S/MIME), and Encrypting File System (EFS). For example, a user certificate can be used for both user authentication and EFS encryption.

Microsoft CAs support three types of certificate templates: version 1, version 2, and version 3.

CAs that are set up on servers running Windows Server 2003, Standard Edition, or Windows 2000 Server support only version 1 templates.
CAs that are set up on servers running Windows Server 2003, Enterprise Edition, or Windows Server 2003, Datacenter Edition, support both version 1 and version 2 templates.
CAs that are set up on servers running Windows Server 2008 support all three versions.

Version 3 certificate templates can only be used by client computers running Windows Server 2008 or Windows Vista.

When determining which type of certificate template to use, select:

Version 1 certificate templates for backward compatibility and if you do not need to make any modifications. However, when you duplicate a version 1 template, the duplicate becomes a version 2 or version 3 template that can be modified.
Version 2 certificate templates for most applications where you need to customize settings in the template.
Version 3 certificate templates if you want to add advanced Suite B cryptographic settings to your certificates. Suite B includes advanced options for encryption, digital signatures, key exchange, and hashing. Certificates based on version 3 certificate templates can only be issued from CAs installed on servers running Windows Server 2008 and used on client computers running Windows Server 2008 or Windows Vista.

If you are using version 1 templates, you can upgrade them to version 2 templates. During the upgrade, domain administrators in your top-level domain must have Full Control permission on the version 1 templates.

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 that apply to the certificate, including additional information that can define certificate purposes, restrictions, and management
Digital signature of the CA, which verifies the relationship of the certificate to the issuing CA

Note: You can also create your own certificate templates.

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

Certificate key length
Certificate validity period
Optional certificate extensions

Certificate templates, in conjunction with the CA policy module, allow you to define certificate policy for CA certificates

In addition, version 2 and version 3 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 cryptographic service provider (CSP) types
Certificate contents

After you have selected the certificate templates and template versions that you want to use, you must select configuration properties where none have been predefined, accept their default configuration options, where available, or modify these default values.

Certificate templates can only be used when the server that is running Active Directory Certificate Services (AD CS) 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.

Select Certificate Issuance Options

Certificate issuance options that need to be assessed and, if necessary, modified, include:

Validity period
Expiration and renewal options
Subject names
Security
Issuance requirements
Superseded templates

Validty period

An expiration date is defined for each certificate at the time that it is issued. An enterprise certification authority (CA) issues certificates with lifetimes that are based on the certificate template for the requested certificate type.

Most certificate templates have a default lifetime of one year. However, 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.

The following factors affect the lifetimes that you choose for certificates and keys:

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 (CSPs). Some cryptographic technologies provide stronger security, as well as support for stronger cryptographic algorithms. For example, you might use smart cards for user logon or FIPS 140-1 Crypto Cards for secure e-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 widely available the CA public key that is used to sign an issued certificate, the more vulnerable it becomes to attempts to break it.
Certificate lifetime nesting. A certificate validity period cannot extend beyond the validity period of the CA that issued it. 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.

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.

For example:

If the expiration date of a Windows Server 2008 root CA certificate is January 2, 2017, no child CA in the chain below the root can issue a certificate with a date that is later than January 2, 2017.
If a Windows Server 2008 intermediate CA has a certificate expiration date of January 2, 2013, no child CA can issue certificates with an expiration date that is later than January 2, 2013.
If a Windows Server 2008 issuing CA has a certificate expiration date of January 2, 2009, no certificate that the CA issues can have an expiration date that is later than January 2, 2009.

Expiration and renewal options

Certificates expire when they reach the end of their 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 affect the security of your public key infrastructure (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 can be renewed for a period based on the nesting guidelines described in the Validity period section above.

To create a certificate renewal strategy, determine the following:

Which certificates, if any, will be 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 attackers 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.

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 and a separate certificate revocation list (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.

Subject names

When configuring a certificate template, subject name formats must be defined. This subject name is included in the issued certificate template to uniquely identify the subject.

A number of options can be included with the subject name, as well as specific configuration settings for the subject name when the subject name is derived from Active Directory information obtained during the certificate request process. The format of the subject name can be defined as follows:

None. Does not enforce any name format for this field.
Common name. The CA creates the subject name from the common name of the requestor obtained from Active Directory Domain Services (AD DS). These should be unique within a domain but may not be unique within an enterprise.
Fully distinguished name. The CA creates the subject name from the fully distinguished name obtained from AD DS. This ensures that the name is unique within an enterprise.

In addition, you can choose to include the e-mail name in the subject name. This information is populated from the E-mail attribute of an account and is included with either the common name or fully distinguished name as part of the subject name.

In addition to the subject name, you can also choose the name formats to include in the alternate subject name attributes of issued certificates. The alternate subject name formats that are available include:

E-mail name. If the e-mail name field is populated in the Active Directory user object, that e-mail name will be used for user accounts. Important: The e-mail name is required for user certificates. If the e-mail name is not populated for a user in AD DS, the certificate request by that user will fail.
DNS name. The fully qualified domain name (FQDN) of the subject that requested the certificate is used for computer accounts.
User principal name (UPN). This is part of the Active Directory user object and will be used for user accounts.
Service principal name (SPN). This is part of the Active Directory computer object and will be used for computer accounts.

The only case in which a subject can request a certificate with a different subject name is when the request includes a certificate based on the Enrollment Agent template. The Enrollment Agent template allows a subject to request a certificate on behalf of another subject.

Security

The security permissions that are assigned to a certificate template define which security principals can read, modify, enroll, or autoenroll for a specific certificate template.

To simplify administration, you should not assign certificate template permissions to individual user or computer accounts. Instead, assign certificate template permissions to global groups or universal groups.

Note: Because certificate template objects are stored in the AD DS Configuration naming context that is required for the proper functioning of Active Directory as a directory service, you cannot assign permissions by using domain local groups.

The permissions that you can assign to a certificate template include:

Full Control. This allows a security principal to modify all attributes of a certificate template, including the permissions for the certificate template.
Read. This allows a security principal to see the certificate template when enrolling for certificates. It is required for a security principal to enroll or autoenroll a certificate; and is required by the CA to find the certificate templates in AD DS.
Write. This allows a security principal to modify the attributes of a certificate template, including the permissions assigned to the certificate template.
Enroll. This allows a security principal to enroll for a certificate based on the certificate template. To enroll for a certificate, the security principal must also have Read permission for the certificate template.
Autoenroll. This allows a security principal to receive a certificate through the autoenrollment process. Autoenroll permission requires that the user has both Read and Enroll permissions in addition to the Autoenroll permission.

You should assign or maintain Read permission for the Authenticated Users group. This permission allows all users and computers—including the CA running under the System context of a computer account—to view the certificate templates in AD DS.

Note: Full Control and Write permissions should only be assigned to administrators who have been delegated to manage certificate templates.

Issuance requirements

Specifying issuance requirements allows you to require an administrator or certificate manager to review and approve all requests for certificates that involve a higher level of security risk. When CA certificate manager approval is configured, a certificate is made pending, rather than being issued immediately.

The following settings on the Issuance requirements tab can be used to manage the authentication and signature requirements for certificates that are issued based on a template.

CA certificate manager approval. All certificates are placed into the pending container for a certificate manager to issue or deny. Any defined certificate manager can issue or deny a certificate request of this type.
This number of authorized signatures. This setting requires the certificate request to be digitally signed by one or more authorized parties before it can be issued.

When you require certificate manager approval, you will also need to configure and issue signing certificates to your designated certificate managers. You can regulate the approval process further by configuring one or more application and issuance policy extensions in the signing certificate template. The following issuance requirements options would preventing any signing certificate that does not contain these extensions from being used to approve a pending certificate request:

Policy type required in signature. This option defines which specific application policy, issuance policy, or both are required in the signing certificate. This is how the CA determines whether the signature is appropriate for authorizing the issuance of the subject's certificate.
Application policy. This option specifies the application policy that must be included in the signing certificate used to sign the certificate request. It is enabled when Policy type required in signature is set to either application policy or both application and issuance policy.
Issuance policy. This option specifies the issuance policy that must be included in the signing certificate used to sign the certificate request. This option is enabled when Policy type required in signature is set to either issuance policy or both application and issuance policy.

In addition, you can also determine whether the same issuance requirements are upheld for certificate renewal, or if the existence of a valid existing certificate of the same template in the certificate store meets the minimum requirements for certificate issuance.

The Request Handling tab for a certificate template also allows you to specify several user input settings associated with certificate issuance. These settings include:

Enroll subject without requiring any user input. This option allows autoenrollment without any user interaction and is the default setting for both computer and user certificates. This option must not be enabled for computer certificates.
Prompt the user during enrollment. Although useful when testing initial autoenrollment deployments, typically, this option is disabled. By disabling this option, users do not have to provide any input for the installation of a certificate based on the certificate template.
Prompt the user during enrollment and require user input when the private key is used. This option enables the user to set a strong private key protection password on the user's private key when the key is generated and requires the user to use it whenever the certificate and private key are used. This option must not be enabled for computer certificates or smart card user certificates.

To enable smart card autoenrollment, the Prompt the user during enrollment option must be enabled so that the user is prompted to insert the smart card in the smart card reader when required.

Strong private key protection with autoenrollment is not supported or enabled for computer certificates and is only available on computers running Windows XP Service Pack 1, Windows XP Service Pack 2, and Windows Vista.

Superseded templates

Over time, you will likely want to replace existing certificates and certificate templates with updated versions that address new security and application requirements. The Superseded Templates tab allows you to specify which certificate templates you want a new certificate template to supersede. For example, you can supersede:

A version 1, 2, or 3 certificate template with a version 2 or 3 certificate template.
Multiple existing certificate templates with a common version 2 or 3 certificate template.

When you supersede one or more existing certificate templates, you can also require all certificate holders to re-enroll by using the updated certificate template.

Select Certificate Use Options

Many of the certificates that you issue can be used without any further customization. However, you might want to limit the scope of your certificates, whether they are intended to enable an application, validate a subordinate certification authority (CA), or cross-certify an external CA. You can limit the scope of a certificate by specifying custom settings for the following properties of a certificate template:

Request handling
Cryptography
Extensions

Request handling

Request handling properties for certificate templates allow you to define the purpose of the certificate template, the supported cryptographic service providers (CSPs), minimum key length, exportability, autoenrollment settings, and whether strong private key protection should be required. Version 3 templates have a few request handling options that are not available on version 2 templates.

The certificate purpose defines the intended primary use of the certificate. The certificate purpose can be one of four settings:

Encryption. This certificate contains cryptographic keys for encryption and decryption.
Signature. This certificate contains cryptographic keys for signing data only.
Signature and encryption. This certificate contains all primary uses of a certificate's cryptographic key, including encryption of data, decryption of data, initial logon, and digitally signing data.
Signature and smart card logon. This certificate allows for initial logon with a smart card and digital signing of data; it cannot be used for data encryption.

The certificate purpose setting will also determine whether key archival can be enabled for a certificate template. Key archival is only possible if the certificate purpose is set to Encryption or Signature and encryption.

Archive settings

On the Request Handling tab, you can also configure key archival and recovery settings. When subjects lose their private keys due to user profile corruption or because the user to whom the private key was issued is no longer a member of the organization, any information that was encrypted with the corresponding public key is inaccessible. To help prevent this, define certificate template settings to archive a subject's keys when certificates are issued. If subjects lose their keys, the information can then be retrieved from the CA database and securely provided to the subject or a designated recovery agent. This allows the encrypted information to be recovered instead of lost.

Notes:

These settings are available in Windows Server 2008 Enterprise, Windows Server 2008 Datacenter, Windows Server 2003 Enterprise Edition, and Windows Server 2003 Datacenter Edition.
You must also issue key recovery certificates and enroll key recovery agents before key archival and recovery are fully enabled.

The following key archival options can be defined for certificate templates:

Archive subject's encryption private key. If the issuing enterprise CA is configured for key archival, the subject's private key will be archived.
Allow private key to be exported. When this option is specified, the subject's private key can be exported for backup or transportation.
Deleting revoked or expired certificates (do not archive). If a certificate is renewed due to expiration or revocation, the previously issued certificate is removed from the subject's certificate store. By default, the certificate is archived.
Include symmetric algorithms allowed by the subject. When the subject requests the certificate, a list of supported symmetric algorithms can be supplied by the subject. This option allows the issuing CA to include those algorithms in the certificate, even if they are not recognized or supported by that server. The algorithms are used by applications such as secure e-mail.

Additional options (Windows Server 2008 only)

The Request Handling tab for Windows Server 2008 certificate templates has been updated to provide support for the new options available on the Cryptography tab, as well as for some additional changes made in Windows Server 2008.

Use advanced Symmetric algorithm to send the key to the CA. This option allows the administrator to choose the Advanced Encryption Standard (AES) algorithm to encrypt private keys while they are transferred to the CA for key archival. If this option is selected, the client computer will use AES-256 symmetric encryption (along with the CA's exchange certificate for asymmetric encryption) to send the private key to the CA for archival. If this option is not selected, the symmetric algorithm used is Triple Data Encryption Standard (3DES). Note: Because key archival is intended for encryption keys (not signing keys), this option is enabled only when Encryption is selected in the Purpose box.
Add Read permissions to Network Service on the private key. For computer certificate templates, this option grants Read permission to Network Service for the certificate's private key on the computer to which the certificate is issued. This enables services such as the Online Responder service and Internet Information Services (IIS) to use certificates and keys issued to the computer on which they run.

Cryptography

In addition to key archival settings, some general options that affect all certificates, including those that do not enable key archival, can be defined. These include:

Minimum key size. This specifies the minimum size, in bits, of the key that will be generated for this certificate.
Cryptographic service providers. This is a list of CSPs that will be used to enroll certificates for the given template. Selecting one or more CSPs configures the certificate to work with only those CSPs. If you do not select a specific CSP, the certificate enrollment will work with any installed CSP but will use the first CSP from the enumeration list. The CSP must be installed on the client computer for the CSP to be used during enrollment. If a specific CSP is chosen and not available on a client computer, enrollment will fail.

Extensions

Using options on the Extensions tab, organizations can define specific application policies, issuance policies, certificate subject types, and key usage attributes for a certificate template.

Application policies

Application policies enable you to decide which certificates can be used for certain purposes. You can issue certificates widely without being concerned that they are misused for an unintended purpose.

Application policies are settings that inform a target that the subject holds a certificate that can be used to perform a specific task. They are represented in a certificate by an object identifier that is defined for a given application. This object identifier is included in the issued certificate. When a subject presents its certificate, it can be examined by the relying party to verify the application policy and determine if it can perform the requested action.

Application policies are similar to the extended key usage attribute in version 1 certificate templates. Because some implementations of public key infrastructure (PKI) applications may not understand application policies, both application policies and enhanced key usage sections appear in certificates issued by a Microsoft CA.

The following table shows some of the more commonly used application policies and their related object identifiers. You can add application policies if the certificate template that you are selecting does not already include them.

Application policy	Object identifier
Client Authentication	1.3.6.1.5.5.7.3.2
CA Encryption Certificate	1.3.6.1.4.1.311.21.5
Smart Card Logon	1.3.6.1.4.1.311.20.2.2
Document Signing	1.3.6.1.4.1.311.10.3.12
File Recovery	1.3.6.1.4.1.311.10.3.4.1
Key Recovery	1.3.6.1.4.1.311.10.3.11
Microsoft Trust List Signing	1.3.6.1.4.1.311.10.3.1
Qualified Subordination	1.3.6.1.4.1.311.10.3.10
Root List Signer	1.3.6.1.4.1.311.10.3.9
OCSP Signing	1.3.6.1.5.5.7.3.9

For Windows Server 2008–based CAs, the new OCSP Response Signing default template contains an additional custom extension called OCSP no revocation checking. If this template extension is selected, the CA will include the OCSP no revocation checking (id-pkix-ocsp-nocheck) extension in the issued certificate and exclude the commonly used authority information access and CRL distribution point extensions in the certificate. The extension has this effect only if the certificate request contains OCSP Signing in the enhanced key usage and application policies.

Issuance policies

You can use issuance policies, also referred to as certificate policies, to define the extent to which your organization trusts the identity presented in a certificate. For example, you can set an issuance policy stipulating that you only trust certificates that were issued during a face-to-face meeting with a network administrator, such as when a smart card certificate is issued.

An object identifier must describe every issuance policy that you define. The inclusion of an issuance policy object identifier in an issued certificate indicates that the certificate was issued in a manner that meets the issuance requirements associated with the issuance policy object identifier

Note: Issuance policy is only available starting in Windows Server 2003–based CAs. Windows 2000 Server does not provide issuance policy.

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 2008 includes four predefined issuance policies:

All Issuance (2.5.29.32.0). The all issuance policy indicates that the issuance policy contains all other issuance policies. Typically, this object identifier is only assigned to CA certificates.
Low Assurance (1.3.6.1.4.1.311.21.8.x.y.z.1.400). The low assurance object identifier is used to represent certificates that are issued with no additional security requirements. Note: The x.y.z portion of the object identifier is a randomly generated numeric sequence that is unique for each Windows Server 2008 forest.
Medium Assurance (1.3.6.1.4.1.311.21.8.x.y.z.1.401). The medium assurance object identifier is used to represent certificates that have additional security requirements for issuance. For example, a smart card certificate that is issued in a face-to-face meeting with a smart card issuer might be considered a medium assurance certificate and contain the medium assurance object identifier.
High Assurance (1.3.6.1.4.1.311.21.8.x.y.z.1.402). The high assurance object identifier is used to represent certificates that are issued with the highest security. For example, the issuance of a key recovery agent certificate might require additional background checks and a digital signature from a designated approver because a person holding this certificate can recover private key material from a Windows Server 2008 Enterprise–based CA.

In addition, you can create your own object identifiers to represent custom issuance policies. For example, two organizations involved in a purchaser/seller relationship can define custom object identifiers to represent digital signature certificates for specific purchase amounts. In such a case, an object identifier can be defined for purchase between $100,000 and $500,000 and another object identifier can be defined for purchases greater than $500,000. Applications can then use these object identifiers to recognize whether a person had the appropriate signing authority for a specific volume purchase.

Key usage

A certificate enables the subject to perform a specific task. To help control the usage of a certificate outside its intended purpose, restrictions are automatically placed on certificates. Key usage is a restriction method and determines what a certificate can be used for. This allows the administrator to issue certificates that can only be used for specific tasks or certificates that can be used for a broad range of functions. If no key usage is specified, the certificate can be used for any purpose.

For signatures, key usage can be limited to one or more of the following purposes:

Digital signature
Signature is proof of origin (nonrepudiation)
Certificate signing
CRL signing

For encryption key usage, the following options are available:

Key exchange without key encryption
Key exchange only with key encryption

Certificate template information

The certificate template information, also referred to as the certificate subject type, defines the purpose of a certificate template. Six subject types are recognized:

Key recovery agent
Directory e-mail replication
Cross-certified certification authority
Certification authority (CA)
Computer
User

The certificate template information extension cannot be edited. If you need a specific subject type to be applied to a certificate, you should start from a different certificate template that includes the required subject type.

↑ Back to top

Creating the Certificate Management Plan

After you have configured certificates for your organization, you need to create a plan for managing certificates throughout their lifetimes. The certificate management plan includes the following:

Select a Certificate Enrollment and Renewal Method
Establish Certificate Revocation Policies
Plan for Root Trust
Plan for Key and Data Recovery

Select a Certificate Enrollment and Renewal Method

To enable enrollment, you need to specify the enrollment and renewal processes for your certificates. Enrollment involves either configuring permissions to establish which security principals have Enroll permissions for specific templates (in the case of enterprise certification authorities (CAs) or appointing a certificate administrator who reviews each certificate request and issues or denies the request based on the information provided.

Enrollment and Renewal Options

Active Directory Certificate Services supports the ability to process certificate requests manually, if administrative approval is required, or automatically, if no approval is necessary. The following enrollment and renewal methods are available:

Certificate autoenrollment and renewal. Allows you to automatically issue certificates that enable PKI applications, such as smart card logon, EFS, SSL, and S/MIME, to users and computers within an Active Directory environment. Certificate autoenrollment is based on a combination of Group Policy settings and certificate templates, which allows you to enroll computers when they start up and to enroll users when they log on to their domain.

Note: To use autoenrollment, you need a Windows Server 2008 or Windows Server 2003 domain controller, a Windows Vista or Windows XP Professional client, and a Windows Server 2008 or Windows Server 2003 enterprise CA.
Certificate Request Wizard and Certificate Renewal Wizard. Available from the Certificates console, you can use the Certificate Request Wizard to request a certificate from an active enterprise CA on behalf of a user, computer, or service.
Web Enrollment Support pages. Contain Active Server Pages and ActiveX controls that provide a Web-based user interface to a CA. By default, the Web Enrollment Support pages are automatically installed on the computer on which the CA is installed, but you can also install the Web Enrollment Support pages on another Windows Server 2003 computer. You can also customize Web Enrollment Support pages. For example, you can limit user options or provide additional links to online user instructions and user support information.

Note: You can use Web Enrollment Support pages on stand-alone CAs to issue most of the same types of certificates that enterprise CAs can issue, with the exception of certificates for smart card logon and for autoenrollment, which must be issued and renewed by an enterprise CA. The Web Enrollment Support pages that are installed on stand-alone CAs do not use certificate templates, so all information about the certificate, including information about the requester (and, if asking for a specific application, a correct object identifier), must be specified in the certificate request.
Smart card enrollment station. Advanced version of the Web Enrollment Support pages that allows trusted administrators or security personnel to enroll for smart card certificates on the behalf of other users.

To select the certificate enrollment and renewal processes that are appropriate for your organization, you need to consider the following:

The users, computers, and services for which you intend to provide services. Determine whether they are internal or external to the organization. Identify the operating systems they are running and determine whether or not they are connected to Active Directory.
The operating system that your clients are using. Clients running Windows Server 2003 and Windows XP can use the Certificate Request Wizard, autoenrollment, or the smart card enrollment station. Windows 2000 supports the Certificate Request Wizard but does not support smart card autoenrollment. Autoenrollment and the smart card enrollment station also require Active Directory. Most other clients can use their Web browsers to access Web-based enrollment and renewal services.
The policies that you establish in order to manage certificate distribution. This includes both the procedural policies that you establish for your PKI, and the Group Policy settings that you use to implement those policies.
The type of CA that is issuing the certificates. For example, you must have a Windows Server 2008 or Windows Server 2003 enterprise CA to use the smart card enrollment station. 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

Automatic vs. Manual Requests

Whether you choose to generate certificate requests automatically or manually depends on the types of certificates that you intend to use and the number and type of clients that you enroll. For example, if you want all users or computers to use a certain type of certificate, it is not practical for you to require that each certificate be requested individually. Although rolling out a new certificate to all users or computers at one time can generate a large amount of network activity, you can control that activity by deploying the certificate requests for each organizational unit one at a time.

On the other hand, you might want to have users or an administrator request certain high-security certificates, such as those used for digital signing or administrative tasks, only when needed. This can improve administrative control over these certificates — particularly if certificate use is not limited by a user or computer OU, or security group membership.

You can improve control over your certificates by using one of the following options to limit user certificate requests:

Restrict access to specific templates. Configure the discretionary access control list (DACL) for each template so that only the required security principals have Enroll and Read permissions for particular templates.
Automate the deployment of computer certificates. Configure Group Policy to automatically assign the necessary computer certificates by adding the certificate template to the Automatic Certificate Request Settings option in Group Policy. Tip: Autoenrollment is most useful for issuing and renewing computer and IPSec certificates.

Automatic vs. Manual Approval

Users can request a certificate from a Windows Server 2003 CA either manually or automatically. This request is held until an administrator approves it, if manual approval is required, or until the verification process is completed. When the certificate request has been approved, the autoenrollment process installs the certificate automatically, or automatically renews the certificate on behalf of the user, based on the specifications in the certificate template.

Most of the time, you choose the same method for certificate approval that you choose for certificate requests — but not always. For example, if you have the appropriate Group Policy and DACL restrictions on your certificate templates, you might decide to approve automatically a certificate request that was generated manually. Conversely, in some cases, it is appropriate to manually approve certificate requests that are automatically generated.

You can use strong authentication to enhance the security associated with autoenrollment. With strong authentication, the certificate template uses a specify policy object identifier to require an additional signature on the certificate request. For example, you can set a policy that requires the use of a smart card to provide a stronger authentication method for autoenrollment requests, or you can require approval for automatic certificate requests, so that administrators must approve pending requests.

However, in general:

For routine and high volume certificates, such as e-mail certificates, automatic approval is the best option for certificate approval as long as the certificate requester has already been authenticated with a valid set of domain credentials.
When a high degree of administrative oversight is required, such as for software code signing certificates, consider processing certificate requests manually. By using the Certificate Request Wizard, you can evaluate every certificate request individually — or you can delegate this responsibility to another administrator.

Selecting an Enrollment and Renewal User Interface

The user interface that you select for certificate request and approval processing depends on whether you choose automatic or manual certificate request and approval methods. If you decide to use autoenrollment for both certificate requests and certificate approval, you must use a minimal user interface.

However, if all or part of the enrollment process is manual, you must decide between using the Web Enrollment Support pages or the Certificate Request Wizard. The Web Enrollment Support pages are the easier interface for users to use. Users can perform the following tasks from the Web Enrollment Support pages:

Request and obtain a basic user certificate.
Request and obtain other types of certificates by using advanced options.
Request a certificate by using a certificate request file.
Renew certificates by using a certificate renewal request file.
Save a certificate request to a file.
Save the issued certificate to a file.
Check on pending certificate requests.
Retrieve a CA certificate.
Retrieve the latest certificate revocation list from a CA.
Request smart card certificates on behalf of other users (for use by trusted administrators).

However, administrators might prefer to use the Certificate Request and Renewal Wizard. You can start the wizard from the Certificates snap-in. Because the wizard is linked to the Certificates snap-in, you can also create custom snap-ins that you can distribute to certification authority administrators to whom you have delegated specific roles.

Unless an organization uses firewalls between one part of the organization and another, you can use the Certificates snap-in or the Web interface interchangeably. If a firewall exists between the CA and the requesting client, you must request certificates by means of the Web Enrollment Support pages or ensure that port 135 and a dynamic port above 1024 is open for MMC DCOM communication.

Whether you choose to use the Web Enrollment Support Pages or the Certificate Request and Renewal Wizard, you might need to prepare documentation that describes how users can request a user certificate, what users can expect after they request the certificate (for example, automatic enrollment or a delay pending administrator approval), and how they can use the certificates after they receive them.

Planning for CA Certificate Renewal

When a CA has issued and supports a large number of certificates, the quality of service and user satisfaction can decline. However, enrollment and renewal are relatively infrequent activities that can be anticipated and therefore planned for well in advance. Many organizations fail to plan for certificate renewal because this activity does not occur until some point well into the future.

When the certificate of a CA expires, the CA can no longer provide certificate services. To provide uninterrupted certificate services, use the Certificates console to renew the CA certificate before its expiration date. The interval that is required for CA renewal depends on the certificate lifetime of the CA.

After you renew a CA, the CA continues to issue certificates by using the new CA certificate, and the cycle starts over. Unexpired certificates that were issued by the pre-renewal CA continue to be trusted until they expire or are revoked.

You can use the standard enrollment and renewal methods that are available in Windows Server 2003 to renew your CAs and certificates. You can renew certificates with the same private key and public key set or with new private and public keys. However, if you have special needs, you can develop custom certificate enrollment and renewal applications for CAs.

Caution: Do not renew certificates with the same private and public key sets if the renewal period exceeds the maximum safe key lifetime. The safe key lifetime is based on your choice of key lengths. Longer keys allow for longer safe key lifetimes.

The Windows Server 2008 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.

Establish Certificate Revocation Policies

All certificates have specified lifetimes. However, in some situations, a certificate needs to be invalidated 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 use and configuration guidelines for Online Responders, if appropriate.

Defining Conditions for Certificate Revocation

Not all public key infrastructures (PKIs) need to be supported by the publication of CRLs. For example, if your certificates provide only a low- or medium- level of security and are unlikely to be misused, or if they have short lifetimes, there might not be a need to create and distribute lists of revoked certificates. If, on the other hand, your certificates have a high perceived value and a lifetime that is long enough to cause potential misuse, you need to create and distribute certificate revocation lists on a regular basis.

Before you create certificate revocation schedules, define all the circumstances that justify the revocation of certificates in your organization. For example, you might choose to revoke certificates for any of the following reasons:

An unauthorized user has gained access to the private key of the certificate.
An unauthorized user has gained access to the CA. In this case, all the certificates that the CA has published must be revoked and reissued.
Certificate criteria have changed; for example, an employee has moved to a different department.
The certificate has been superseded. For example, you might decide to use a different encryption protocol or a longer key.
The CA that issued the certificate is no longer operating.
The status of the certificate is on hold. When a certificate has been revoked, it cannot be renewed. However, if the status of a certificate is questionable, you can revoke it and then rescind the revocation if necessary, or re-revoke it for another reason.

Note: Use Certificate Hold sparingly because issues can develop involving the period that the certificate was on hold. For example, if a certificate was on hold for three hours but the hold is then removed, attempts to use the certificate during the hold period can yield unexpected results.
Users misuse their security permissions or the private keys of users are compromised (a smart card is lost, for example).
A computer is replaced or permanently removed from service, or the private key of the computer is compromised.

Note: A root certificate cannot be revoked by means of a CRL because a root CA is self-signed. A CRL includes only certificates that are issued by a dedicated CA. If you must revoke a root certificate, you need to revoke all the certificates issued by the root CA. The CA certificate becomes obsolete if there are no more valid certificates.

Selecting a CRL Publication Location

Selecting a location for CRL publication involves answering the following questions:

Are the certificate revocation lists needed internally, externally, or both?

CRLs have to be published where they can be accessed to validate or invalidate certificates. If the PKI is within the firewall of the organization and certificates are published to Active Directory, then LDAP can be used to publish CRLs. If the certificates are used outside the organization or if there is no directory service, http can be used to publish CRLs to a Web server because HTTP traffic can travel more reliably through a firewall than LDAP traffic.

Do you require multiple CRL publication locations for fault tolerance or to support greater numbers of geographically diverse clients?

If the answer is yes, choose the domain controllers and Web servers that provide you with greater coverage and improved response times. This way, if one CRL publication point becomes unavailable, the information is available from other publication points.

Do you need to set up one or more Online Responders to provide revocation data to clients who have slow or intermittent connections to the network?

Selecting CRL Distribution Points

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.

Note : On root CAs, you must also modify the CRL distribution point in the CAPolicy.inf file so that the root CA certificate references the correct CDP and AIA paths, if specified.

If you are using certificates on the Internet, you must have at least one HTTPs-accessible location for all certificates that are not limited to internal use.

Planning for Different Delta and Base CRLs

Starting in Windows Server 2003, there are 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.

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

Establishing a CRL Publication Schedule

CAs publish CRLs listing the serial numbers of certificates that have been revoked according to an established publication schedule. The frequency of publication is based on the number of changes that take place in a given period of time, and how critical the need to maintain up-to-date revocation information is to your organization.

As you create your CRL policies, you need to specify publication schedules for CRLs. By default, enterprise CAs publish CRLs weekly to Active Directory, and stand-alone and enterprise CAs publish CRLs weekly to a directory on the CA server. For example, you can specify that certain CRLs are distributed to Web pages as well as to Active Directory, and that certain CRLs are published daily instead of weekly.

If you use delta CRLs, a typical publication schedule might look like this:

• Publish base CRLs every week.
• Publish delta CRLs every day.

The CRL schedule for the certificates of your issuing CA must account for potential network and server downtime. In addition, it must account for latency in Active Directory replication. For these reasons, make the CRL publication schedule longer than the maximum replication latency.

Make sure that your publication schedule is shorter than the validity period of the CRL. With a validity period of one week, your CRL will be up-to-date for most purposes. If you require an additional buffer to protect against interruptions in communications, you can publish the CRL every two days.

Your strategy for renewing CAs also impacts your CRL publication strategy. If you choose to reuse the existing key pair when you renew a certificate for a CA, the existing CRL covers certificates issued under both the old and new CA certificates. If you choose to renew certificates by using a new key pair for the CA, you need to issue one CRL for the certificates issued with the old key pair, and another CRL for certificates issued with the new key pair. Although both old and new certificates were issued by the same CA, the validity of the older certificates will be validated against one CRL, and the validity of the newer certificates will be validated against the other CRL.

Note: CRLs are published for all CA keys. You cannot selectively publish a CRL for only one CA key pair.

Setting a Validity Period for Cached CRLs

To reduce the amount of network bandwidth needed to retrieve CRLs, the CRL that is specified in the CRL attribute of the certificate is cached on the client system using the certificate. You can control the schedule by which the client retrieves updated CRLs by setting the CRL lifetime.

CRL publication and client use of the most recent CRL are independent. The client does not retrieve a new CRL from its distribution point unless the lifetime of a matching cached CRL has expired. Therefore, when you set the CRL validity period, be sure to balance the intended and actual CRL lifetime.

The only way to force a client to retrieve the latest CRL from the CRL distribution point before the CRL cache on the client has expired is by clearing the CRL cache — a task that is difficult to perform in many networks.

Adding Online Responders to Your PKI

An Online Responder is a trusted server that receives and responds to individual client requests for information about the status of a certificate. Unlike certificate revocation lists (CRLs), which are distributed periodically and contain information about all certificates that have been revoked or suspended, an Online Responder receives and responds only to individual requests from clients for information about the status of a certificate. The amount of data retrieved per request remains constant no matter how many revoked certificates there might be.

In many circumstances, Online Responders can process certificate status requests more efficiently than by using CRLs. Consider using Online Responders to address the following situations:

Clients who connect to the network remotely and either do not need nor have the high-speed connections required to download large CRLs.
A network needs to handle large peaks in revocation checking activity, such as when large numbers of users log on or send signed e-mail simultaneously.
An organization needs an efficient means to distribute revocation data for certificates issued from a non-Microsoft certification authority (CA).
An organization wants to provide only the revocation checking data needed to verify individual certificate status requests, rather than make available information about all revoked or suspended certificates.

Achieving Scalability and High Availability

To provide scalability and high availability, an Online Responder can be deployed on a single computer or on a software cluster that contains one or more computers. Clustering can be achieved by using any software or hardware TCP/IP load balancers. The Online Responder Microsoft Management Console (MMC) snap-in provides the ability to manage multiple responders as if they were a single entity.

Deployment Models for Extranet Scenarios

When deploying extranet-facing Online Responders, one of the design considerations is the level of protection provided for the Online Responder signing key.

The Online Responder can be located in a protected local area network (LAN), while all requests are redirected by an authenticated server that is running IIS, which is located in a perimeter network (also known as DMZ, demilitarized zone, and screened subnet). The advantage of such a deployment model is that the firewall configuration requires only pass-through for port 80 between IIS and the Online Responder.

Plan for Root Trust

When a client uses a certificate, they must be able to verify the trust relationship between the certificate and the root certification authority (CA) for the public key infrastructure (PKI). A certificate is trusted if the client that verifies the certificate trusts the root CA certificate that is in the client certificates certificate trust path as well. A client must have the related root CA certificate in its local certificate store to proof a trust-relationship with the root CA.

If Active Directory is available, you can use Active Directory to establish a trust relationship with the root CA

You can achieve the trust that is obtained from a root certification authority by deploying the root CA certificate through one of the following six methods:

Enterprise trust in Active Directory
Group policy in Active Directory
Certificate Trust Lists (CTLs) in Group Policy
Manual trust on a local computer
Manual trust by a user
Windows Update

Depending on the permissions and the scope of the distribution mechanism, certificates are put into different locations and require different maintenance tools. For more information, see the following table.

Distribution method	Scope	Uses Group Policy object	Location	Maintained with
Enterprise trust	Entire forest	Yes	Services\Public Key Services\CertificationAuthorities	Certutil.exe or PKI Health Tool
Group policy trust	Domain	Yes	Domain Security Group Policy object	Group Policy MMC
NTAuth (for CAs trusted to issue authentication certificates)	Entire forest	Yes	Services\Public Key Services\NTAuth object	Certutil.exe or PKI Health Tool
Manual trust on the local computer	Local computer and all users that log on to system	No	Registry HKEY_LOCAL_MACHINE	Certificates MMC for the local computer
Manual trust by user	Current user	No	Registry HKEY_CURRENT_USER	Certificates MMC for the local computer
Windows Update	Local computer and all users that log on to system	No	Registry HKEY_LOCAL_MACHINE	Group Policy MMC or Add or Remove Programs in Control Panel

Enterprise Trust

The built-in autoenrollment service can be used to automatically download root CA certificates and certificate trust lists (CTLs) from the Active Directory enterprise trust store on both Windows 2000 and Windows XP clients.

Group Policy Trust

Group Policy trust can be defined and applied by using the Group Policy Object Editor and the Default Domain Security Group Policy object. Group Policy trust is configured and enforced for the domain where the Group Policy object applies. Because of this, different users in different domains trust different root CAs. It is highly recommended to create a new domain policy and not edit the default domain policies.

Note: Only root CA certificates must be trusted and registered on client computers. Do not add subordinate CA certificates to the Group Policy trust, because intermediate and issuing CAs certificates may not be explicitly trusted.

NTAuth

The NTAuth store is deployed on all computers in the forest from the configuration partition of the forest in the following directory path:

CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=<Domain>,DC=<Domain>

NTAuth CAs are trusted to both issue authentication (logon) certificates for any user in the forest and enable logon for smart cards, Internet Information Services (IIS) mapping, and Extensible Authentication Protocol-Transport Layer Security (EAP-TLS).Precise control of issuing CAs can be achieved through qualified subordination with constraints.

In a Windows Server 2008 or Windows Server 2003 Active Directory environment that contains only clients running Windows XP or Windows Vista, the NTAuth store is not mandatory for smart card logon and certificate mapping, compared to a mixed environment that includes Windows 2000 clients.

Windows Server 2008 and Windows Server 2003 Active Directory support the publication of cross-certificates and clients running Windows Vista or Windows XP support name and policy constraints for x.509 certificates. Therefore, administrators in these organizations can bypass the NTAuth policy if desired. To do this, CAs must have defined name constraints instead of being listed in the NTAuth store of the directory. Therefore, domain controllers that process both smart card logon and certificate mapping requests will explicitly trust all CAs that chain to trusted root CAs, assuming that the certificate matches a valid user account in Active Directory.

Caution: Disabling NTAuth policy verification enables domain controller trust of any CA that issues a valid smart card logon certificate and chains to a trusted root CA in the Active Directory environment. Any CAs, including the default third-party root CAs, should have name constraints defined before disabling the NTAuth policy. If this does not occur, unintended trust and logon access may occur. Use this option with extreme caution and only when root CAs have been properly constrained in the environment.

Manual Trust on a Local Computer

It is recommended that only administrators maintain certificate trust and that you store only CA certificates in the local computers certificate store.

Windows Update

By default, computers that are running Windows Server 2008, Windows Vista, Windows XP and members of the Windows Server 2003 family run a service that will download updated public root CA certificates that have been added to the Microsoft root program. This service is not available on computers running Windows 2000.

Any organization that has a CA that meets the requirements that are outlined in the Microsoft Root Certificate program is able to distribute the CA certificate through Windows Update.

Computers that are running either Windows XP or Windows Server 2003 periodically download the current list of Root CA certificates that are added to the Third-Party Root Certification Authority store on the local computer.

This service can also be managed through Group Policy in Active Directory.

Plan for Key and Data Recovery

If public key pairs and certificates are lost due to system failure, it can be time consuming and expensive to replace them and the data that they protect. For this reason, as part of your certificate management plan, you need to evaluate the potential consequences of loss of public keys and the data that they secure, and create a strategy for data and key recovery.

Data recovery is a process by which data is encrypted in such a way that more than one person can retrieve the data in plaintext form. Data recovery does not always imply that private key recovery has occurred; however, key recovery is one method for data recovery.

Use data recovery if you need to be able to recover data in your organization, but do not need to have access to individual private keys of users.

The advantages of data recovery include:

It does not require a certification authority or PKI infrastructure.
Data recovery policies can be managed centrally by means of Active Directory.
Users do not have to manage certificates or private keys for data recovery.
Decryption can be limited to the user alone.

The disadvantages of data recovery include:

An administrative process must recover user data. Users cannot recover their own data.
You cannot define the scope of what data can be recovered by a data recovery agent and what data cannot be recovered by a data recovery agent.
Data recovery occurs manually on a file-by-file basis.
Only data is recovered, and not the user keys. Therefore, after data recovery is completed, the user must re-enroll for new certificates.
It is assumed that, when a key is lost, the certificate is compromised. Therefore, administrators must revoke old certificates.
Stand-alone workstations or workstations in non-Active Directory environments cannot be centrally managed.

Key recovery allows a trusted agent to gain access to user private keys. For this reason, it is best to use key recovery only if your organization permits a person other than the original requester to have access to the private key of another user.

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 2008 and Windows Server 2003 enterprise CAs include a certificate template to support the key recovery agent role. A Windows Server CA CA can use only key recovery agent certificates that have been properly formatted and that have not expired. To enable key recovery, the following tasks need to be completed:

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

Setting Configuration Options for the Key Recovery Agent

Before a key recovery agent certificate can be configured, 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, the new Read and Enroll permissions on the template itself must be configured.

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.

The keys must be markedas 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 2000 do not allow for key archiving. You must create new version 2 or version 3 templates, which to support user enrollment with archiving.

Second, although you can configure the cryptographic service providers that are used for the private keys that are to be archived, you can only archive keys that are generated by means of a Rivest-Shamir-Adleman (RSA)-based CSP. The Digital Signature Standard (DSS) and Diffie-Hellman CSPs are not supported for key archiving.

Establishing Key Recovery Agent Policies

Allowing someone other than the original user to recover keys presents a security risk. Although you trust your administrators, there are limits to how much any individual can be trusted with the ability to recover other the key pairs of other users. For example, your key recovery agent might leave the organization, taking a copy of the key. Therefore it is recommended that you monitor key recovery plans carefully.

Consider limiting the time that any one individual serves as the key recovery agent, or consider dividing the responsibility between several individuals and requiring that a smart card be used to perform key recovery tasks.

In addition, employ the following key recovery policies:

If 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. Require new keys to be issued at the time of recovery. Revocation ensures that the user can still decrypt data with the old key but cannot encrypt new data.

Educating Users About Data Recovery and Key Recovery

Although the process of certificate enrollment and use is nearly transparent to end users, it is important to educate users about certificates and their use. Specifically, be sure to provide end users with the following information:

How to use the certificate enrollment user interface and certificate-enabled applications.
The capabilities of certificates.
The limitations of certificates.
Inappropriate or ineffective uses for certificates.
How to evaluate certificates received from others.
The importance of retaining expired certificates.
What to do in the event of an error message or if certificates fail to function as expected.

Share via

Active Directory Certificate Services (AD CS) Public Key Infrastructure (PKI) Design Guide

Identifying Your AD CS Deployment Goals

Digital signatures

Secure e-mail

Internet authentication

IP security

Smart card logon

Encrypting File System use and recovery certificates

Wireless 802.1X authentication

Authentication of network devices

Defining Certificate Requirements, Policies, and Practices

Determining client certificate requirements

Documenting certificate policies

Documenting certificate practices

Designing the CA Infrastructure

Plan Fundamental CA Options

Determine Critical Root CA Options

Select Internal CAs vs. External CAs

Internal CAs

External CAs

Plan for CA Capacity, Performance, and Scalability

Determine the Number of CAs Required

Do you require more than one CA?

If you need more than one CA, how many root CAs do you require?

How many intermediate or policy CAs do you need?

How many intermediate and issuing CAs do you need?

Define CA Types and Roles

Enterprise vs. stand-alone CAs

Establishing a root CA

Subordinate CAs

Use Offline CAs

Integrate the Active Directory Infrastructure

Configuring public key Group Policy

Select a CA Database Location

Establish a CA Naming Convention

Use Hardware CSPs and KSPs

Select a Trust Model

Rooted trust model

Network trust model

Hybrid trust model

Trust hierarchy based on quality of identification

Trust hierarchy based on organizational structure

Trust hierarchy based on location

Define CA Roles in the Trust Hierarchy

Define PKI Management and Delegation Options

Extending the CA Infrastructure

Identify Factors that Affect Extended Trust

Standards support

Algorithm support

CRL distribution points

Authority information access

Authority key identifier

Certificate extensions

Key length

Enhanced key usage

Directory integration

Select an Extended CA Trust Configuration

Using a non-Microsoft root CA configuration

Adding trusted root certificates to Group Policy

Using a new root CA configuration

Using a cross-certification configuration

Limit Unplanned Trusts

Using certificate trust lists to limit unplanned trusts

Defining Certificate Configuration Options

Select Certificate Templates

Select Certificate Issuance Options

Validty period

Expiration and renewal options

Subject names

Security

Issuance requirements

Superseded templates

Select Certificate Use Options

Request handling

Archive settings

Additional options (Windows Server 2008 only)

Cryptography

Extensions

Application policies