The Windows Server® 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:
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:
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.
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.
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.
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.
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
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.
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 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.
The widespread use of wireless networks in organizations and public areas creates the challenge of ensuring that:
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
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.
Return to Top
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.
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:
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:
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:
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.
Return to Top
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.
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:
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.
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:
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.
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.
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 disadvantages of using internal CAs include:
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:
The disadvantages of using external CAs include:
You might need to use both internal and external CAs, which will be discussed later in this article.
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 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.
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 network—for example, if it also functions as a domain controller—it 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 2008–based CA.
Note: Because of the architecture of their databases, Windows Server 2008–based 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
• 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.
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.
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..
For more information about using clustering to provide fault tolerance, see Configuring Certificate Services Clustering in Windows Server 2008.
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.
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
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).
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.
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 CAs—one to support internal users and the second to support external users.
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:
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.
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:
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.
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.
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
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
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.
The CA store
The transaction log file for the CA store
Reservation log file to store transactions if disk space is full
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.
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.
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.
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
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:
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:
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.
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.
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.
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:
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
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 requirements—for example, if you perform work for a government agency—or agency—or other local regulations.
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:
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 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.
Offline root CA
Offline intermediate CA
It 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:
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:
If you need stricter guidelines, you can include the following:
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
PKI administrative role
Windows Server 2008 administrative role
Configures, maintains, and renews the CA
Performs system backup and recovery
Backup operator on the server on which the CA is running
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
Approves certificate enrollment and revocation requests
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
Manages users and their associated information
Account operators or person delegated to create user accounts in Active Directory Domain Services (AD DS)
Requests certificates from the CA
The following table lists the actions that each PKI administrative role can perform.
Local server administrator
Install a CA
Configure a CA
Configure policy and exit modules
Stop and start the Active Directory Certificate Services (AD CS) service
Change CA configuration
Assign user roles
Establish user accounts
Maintain user accounts
Renew CA keys
Define key recovery agents
Define officer roles
Enable role separation
Issue and approve certificates
Reactivate certificates that have been revoked
Enable, publish, or configure certificate revocation list (CRL) schedules
Configure audit parameters
Back up the system
Restore the system
Read CA properties and CRLs
Read CA databases
Read CA configuration information
Read issued, revoked, and pending certificates
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
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:
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.
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:
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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 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.
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.
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:
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:
Implement these constraints when you configure your CA and user certificates.
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:
After a CTL is defined, it must be applied to client computers by means of Group Policy.
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:
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.
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 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.
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:
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:
Note: You can also create your own certificate templates.
Before the certificates are issued, you need to determine the following critical information:
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:
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.
Certificate issuance options that need to be assessed and, if necessary, modified, include:
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:
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 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.
Certificates expire when they reach the end of their established lifetime, unless:
Certificate lifetimes affect the security of your public key infrastructure (PKI) for the following reasons:
To create a certificate renewal strategy, determine the following:
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 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.
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:
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.
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:
You should assign or maintain Read permission for the Authenticated Users group. This permission allows all users and computers—including computers—including the CA running under the System context of a computer account—to 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.
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.
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:
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
The Request Handling tab for a certificate template also allows you to specify several user input settings associated with certificate issuance. These settings include:
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.
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:
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.
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 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:
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.
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.
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.
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.
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:
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 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.
CA Encryption Certificate
Smart Card Logon
Microsoft Trust List Signing
Root List Signer
For Windows Server 2008–based 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.
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 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:
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.
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:
For encryption key usage, the following options are available:
The certificate template information, also referred to as the certificate subject type, defines the purpose of a certificate template. Six subject types are recognized:
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.
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:
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.
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:
To select the certificate enrollment and renewal processes that are appropriate for your organization, you need to consider the following:
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:
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:
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:
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.
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
All certificates have specified lifetimes. However, in some situations, acertificate a certificate needs to be invalidated before it has reached the end of its lifetime. Creating policies for certificate revocation involves the following tasks:
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:
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?
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
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
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.
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.
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.
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.
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:
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.
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.
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:
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.
Uses Group Policy object
Services\Public Key Services\CertificationAuthorities
Certutil.exe or PKI Health Tool
Group policy trust
Domain Security Group Policy object
Group Policy MMC
NTAuth (for CAs trusted to issue authentication certificates)
Services\Public Key Services\NTAuth object
Manual trust on the local computer
Local computer and all users that log on to system
Certificates MMC for the local computer
Manual trust by user
Group Policy MMC or Add or Remove Programs in Control Panel
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 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.
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.
It is recommended that only administrators maintain certificate trust and that you store only CA certificates in the local computers certificate store.
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.
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
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:
The disadvantages of data recovery include:
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.
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 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.
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: