Active Directory Certificate Services

Active Directory Certificate Services (AD CS) provides customizable services for issuing and managing certificates in software security systems that use public key technologies. For background information about public key cryptography and the benefits of having a public key infrastructure (PKI), see Public Key Infrastructures.

You can use AD CS to create one or more certification authorities (CA) to receive certificate requests, verify the information in the requests and the identity of the requester, issue certificates, revoke certificates, and publish certificate revocation data.

With AD CS, you can also:

  • Set up Web enrollment, the Network Device Enrollment Service, and the Online Responder service.

  • Manage enrollment and revocation of certificates for users, computers, services, and network devices such as routers.

  • Use Group Policy to distribute and manage certificates.

Additional references

  • Active Directory Certificate Services Overview

  • Common Scenarios for Using Active Directory Certificate Services

  • Setting Up Active Directory Certificate Services

  • Managing a Certification Authority

  • Use the Network Device Enrollment Service

  • Using Policy to Manage Active Directory Certificate Services

  • Troubleshoot Active Directory Certificate Services

  • Active Directory Certificate Services Resources


Active Directory Certificate Services Overview

Active Directory Certificate Services (AD CS) role services can be set up on servers running operating systems including Windows Server 2008 R2, Windows Server 2008, Windows Server 2003, and Windows 2000 Server. However, not all operating systems support all features or design requirements, and creating an optimal design requires careful planning and lab testing before you deploy AD CS in a production environment. Although you can deploy AD CS with a single server for a single certification authority (CA), deployments can involve multiple servers configured as root CAs, policy CAs, and issuing CAs, and other servers configured as Online Responders.

The following table lists the AD CS components that can be configured on different editions of Windows Server 2008 R2.

Components | Web edition | Standard edition | Enterprise edition | Datacenter edition
CA | No | Yes | Yes | Yes
Network Device Enrollment Service | No | No | Yes | Yes
Online Responder service | No | No | Yes | Yes
CA Web Enrollment | No | Yes | Yes | Yes
Certificate Enrollment Web Service | No | Yes | Yes | Yes
Certificate Enrollment Policy Web Service | No | Yes | Yes | Yes

The following features are available on servers running Windows Server 2008 R2 that have been configured as CAs.

AD CS features | Web edition | Standard edition | Enterprise edition | Datacenter edition
Customizable version 2 and version 3 certificate templates | No | Yes | Yes | Yes
Key archival | No | No | Yes | Yes
Role separation | No | No | Yes | Yes
Certificate manager restrictions | No | No | Yes | Yes
Delegated enrollment agent restrictions | No | No | Yes | Yes
Certificate enrollment across forest boundaries | No | No | Yes | Yes

Customizing AD CS

AD CS includes programmable interfaces so that developers can create support for additional transports, policies, and certificate properties and formats. For information about customizing AD CS, see Certificate Services Architecture (http://go.microsoft.com/fwlink/?LinkId=91405).

Managing AD CS

The following Microsoft Management Console (MMC) snap-ins can be used to manage AD CS:

  • Certification Authority. The primary tool for managing a CA, certificate revocation, and certificate enrollment.

  • Certificate Templates. Used to duplicate and configure certificate templates for publication to Active Directory Domain Services (AD DS) and for use with enterprise CAs.

  • Online Responder. Used to configure and manage Online Certificate Status Protocol (OCSP) responders.

  • Enterprise PKI. Used to monitor multiple CAs, certificate revocation lists (CRLs), and authority information access locations, and to manage AD CS objects that are published to AD DS.

  • Certificates. Used to view and manage certificate stores for a computer, user, or service.

Additional references

  • Public Key Infrastructures

  • Types of Certification Authorities

  • Certificate Enrollment Web Service Overview

  • Certificate Enrollment Policy Web Service Overview

  • Configuring Certificate Enrollment Web Services for Enrollment Across Forest Boundaries


Public Key Infrastructures

A public key infrastructure (PKI) is a system of digital certificates, certification authorities (CAs), and registration authorities that verify and authenticate the validity of each entity that is involved in an electronic transaction through the use of public key cryptography. Standards for PKIs are still evolving, even as they are being widely implemented as a necessary element of electronic commerce. For more information about planning a PKI and using public key cryptography, see Active Directory Certificate Services Resources.

The Microsoft PKI supports a hierarchical CA model that is scalable and provides consistency with a growing number of commercial and other CA products.

In its simplest form, a certification hierarchy consists of a single CA. However, a hierarchy frequently contains multiple CAs with clearly defined parent/child relationships. In this model, the child subordinate CAs are certified by their parent CA-issued certificates, which bind a CA's public key to its identity. The CA at the top of a hierarchy is referred to as the root CA. The child CA of a root CA is called a subordinate CA. For more information, see Types of Certification Authorities.

In Windows, if you trust a root CA (by having its certificate in your Trusted Root Certification Authorities certificate store), you trust every subordinate CA that has a valid CA certificate in the hierarchy. Thus, a root CA is a very important point of trust in an organization and should be secured accordingly. For more information, see CA Certificates.

There are several practical reasons for setting up multiple subordinate CAs, including:

  • Usage. Certificates may be issued for a number of purposes, such as secure e-mail and network authentication. The issuing policy for these uses may be distinct, and separation provides a basis for administering these polices.

  • Organizational divisions. There may be different policies for issuing certificates, depending upon an entity's role in the organization. Again, you can create subordinate CAs to separate and administer these policies.

  • Geographic divisions. Organizations may have entities at multiple physical sites. Network connectivity between these sites may require individual subordinate CAs for many or all sites.

  • Load balancing. If your PKI will be used to issue and manage a large number of certificates, having only one CA can result in considerable network load for that single CA. Using multiple subordinate CAs to issue the same kind of certificates divides the network load between CAs.

  • Backup and fault tolerance. Multiple CAs increase the possibility that your network will always have operational CAs available to respond to user requests.

A CA hierarchy can also provide administrative benefits, including:

  • Flexible configuration of the CA security environment to tailor the balance between security and usability. For example, you may choose to employ special-purpose cryptographic hardware on a root CA, operate it in a physically secure area, or operate it offline. These may be unacceptable for subordinate CAs, due to cost or usability considerations.

  • The ability to "turn off" a specific portion of the CA hierarchy without affecting established trust relationships. For example, you can easily shut down and revoke an issuing CA certificate that is associated with a specific business unit without affecting other parts of the organization.

Additional references

  • Active Directory Certificate Services Overview


Types of Certification Authorities

A certification authority (CA) accepts a certificate request, verifies the requester's information according to the policy of the CA, and then uses its private key to apply its digital signature to the certificate. The CA then issues the certificate to the subject of the certificate for use as a security credential within a public key infrastructure (PKI). A CA is also responsible for revoking certificates and publishing a certificate revocation list (CRL).

A CA can be an outside entity, such as VeriSign, or it can be a CA that you create for use by your organization by installing Active Directory Certificate Services (AD CS). Each CA can have distinct proof-of-identity requirements for certificate requesters, such as a domain account, employee badge, driver's license, notarized request, or physical address. Identification checks such as this often warrant an onsite CA, so that organizations can validate their own employees or members.

Microsoft enterprise CAs use a person's user account credentials as proof of identity. In other words, if you are logged on to a domain and request a certificate from an enterprise CA, the CA can authenticate your identity based on your account in Active Directory Domain Services (AD DS).

Every CA also has a certificate to confirm its own identity, issued by another trusted CA or, in the case of root CAs, issued by itself. It is important to remember that anyone can create a CA. Therefore, a user or administrator must decide whether to trust that CA and, by extension, the policies and procedures that the CA has in place for confirming the identity of the entities that are issued certificates by that CA.

Root and subordinate CAs

A root CA is meant to be the most trusted type of CA in an organization's PKI. If the root CA is compromised or issues a certificate to an unauthorized entity, then any certificate-based security in your organization becomes vulnerable. Therefore, both the physical security and the certificate issuance policy of a root CA are normally more rigorous than those for subordinate CAs. While root CAs can be used to issue certificates to end users for such tasks as sending secure e-mail, in most organizations they will only be used to issue certificates to other CAs, called subordinate CAs.

A subordinate CA is a CA that has been issued a certificate by another CA in your organization. Typically, a subordinate CA will issue certificates for specific uses, such as secure e-mail, Web-based authentication, or smart card authentication. Subordinate CAs can also issue certificates to other CAs that are more subordinate. Together, a root CA, the subordinate CAs that have been certified by the root, and subordinate CAs that have been certified by other subordinate CAs form a certification hierarchy.

For more information about certification hierarchies, see Public Key Infrastructures.

Enterprise and stand-alone CAs

This version of AD CS supports the installation of stand-alone CAs and enterprise CAs. For information about the operational characteristics of enterprise CAs and stand-alone CAs, see Enterprise Certification Authorities and Stand-Alone Certification Authorities.

Additional references

  • Active Directory Certificate Services Overview


Enterprise Certification Authorities

Enterprise certification authorities (CAs) can issue certificates for purposes such as digital signatures, secure e-mail by using S/MIME (Secure Multipurpose Internet Mail Extensions), authentication to a secure Web server by using Secure Sockets Layer (SSL) or Transport Layer Security (TLS), and logging on to a domain by using a smart card.

An enterprise CA has the following characteristics:

  • Requires access to Active Directory Domain Services (AD DS).

  • Uses Group Policy to propagate its certificate to the Trusted Root Certification Authorities certificate store for all users and computers in the domain.

  • Publishes user certificates and certificate revocation lists (CRLs) to AD DS. In order to publish certificates to AD DS, the server that the CA is installed on must be a member of the Certificate Publishers group. This is automatic for the domain the server is in, but the server must be delegated the proper security permissions to publish certificates in other domains.

Note

You must be a member of the Domain Admins group or be an administrator with Write access to AD DS to install an enterprise root CA.

An enterprise CA issues certificates based on a certificate template. The following functionality is possible when you use certificate templates:

  • Enterprise CAs enforce credential checks on users during certificate enrollment. Each certificate template has a security permission set in AD DS that determines whether the certificate requester is authorized to receive the type of certificate they have requested.

  • The certificate subject name can be generated automatically from the information in AD DS or supplied explicitly by the requester.

  • The policy module adds a predefined list of certificate extensions to the issued certificate. The extensions are defined by the certificate template. This reduces the amount of information a certificate requester has to provide about the certificate and its intended use.

  • Autoenrollment can be used to issue certificates.

Additional references

  • Types of Certification Authorities


Stand-Alone Certification Authorities

Stand-alone certification authorities (CAs) can issue certificates for purposes such as digital signatures, secure e-mail by using S/MIME (Secure Multipurpose Internet Mail Extensions), and authentication to a secure Web server by using Secure Sockets Layer (SSL) or Transport Layer Security (TLS).

A stand-alone CA has the following characteristics:

  • Unlike an enterprise CA, a stand-alone CA does not require the use of Active Directory Domain Services (AD DS). Even if you are using AD DS, stand-alone CAs can be used as offline trusted root CAs in a CA hierarchy or to issue certificates to clients over an extranet or the Internet.

  • When users submit a certificate request to a stand-alone CA, they must provide their identifying information and specify the type of certificate they need. (This does not need to be done when submitting a request to an enterprise CA because the enterprise user's information is already in AD DS and the certificate type is described by a certificate template). The authentication information for requests is obtained from the local computer's Security Accounts Manager database.

  • By default, all certificate requests sent to the stand-alone CA are set to pending until the administrator of the stand-alone CA verifies the submitted information and approves the request. The administrator has to perform these tasks because the certificate requester's credentials are not verified by the stand-alone CA.

  • Certificate templates are not used.

  • The administrator has to explicitly distribute the stand-alone CA's certificate to the domain user's trusted root store, or users must perform that task themselves.

  • If a cryptographic provider supporting elliptic curve cryptography (ECC) is used, a stand-alone CA will honor every key usage for the ECC key. For more information, see Cryptography Next Generation (http://go.microsoft.com/fwlink/?LinkID=85480).

When a stand-alone CA uses AD DS, the CA has these additional features:

  • If a member of the Domain Admins group or an administrator with Write access to a domain controller installs a stand-alone root CA, it is automatically added to the Trusted Root Certification Authorities certificate store for all users and computers in the domain. For this reason, if you install a stand-alone root CA in an Active Directory domain, you should not change the default action of the CA upon receiving certificate requests (which marks requests as pending). Otherwise, you will have a trusted root CA that automatically issues certificates without verifying the identity of the certificate requester.

  • If a stand-alone CA is installed by a member of the Domain Admins group of the parent domain in the enterprise, or by an administrator with Write access to AD DS, then the stand-alone CA will publish its CA certificate and the certificate revocation list (CRL) to AD DS.

Additional references

  • Types of Certification Authorities


Certificate Enrollment Web Service Overview

The Certificate Enrollment Web Service is an Active Directory Certificate Services (AD CS) role service that enables users and computers to perform certificate enrollment by using the HTTPS protocol. Together with the Certificate Enrollment Policy Web Service, this enables policy-based certificate enrollment when the client computer is not a member of a domain or when a domain member is not connected to the domain.

The Certificate Enrollment Web Service uses the HTTPS protocol to accept certificate requests from and return issued certificates to network client computers. The Certificate Enrollment Web Service uses the DCOM protocol to connect to the certification authority (CA) and complete certificate enrollment on behalf of the requester. In previous versions of AD CS, policy-based certificate enrollment can be completed only by domain member client computers that are using the DCOM protocol. This limits certificate issuance to the trust boundaries established by Active Directory domains and forests.

Certificate enrollment over HTTPS enables the following new deployment scenarios:

  • Certificate enrollment across forest boundaries to reduce the number of CAs in an enterprise.

  • Extranet deployment to issue certificates to mobile workers and business partners.

Additional references

  • Certificate Enrollment Policy Web Service Overview


Certificate Enrollment Policy Web Service Overview

The Certificate Enrollment Policy Web Service is an Active Directory Certificate Services (AD CS) role service that enables users and computers to obtain certificate enrollment policy information. Together with the Certificate Enrollment Web Service, this enables policy-based certificate enrollment when the client computer is not a member of a domain or when a domain member is not connected to the domain.

The Certificate Enrollment Policy Web Service uses the HTTPS protocol to communicate certificate policy information to network client computers. The Web service uses the LDAP protocol to retrieve certificate policy from Active Directory Domain Services (AD DS) and caches the policy information to service client requests. In previous versions of AD CS, certificate policy information can be accessed only by domain client computers that are using the LDAP protocol. This limits policy-based certificate issuance to the trust boundaries established by AD DS forests.

Publishing enrollment policy over HTTPS enables the following new deployment scenarios:

  • Certificate enrollment across forest boundaries to reduce the number of certification authorities (CAs) in an enterprise.

  • Extranet deployment to issue certificates to mobile workers and business partners.

Additional references

  • Certificate Enrollment Web Service Overview


Common Scenarios for Using Active Directory Certificate Services

One or more certification authorities (CAs) can be configured to support a number of scenarios that require the added security that certificates can provide. The following checklists identify the general steps and procedures needed to configure one or more CAs to enable these scenarios.

  • Checklist: Configure CAs to Issue and Manage Certificates

  • Checklist: Protect Encrypted Data from Loss by Enabling Key Archival and Recovery

  • Checklist: Enhance Certificate Revocation Checking in Diverse Environments by Setting Up an Online Responder Array

  • Checklist: Authenticate Web Servers with Certificates Issued by a Windows-Based CA

  • Checklist: Enhance Wireless Network Security by Requiring Certificates for Authentication and Encryption

  • Checklist: Strengthen Identity Management by Issuing Certificates for Smart Cards


Checklist: Configure CAs to Issue and Manage Certificates

Most organizations deploy an offline root certification authority (CA) and one or more subordinate CAs as a public key infrastructure (PKI). After these CAs have been installed on servers, additional steps must be completed before the PKI can be used to issue, support, and manage certificates. These steps include setting up certificate revocation options, configuring certificates or certificate templates, and configuring enrollment and issuance options.

Task | Reference
Plan the PKI. | Public Key Infrastructures
Set up a stand-alone or enterprise root CA. | Install a Root Certification Authority
Set up additional subordinate CAs. (Optional) | Install a Subordinate Certification Authority
Complete additional CA configuration tasks. | Managing a Certification Authority
Install and configure certificate templates. | Managing Certificate Templates (http://go.microsoft.com/fwlink/?LinkId=142230)
Configure certificate enrollment. | Managing Certificate Enrollment


Checklist: Protect Encrypted Data from Loss by Enabling Key Archival and Recovery

If a certificate that is used to encrypt data with Encrypting File System (EFS) is lost, the data cannot be recovered unless a key recovery agent has been configured. Establishing a key archival and recovery plan based on Microsoft certification authority (CA) certificates can help you protect your organization's data resources from becoming irretrievable if the original EFS key is no longer accessible.

Task | Reference
Set up additional subordinate CAs. (Optional) | Install a Subordinate Certification Authority
Install and configure certificate templates. | Managing Certificate Templates (http://go.microsoft.com/fwlink/?LinkId=142230)
Configure key archival and recovery. | Managing Key Archival and Recovery
Configure certificate enrollment. | Managing Certificate Enrollment


Checklist: Enhance Certificate Revocation Checking in Diverse Environments by Setting Up an Online Responder Array

Unlike certificate revocation lists (CRLs), which are distributed periodically, contain information about all certificates that have been revoked or suspended, and can become quite large, an Online Responder responds to client requests for information about the status of individual certificates. The amount of data retrieved per request remains constant no matter how many revoked certificates there might be, which makes it easier to provide current status information to large numbers of clients when it might take an unacceptable amount of time for clients to download a CRL. Setting up multiple linked Online Responders in an Array can provide flexibility and scalability to revocation checking in diverse network environments.

Task | Reference
Set up additional subordinate certification authorities (CAs). | Install a Subordinate Certification Authority
Install and configure certificate templates. | Managing Certificate Templates (http://go.microsoft.com/fwlink/?LinkId=142230)
Configure the issuing CA to issue Online Certificate Status Protocol (OCSP) Response Signing certificates. | Configure a CA to Support OCSP Responders
Install and configure the Online Responder. | Set Up an Online Responder
Create a revocation configuration for the Online Responder. | Creating a Revocation Configuration
Create an Online Responder Array. | Managing an Online Responder Array (http://go.microsoft.com/fwlink/?LinkId=142234)


Checklist: Authenticate Web Servers with Certificates Issued by a Windows-Based CA

Certificates can be used to authenticate queries sent by clients to Web servers. By using certificates issued by a Microsoft certification authority (CA), clients can verify that the query results have not been tampered with and that the results were returned by the correct domain controller or Web server.

Task | Reference
Set up additional subordinate CAs. (Optional) | Install a Subordinate Certification Authority
Install and configure a Web Server certificate template. | Managing Certificate Templates (http://go.microsoft.com/fwlink/?LinkId=142230)
Configure certificate enrollment. | Managing Certificate Enrollment


Checklist: Enhance Wireless Network Security by Requiring Certificates for Authentication and Encryption

Wireless networks make it possible for network users to access data and resources from multiple locations without relying on a physical connection to the network. The large number and variety of wireless clients and the potential security risks that they pose make it important for administrators to enhance data protection and to prevent unwanted clients from accessing the network. Certificates issued and supported by a Microsoft certification authority (CA) can enhance the security of a wireless network with strong certificate-based authentication and encrypted communication between clients and network servers.

Task | Reference
Set up additional subordinate CAs. (Optional) | Install a Subordinate Certification Authority
Install and configure certificate templates, including the RAS and IAS Server, Workstation Authentication, and User certificate templates. | Managing Certificate Templates (http://go.microsoft.com/fwlink/?LinkId=142230)
Configure certificate enrollment. | Set Up Automatic Certificate Enrollment (http://go.microsoft.com/fwlink/?LinkId=142235)
Deploy RAS and IAS Server certificates. | Deploy a CA and NPS Server Certificate (http://go.microsoft.com/fwlink/?LinkID=141788)
Configure 802.1X wireless clients by using Group Policy. | Configure 802.1X Wireless Clients Running Windows Vista with Group Policy (http://go.microsoft.com/fwlink/?LinkId=141790)
Configure 802.1X wireless access points as Remote Authentication Dial-In User Service (RADIUS) clients in Network Policy Server (NPS). | Add a New RADIUS Client (http://go.microsoft.com/fwlink/?LinkId=141791)
If you want to perform authorization by group, create a user group in Active Directory Domain Services (AD DS) that contains the users who are allowed to access the network through the wireless access points. | Create a Group for a Network Policy (http://go.microsoft.com/fwlink/?LinkId=141794)
In NPS, configure one or more network policies for 802.1X wireless access. | Add a Network Policy (http://go.microsoft.com/fwlink/?LinkId=141792) Create Policies for 802.1X Wired or Wireless with a Wizard (http://go.microsoft.com/fwlink/?LinkId=141793)


Checklist: Strengthen Identity Management by Issuing Certificates for Smart Cards

Smart cards and other physical authentication tokens improve upon basic password-based authentication by requiring users to supplement something they know—a password or personal identification number (PIN)—with something they have—the smart card or token. An obstacle to smart card deployments has been the cost and difficulty in managing smart card certificates. However, issuing and managing certificates with a Windows-based certification authority (CA) can be an efficient and cost-effective solution for deploying smart cards.

Task | Reference
Set up additional subordinate CAs. (Optional) | Install a Subordinate Certification Authority
Install and configure certificate templates. | Managing Certificate Templates (http://go.microsoft.com/fwlink/?LinkId=142230)
Configure and implement a smart card enrollment station. | Set Up and Use a Smart Card Enrollment Station
Configure smart card clients. | Configure Smart Card Clients (http://go.microsoft.com/fwlink/?LinkID=94261)
Issue smart cards to users. | Issue Smart Cards (http://go.microsoft.com/fwlink/?LinkID=94262)


Setting Up Active Directory Certificate Services

Active Directory Certificate Services (AD CS) role services can be set up individually, with multiple role services on a single server, or with each role service installed on a separate server. For more information, see Active Directory Certificate Services Overview.

The following topics explain installation options for various AD CS role services:

  • Setting Up a Certification Authority

  • Set Up Certification Authority Web Enrollment Support

  • Configure the Network Device Enrollment Service

  • Setting Up Online Responder Services in a Network

  • Setting Up Certificate Enrollment Web Services


Setting Up a Certification Authority

Many organizations will set up multiple certification authorities (CAs), including a root and subordinate CA. The following topics describe how to set up different types of CAs and other installation-related procedures.

  • Install a Root Certification Authority

  • Install a Subordinate Certification Authority

  • Set Up a Certification Authority by Using a Hardware Security Module

  • Uninstall a Certification Authority


Install a Root Certification Authority

For most organizations, a root certification authority (CA) certificate is the first Active Directory Certificate Services (AD CS) role service that they install. In a basic public key infrastructure (PKI), a root CA may be the only CA that an organization deploys.

Whether you install just one CA or multiple CAs, the root CA certificate establishes the foundation and basic rules that govern certificate issuance and use for your entire PKI. Where the root certificate defines standards for what is acceptable and unacceptable in the PKI hierarchy, AD CS applies those standards to any other CAs and AD CS role services.

A root CA can be a stand-alone or enterprise CA. If there is more than one CA in the organization, many organizations minimize the exposure of their root CA by keeping it offline except when it is needed to process a request for a subordinate CA certificate.

Membership in local Administrators, or equivalent, is the minimum required to complete this procedure. If this will be an enterprise CA, membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. For more information, see Implement Role-Based Administration.

To install a root CA

  1. Open Server Manager, click Add Roles, click Next, and click Active Directory Certificate Services. Click Next two times.

  2. On the Select Role Services page, click Certification Authority. Click Next.

  3. On the Specify Setup Type page, click Standalone or Enterprise. Click Next.

    Note

    You must have a network connection to a domain controller in order to install an enterprise CA.

  4. On the Specify CA Type page, click Root CA. Click Next.

    For more information, see Types of Certification Authorities.

  5. On the Set Up Private Key page, click Create a new private key. Click Next.

  6. On the Configure Cryptography page, select a cryptographic service provider, key length, and hash algorithm. Click Next.

    For more information, see Cryptographic Options for CAs.

  7. On the Configure CA Name page, create a unique name to identify the CA. Click Next.

    For more information, see Certification Authority Naming.

  8. On the Set Validity Period page, specify the number of years or months that the root CA certificate will be valid. Click Next.

  9. On the Configure Certificate Database page, accept the default locations unless you want to specify a custom location for the certificate database and certificate database log. Click Next.

    For more information, see Certificates Database.

  10. On the Confirm Installation Options page, review all of the configuration settings that you have selected. If you want to accept all of these options, click Install and wait until the setup process has finished.

Additional references

  • Setting Up a Certification Authority

  • Certification Authority Naming

  • Cryptographic Options for CAs

  • Certificates Database

  • Install a Subordinate Certification Authority


Certification Authority Naming

Before you configure certification authorities (CAs) in your organization, you should 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 might want to use the ANSI character set if interoperability is a concern. For example, certain types of routers will not be able to use the Network Device Enrollment Service to enroll for certificates if the CA name contains special characters such as an underscore.

Important

If you use non-Latin characters (such as Cyrillic, Arabic, or Chinese characters), your CA name must contain fewer than 64 characters. If you use only non-Latin characters, your CA name can be no more than 37 characters in length.

In Active Directory Domain Services (AD DS), the name that you specify when you configure a server as a CA becomes the common name of the CA, and this name 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 for the common name of the CA. This way, malicious users who obtain a copy of a certificate cannot identify and use the fully qualified domain name of the CA to create a potential security vulnerability.

The CA name does not have to be identical to the name of the computer. However, you cannot change the name of a server after Active Directory Certificate Services (AD CS) has been installed without invalidating all the certificates issued by the CA.

To change the server name after AD CS 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.

Additional references

  • Install a Root Certification Authority

  • Administering Active Directory Domain Rename in Windows Server 2008 (http://go.microsoft.com/fwlink/?LinkId=143938)

  • Windows Server 2003 Active Directory Domain Rename Tools (http://go.microsoft.com/fwlink/?LinkId=91448)


Cryptographic Options for CAs

Selecting cryptographic options for a certification authority (CA) can have significant security, performance, and compatibility implications for that CA. Although the default cryptographic options may be suitable for most CAs, the ability to implement custom options can be useful to administrators and application developers with a more advanced understanding of cryptography and a need for this flexibility. Cryptographic options can be implemented by using cryptographic service providers (CSPs) or key storage providers.

CSPs are hardware and software components of Windows operating systems that provide generic cryptographic functions. CSPs can be written to provide a variety of encryption and signature algorithms.

Key storage providers can provide strong key protection on computers running Windows Server 2008 R2, Windows Server 2008, Windows 7, or Windows Vista.

On the Configure Cryptography page of the CA setup process, you can configure the following options:

  • Select a cryptographic service provider. Windows Server 2008 R2 and Windows Server 2008 include a number of CSPs, and additional CSPs or key storage providers can be added. In Windows Server 2008 R2 and Windows Server 2008, the provider list includes the name of the algorithm. All providers with a number sign (#) in the name are Cryptography Next Generation (CNG) providers. CNG providers can support multiple asymmetric algorithms. CSPs can implement only a single algorithm.

    Note

    For more information, see Cryptography Next Generation (http://go.microsoft.com/fwlink/?LinkID=85480).

  • Key character length. Each CSP supports different character lengths for cryptographic keys. Configuring a longer key character length can enhance security by making it more difficult for a malicious user to decrypt the key, but it can also slow down the performance of cryptographic operations.

  • Select the hash algorithm for signing certificates issued by this CA. Hash algorithms are used to sign CA certificates and certificates issued by a CA to ensure that they have not been tampered with. Each CSP can support different hash algorithms.

    Note

    The list of available hash algorithms can be restricted further if the DiscreteAlgorithm option has been configured in a CAPolicy.inf file installed on the computer before CA setup begins.

  • Use strong private key protection features provided by the CSP (this may require administrator interaction every time the private key is accessed by the CA). This option can be used to help prevent unapproved use of the CA and its private key by requiring the administrator to enter a password before every cryptographic operation.

Additional references

  • Install a Root Certification Authority


Certificates Database

When you install a certification authority (CA), you also need to create a CA database to record:

  • Every certificate issued by the CA.

  • Every private key archived by the CA.

  • Every certificate revoked by the CA.

  • Every certificate request received by the CA, regardless of whether the request is approved, denied, or set to pending.

This database should be located on an NTFS file system partition on the server's disk drives to provide the best security possible for the database file. You specify the locations for the database during the setup of a CA. By default, the database is located in systemroot\system32\certlog.

You also specify the location of the CA database log during Active Directory Certificate Services (AD CS) setup. The CA database log keeps a record of every transaction involving the CA database. CA database logs are used when restoring the CA from a backup. If a CA is restored from a backup that is one month old, then the CA database can be updated with more recent activity recorded in the log to restore the database to its most current state. When you back up a CA, the existing certificate database logs will be truncated in size because they will no longer be needed to restore the certificate database to its most current state.

The name of the database file is based on the name of the CA, with an .edb extension.

The Certification Authority snap-in allows you to view and administer the CA database.

For more information about CA backup and restore, see Protecting a CA from Data Loss.

Additional references

  • Install a Root Certification Authority


Install a Subordinate Certification Authority

After a root certification authority (CA) has been installed, many organizations will install one or more subordinate CAs to implement policy restrictions on the public key infrastructure (PKI) and to issue certificates to end clients. Using at least one subordinate CA can help protect the root CA from unnecessary exposure.

If a subordinate CA will be used to issue certificates to users or computers with accounts in an Active Directory domain, installing the subordinate CA as an enterprise CA allows you to use the client's existing account data in Active Directory Domain Services (AD DS) to issue and manage certificates and to publish certificates to AD DS.

Membership in local Administrators, or equivalent, is the minimum required to complete this procedure. If this will be an enterprise CA, membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. For more information, see Implement Role-Based Administration.

To install a subordinate CA

  1. Open Server Manager, click Add Roles, click Next, and click Active Directory Certificate Services. Click Next two times.

  2. On the Select Role Services page, click Certification Authority, and then click Next.

  3. On the Specify Setup Type page, click Standalone or Enterprise, and then click Next.

    For more information, see Types of Certification Authorities.

    Note

    You must have a network connection to a domain controller in order to install an enterprise CA.

  4. On the Specify CA Type page, click Subordinate CA, and then click Next.

  5. On the Set Up Private Key page, click Create a new private key, and then click Next.

  6. On the Configure Cryptography page, select a cryptographic service provider, key length, and hash algorithm. Click Next.

    For more information, see Cryptographic Options for CAs.

  7. On the Request Certificate page, browse to locate the root CA, or if the root CA is not connected to the network, save the certificate request to a file so that it can be processed later. Click Next.

    Note

    The subordinate CA cannot be used until it has been issued a root CA certificate and this certificate has been used to complete the installation of the subordinate CA.

  8. On the Configure CA Name page, create a unique name to identify the CA. Click Next.

    For more information, see Certification Authority Naming.

  9. On the Set Validity Period page, specify the number of years or months that the CA certificate will be valid. Click Next.

  10. On the Configure Certificate Database page, accept the default locations unless you want to specify a custom location for the certificate database and certificate database log. Click Next.

    For more information, see Certificates Database.

  11. On the Confirm Installation Options page, review all of the configuration settings that you have selected. If you want to accept all of these options, click Install and wait until the setup process has finished.

Additional references

  • Setting Up a Certification Authority

  • Install a Root Certification Authority


Set Up a Certification Authority by Using a Hardware Security Module

Using a hardware security module (HSM) can enhance the security of a certification authority (CA) and public key infrastructure (PKI).

An HSM is a dedicated hardware device that is managed separately from the operating system. These modules provide a secure hardware store for CA keys, as well as a dedicated cryptographic processor to accelerate signing and encrypting operations. Windows utilizes the HSM through the CryptoAPI interfaces—the HSM functions as a cryptographic service provider (CSP) device.

HSMs typically are PCI adapters but are also available as network-based appliances. If an organization plans to implement two or more CAs, you can install a single network-based HSM and share it among multiple CAs.

In order to set up a CA by using an HSM, the HSM must be installed and configured before you set up any CAs whose keys will be stored on the HSM.

Additional references

  • Setting Up a Certification Authority


Uninstall a Certification Authority

There may be times when you need to uninstall a certification authority (CA). However, clients will not be able to send requests to this CA and some applications that depend on your public key infrastructure (PKI) may not function properly after a CA that is needed to verify the validity and revocation status of a certificate has been uninstalled.

If you are permanently decommissioning the CA before its expected expiration date, then the CA certificate should be revoked from its parent CA and you should list "Cease of operation" as the reason for the revocation. If the CA is a self-signed root CA, then all of the certificates issued by the CA that have not expired should be revoked and a certificate revocation list (CRL) should be generated that lists the same reason. This will indicate that the certificates are no longer valid because the CA has been decommissioned.

Uninstalling an enterprise CA should be done properly to ensure that its CA enrollment object is removed from Active Directory Domain Services (AD DS). Failure to do so may cause Active Directory clients to continue attempts to enroll for certificates from that CA. If an enterprise CA cannot be uninstalled normally, use the Enterprise PKI snap-in to manually remove the CA objects from AD DS.

If you are uninstalling an enterprise CA, membership in Enterprise Admins, or equivalent, is the minimum required to complete this procedure. For more information, see Implement Role-Based Administration.

To uninstall a CA

  1. Click Start, point to Administrative Tools, and click Server Manager.

  2. Under Roles Summary, click Remove Roles to start the Remove Roles Wizard. Click Next.

  3. Clear the Active Directory Certificate Services check box, and click Next.

  4. On the Confirm Removal Options page, review the information, and then click Remove.

  5. If Internet Information Services (IIS) is running and you are prompted to stop the service before proceeding with the uninstall process, click OK.

  6. After the Remove Roles Wizard is finished, you must restart the server to complete the uninstall process.

The procedure is slightly different if you have multiple Active Directory Certificate Services (AD CS) role services installed on a single server. You can use the following procedure to uninstall a CA but retain other AD CS role services.

You must log on with the same permissions as the user who installed the CA to complete this procedure. If you are uninstalling an enterprise CA, membership in Enterprise Admins, or equivalent, is the minimum required to complete this procedure. For more information, see Implement Role-Based Administration.

To uninstall a CA role service

  1. Click Start, point to Administrative Tools, and click Server Manager.

  2. Under Roles Summary, click Active Directory Certificate Services.

  3. Under Roles Services, click Remove Role Services.

  4. Clear the Certification Authority check box, and click Next.

  5. On the Confirm Removal Options page, review the information, and then click Remove.

  6. If IIS is running and you are prompted to stop the service before proceeding with the uninstall process, click OK.

  7. After the Remove Roles Wizard is finished, you must restart the server to complete the uninstall process.

If the remaining role services, such as the Online Responder service, were configured to use data from the uninstalled CA, you must reconfigure these services to support a different CA.

After a CA has been uninstalled, the following information is left on the server:

  • The CA database

  • The CA public and private keys

  • The CA's certificates in the Personal store

  • The CA's certificates in the shared folder, if a shared folder was specified during AD CS setup

  • The CA chain's root certificate in the Trusted Root Certification Authorities store

  • The CA chain's intermediate certificates in the Intermediate Certification Authorities store

  • The CA's CRL

This information is kept on the server by default, in case you are uninstalling and then reinstalling the CA. For example, you might uninstall and reinstall the CA if you want to change a stand-alone CA to an enterprise CA.

Additional references

  • Setting Up a Certification Authority


Set Up Certification Authority Web Enrollment Support

Active Directory Certificate Services (AD CS) Web enrollment support can be installed on any computer running Windows Server 2008 R2 Standard, Windows Server 2008 R2 Enterprise, Windows Server 2008 R2 Datacenter, Windows Server 2008 Standard, Windows Server 2008 Enterprise, or Windows Server 2008 Datacenter. The certificate enrollment data can come from a certification authority (CA) on a computer running Windows Server 2008 R2, Windows Server 2008, or Windows Server 2003, or from a non-Microsoft CA.

The following procedure can be used if none of the AD CS role services (such as a CA) have been installed on this computer.

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. For more information, see Implement Role-Based Administration.

To install Web enrollment support

  1. Click Start, point to Administrative Tools, and then click Server Manager.

  2. Click Manage Roles. Under Active Directory Certificate Services, click Add role services. If a different AD CS role service has already been installed on this computer, select the Active Directory Certificate Services check box in the Role Summary pane, and then click Add role services.

  3. On the Select Role Services page, select the Certification Authority Web Enrollment check box.

  4. Click Add required role services, and then click Next.

  5. On the Specify CA page, if a CA is not installed on this computer, click Browse to select the CA that you want to associate with Web enrollment, click OK, and then Next.

  6. Click Next, review the information listed, and click Next again.

  7. On the Confirm Installation Options page, click Install.

  8. When the installation is complete, review the status page to verify that the installation was successful.

Additional considerations

  • Installation of the Web enrollment pages configures the computer as a registration authority. This computer is also known as a "CA Web proxy" or a "Web enrollment station."

Additional references

  • Setting Up a Certification Authority


Configure the Network Device Enrollment Service

Setting up the Network Device Enrollment Service involves the following tasks:

  • Add the account that will be the registration authority to the Internet Information Services (IIS) user group.

  • Set up and configure the Network Device Enrollment Service.

Membership in the Administrators group is the minimum required to complete this procedure. For more information, see Implement Role-Based Administration.

To add a designated registration authority to the IIS_IUSRS group

  1. Open the Local Users and Groups snap-in, and double-click the Groups folder.

  2. Click the IIS_IUSRS built-in group.

  3. On the Action menu, click Add to Group.

  4. Click Add, type the domain name of the account that will be the registration authority, and then click OK.

Membership in Enterprise Admins or Domain Admins, or equivalent, is the minimum required to complete this procedure. For more information, see Implement Role-Based Administration.

To set up and configure the Network Device Enrollment Service

  1. On the server where you want to install the Network Device Enrollment Service, open Server Manager, and click Add Roles to start the Add Roles Wizard.

  2. On the Select Server Roles page, select the Active Directory Certificate Services check box, and then click Next two times.

  3. On the Select Role Services page, clear the Certification Authority check box, and then select the Network Device Enrollment Service check box.

    You are prompted to install IIS and Windows Activation Service.

  4. Click Add Required Role Services, and then click Next three times.

  5. On the Specify User Account page, click Select User, and type the user name and password for the account that the Network Device Enrollment Service will use to authorize certificate requests. Click OK, and then click Next.

  6. On the Specify CA page, if this computer does not host a CA, select either the CA name or Computer name check box, click Browse to locate the CA that will issue the Network Device Enrollment Service certificates, and then click Next.

  7. On the Specify Registry Authority Information page, type the name of the registration authority in the RA name box. Under Country/region, select the country/region you are in, and then click Next.

  8. On the Configure Cryptography page, accept the default values for the signature and encryption keys or configure your own values, and then click Next.

  9. Review the summary of configuration options, and then click Install.

For more information about the Simple Certificate Enrollment Protocol (SCEP), see the Internet Engineering Task Force Web site (http://go.microsoft.com/fwlink/?LinkId=71055).

For more information about the Network Device Enrollment Service, see AD CS: Network Device Enrollment Service (http://go.microsoft.com/fwlink/?LinkId=85475) and Microsoft SCEP Implementation Whitepaper (http://go.microsoft.com/fwlink/?LinkId=93875).

Additional references

  • Setting Up Active Directory Certificate Services

  • Use the Network Device Enrollment Service


Setting Up Online Responder Services in a Network

Setting up Online Responder services involves several interrelated steps. Several of these steps must be performed on the certification authority (CA) that will be used to issue the Online Certificate Status Protocol (OCSP) signing certificates necessary for an Online Responder to function. These steps include configuring the appropriate certificate template, enabling the certificate template, and configuring and completing certificate autoenrollment so that the computer hosting the Online Responder has the certificates needed for the Online Responder to function.

Installation and configuration of an Online Responder involves using Server Manager to install the Online Responder service, the Certificate Templates snap-in to configure and publish OCSP Response Signing certificate templates, the Certification Authority snap-in to include OCSP extensions in the certificates that it will issue and to issue OCSP Response Signing certificates, and the Online Responder snap-in to create a revocation configuration.

The following topics describe the steps needed to complete these installation and configuration steps and how to verify that the installation was successful.

  • Configure a CA to Support OCSP Responders

  • Set Up an Online Responder

  • Creating a Revocation Configuration

  • Verify an Online Responder Installation


Configure a CA to Support OCSP Responders

To function properly, an Online Responder must have a valid Online Certificate Status Protocol (OCSP) Response Signing certificate. This OCSP Response Signing certificate is also needed if you are using a non-Microsoft OCSP responder.

Configuring a certification authority (CA) to support OCSP responder services includes the following steps:

  1. Configure certificate templates and issuance properties for OCSP Response Signing certificates.

  2. Configure enrollment permissions for any computers that will be hosting Online Responders.

  3. If this is a Windows Server 2003–based CA, enable the OCSP extension in issued certificates.

  4. Add the location of the Online Responder or OCSP responder to the authority information access extension on the CA.

  5. Enable the OCSP Response Signing certificate template for the CA.

The certificate template used to issue an OCSP Response Signing certificate must contain an extension titled "OCSP No Revocation Checking" and the OCSP Signing application policy. Permissions must also be configured to allow the computer that will host the Online Responder to enroll for this certificate.

The following procedure is for a CA that is installed on a computer running Windows Server 2008 R2 or Windows Server 2008.

Membership in Domain Admins or Enterprise Admins, or equivalent, is the minimum required to complete this procedure. For more information about administering a public key infrastructure (PKI), see Implement Role-Based Administration.

To configure the certificate template for an OCSP Response Signing certificate issued by a Windows Server 2008 R2–based CA or a Windows Server 2008–based CA

  1. Open the Certificate Templates snap-in.

    Note

    If you are completing this procedure on a computer that does not have a CA or Online Responder installed, you may need to install the Active Directory Certificate Services (AD CS) Remote Server Administration Tools in order to use the Certificate Templates snap-in. For more information about the Remote Server Administration Tools, see Administer an Online Responder from Another Computer.

  2. Right-click the OCSP Response Signing template, and then click Properties.

  3. Click the Security tab. Under Group or user name, click Add.

  4. Click Object Types, select the Computers check box, and then click OK.

  5. Type the name of or browse to select the computer hosting the Online Responder or OCSP responder services, and click OK.

  6. In the Group or user names dialog box, click the computer name, and in the Permissions dialog box, select the Read and Enroll check boxes. Then click OK.

The following procedure is for a CA that is installed on a computer running Windows Server 2003. The procedure must be completed on a computer running Windows Server 2008 R2 or Windows Server 2008.

Membership in Domain Admins or Enterprise Admins, or equivalent, is the minimum required to complete this procedure. For more information about administering a PKI, see Implement Role-Based Administration.

To configure the certificate template for an OCSP Response Signing certificate issued by a Windows Server 2003–based CA

  1. Open the Certificate Templates snap-in.

  2. Right-click the OCSP Response Signing template, and then click Duplicate. Click Windows 2003 Server, Enterprise Edition, and then click OK.

  3. Click the Security tab. Under Group or user name, click Add, and then type the name of or browse to select the computer hosting the Online Responder or OCSP responder services.

  4. Click Object Types, select the Computers check box, and then click OK.

  5. Type the name of or browse to select the computer hosting the Online Responder or OCSP responder services, and click OK.

  6. In the Group or user names dialog box, click the computer name, and in the Permissions dialog box, select the Read and Enroll check boxes.

Note

The default OCSP Response Signing certificate template contains an extension titled "OCSP No Revocation Checking." Do not remove this extension, which is used by many clients to verify that responses signed with the signing certificate are valid.

If the CA is installed on a computer running Windows Server 2003, you must complete the following procedure in order to configure the policy module on the CA to issue certificates that include this extension.

You must be a local administrator to complete this procedure. For more information about administering a PKI, see Implement Role-Based Administration.

To prepare a computer running Windows Server 2003 to issue OCSP Response Signing certificates

  1. On the server hosting the CA, open a command prompt, and type:

    certutil -v -setreg policy\EnableRequestExtensionList +1.3.6.1.5.5.7.48.1.5

  2. Stop and restart the CA. You can do this at a command prompt by running the following commands:

    net stop certsvc
net start certsvc

To configure your CA for OCSP, you must use the Certification Authority snap-in to complete the following CA configuration steps:

  • Add the location of the Online Responder or OCSP responder to the authority information access extension.

  • Enable the certificate template for the CA.

You must be a CA administrator to complete this procedure. For more information about administering a PKI, see Implement Role-Based Administration.

To configure a CA to support an Online Responder or OCSP responder services

  1. Open the Certification Authority snap-in.

  2. In the console tree, click the name of the CA.

  3. On the Action menu, click Properties.

  4. Click the Extensions tab.

  5. In the Select extension list, click Authority Information Access (AIA), and then click Add.

  6. Specify the locations from which users can obtain certificate revocation data, such as http://computername/ocsp.

  7. Select the Include in the online certificate status protocol (OCSP) extension check box.

  8. In the console tree of the Certification Authority snap-in, right-click Certificate Templates, and then click New Certificate Templates to Issue.

  9. In Enable Certificate Templates, select the OCSP Response Signing template and any other certificate templates that you configured previously, and then click OK.

  10. Double-click Certificate Templates, and verify that the modified certificate templates appear in the list.

Additional references

  • Setting Up Online Responder Services in a Network

  • Renew OCSP Response Signing Certificates with an Existing Key


Set Up an Online Responder

An Online Responder can be installed on any computer running Windows Server 2008 R2 Enterprise, Windows Server 2008 R2 Datacenter, Windows Server 2008 Enterprise, or Windows Server 2008 Datacenter. The certificate revocation data can come from a certification authority (CA) on a computer running Windows Server 2008 R2, Windows Server 2008, Windows Server 2003, or from a non-Microsoft CA.

Note

Internet Information Services (IIS) must also be installed on this computer before the Online Responder can be installed.

The following procedure can be used if none of the Active Directory Certificate Services (AD CS) role services (such as a CA) have been installed on this computer.

Membership in local Administrators, or equivalent, is the minimum required to complete this procedure. For more information about administering a public key infrastructure (PKI), see Implement Role-Based Administration.

To install the Online Responder service

  1. Click Start, point to Administrative Tools, and then click Server Manager.

  2. Click Manage Roles. Under Active Directory Certificate Services, click Add role services. If a different AD CS role service has already been installed on this computer, select the Active Directory Certificate Services check box in the Role Summary pane, and then click Add role services.

  3. On the Select Role Services page, select the Online Certificate Status Protocol check box.

    A message appears explaining that IIS and Windows Activation Service (WAS) must also be installed to support OCSP.

  4. Click Add required role services, and then click Next three times.

  5. On the Confirm Installation Options page, click Install.

  6. When the installation is complete, review the status page to verify that the installation was successful.

Additional considerations

  • Before an Online Responder can be used, you must also create a revocation configuration. See Creating a Revocation Configuration.

  • By default, IIS 7.0 request filtering blocks the plus sign (+), which is used in the URL of delta CRLs. To allow delta CRL retrieval, modify the IIS configuration by setting allowDoubleEscaping=true on the requestFiltering element in the system.web section of IIS configuration. For more information about IIS 7.0 request filter configuration, see IIS 7.0: Configure Request Filters in IIS 7.0 (http://go.microsoft.com/fwlink/?LinkId=136512.)

    Security Note

    Allowing certain characters to pass through the request filter can result in a reduced security level, which might be unacceptable in some environments. For an explanation of this type of threat, see chapter 12 of Writing Secure Code (http://go.microsoft.com/fwlink/?LinkId=136514).

Additional references

  • Setting Up Online Responder Services in a Network


Creating a Revocation Configuration

An Online Responder can make revocation information available from multiple certification authorities (CAs) and multiple CA certificates. However, each CA and CA certificate served by an Online Responder requires a separate revocation configuration.

A revocation configuration includes all of the settings that are needed to respond to status requests regarding certificates that have been issued by using a specific CA key. These configuration settings include the following:

  • CA certificate. This certificate can be located in Active Directory Domain Services (AD DS), in the local certificate store, or imported from a file.

  • Signing certificate for the Online Responder. This signing certificate can be selected automatically for you, selected manually (which involves a separate import step after you add the revocation configuration), or you can use the selected CA certificate to also serve as the signing certificate.

  • Revocation provider. The revocation provider will provide the revocation data used by this configuration. For a Windows Server 2008 R2 or Windows Server 2008 provider, this information is entered as one or more URLs where valid base CRLs and delta CRLs can be obtained.

Before you begin to add a new revocation configuration, make sure you have the information in the preceding list available.

You must have Manage Online Responder permissions on all of the Online Responders in the Array to complete this procedure. For more information about administering a public key infrastructure, see Implement Role-Based Administration.

To add a revocation configuration to an Online Responder

  1. Open the Online Responder snap-in.

  2. In the console tree, click Revocation Configuration.

    A list of existing revocation configurations appears in the details pane.

  3. In the Actions pane, click Add Revocation Configuration to start the Add Revocation Configuration Wizard.

  4. Provide the information requested in the wizard.

    • For information about the Select CA Certificate Location page, see Revocation Configuration CA Certificates.

    • For information about the Select Signing Certificate page, see Revocation Configuration Signing Certificates.

  5. When all the information has been entered, click Finish, and then click Yes to complete the setup process.

You can modify the properties of an existing revocation configuration, view its CA certificate, or delete the revocation configuration, by selecting the revocation configuration and clicking Edit Properties in the Actions pane.

The following properties of a revocation configuration can be modified:

  • Local CRL. For more information, see Manage Revocation Data Using Local CRLs.

  • Revocation provider. For more information, see Revocation Provider Properties.

  • Signing. For more information, see Revocation Provider Signing.

Additional references

  • Setting Up Online Responder Services in a Network


Revocation Configuration CA Certificates

Use the following criteria to select the revocation configuration certificate:

  • If the certification authority (CA) certificate has been published to Active Directory Domain Services (AD DS) and the computer you are configuring has access to this information in AD DS, click Select a certificate for an existing enterprise CA.

  • If AD DS cannot be accessed and you know the name of the CA certificate and that it exists in the local root certificate store, click Select a certificate from the local certificate store.

    Note

    This option is not available if the Online Responder is not on the same computer as the Online Responder snap-in.

  • If AD DS cannot be accessed and the CA certificate (with a .cer extension) is available on removable media, click Import certificate from a file.

Additional references

  • Creating a Revocation Configuration


Revocation Configuration Signing Certificates

The following options are available for selecting a revocation configuration signing certificate:

  • The default option, Automatically select a signing certificate, will generally meet most organization's needs. This option allows the revocation configuration setup process to identify a suitable signing certificate in the local certificate store. However, if you also enable an option to automatically enroll for a signing certificate, the Online Responder service will enroll for and use that signing certificate.

  • When selecting Manually select a signing certificate, the Online Responder will not assign any signing certificate and the user will have to manually select a signing certificates for each of the Online Responder Array members.

  • Use the CA certificate for the revocation configuration can be selected if the Online Responder is installed on the same computer as the certification authority (CA).

Note

The default installation of Online Responder services does not allow for automatic enrollment of the Online Certificate Status Protocol (OCSP) Response Signing certificate from a hardware security module (HSM) that requires interaction from the user. If you need to use an HSM to distribute OCSP Response Signing certificates, you must modify the Online Responder service to run as Local System with interaction enabled. In addition, on the Signing tab of the Online Responder Properties page, the Do not display UI for cryptographic operations check box must be cleared.

Additional references

  • Creating a Revocation Configuration


Revocation Provider Properties

The revocation provider retrieves the certificate revocation list (CRL) from a certification authority (CA) and uses the revocation list to determine the revocation status of a certificate. Use the Revocation Provider property sheet to specify one or more locations for a CRL and optional delta CRL, and to define the refresh interval for retrieving updated CRLs.

Base CRL and delta CRL locations

The location of CRLs and delta CRLs can be specified in the formats described in the table below. Any CRL locations defined in the CRL distribution point extension of the CA certificate are added to the revocation provider during installation of the Online Responder service.

Location format | Example
HTTP | http://OnlineResponderHost/OCSP/CRLFile.crl
LDAP | ldap:///CN=CACommonName,CN=CAHostName,CN=CDP,CN=Public Key Services,CN=Services,CN=Configuration,DC=Fabrikam,DC=com?certificateRevocationList?base?objectClass=cRLDistributionPoint

Multiple locations can be provided for a CRL. The order of the list defines the order of precedence. A CRL listed at a higher position is used if any two CRLs do not contain the same revocation list.

Refresh interval

The default refresh interval is defined as the CRL validity period. The interval can also be defined in minutes to refresh the CRLs more frequently.

Additional references

  • Creating a Revocation Configuration


Revocation Provider Signing

The Signing tab on the Online Responder Properties page shows the hash algorithm that is used to help verify signing operations for Online Responder responses to clients.

The following signing options can be configured:

  • Do not prompt for credentials for cryptographic operations. If the signing key is strongly protected by an additional password, selecting this option means the Online Responder will not prompt the user for the password and will fail silently.

    Note

    Do not select this option if a hardware security module (HSM) is used to protect private keys.

  • Automatically use renewed signing certificates. Instructs the Online Responder to automatically use renewed signing certificates without asking the Online Responder administrator to manually assign them.

  • Enable NONCE extensions support. Instructs the Online Responder to inspect and process an Online Certificate Status Protocol (OCSP) request that includes a nonce extension. If a nonce extension is included in the OCSP request and this option is selected, the Online Responder will ignore any cached OCSP response and will create a new response that includes the nonce provided in the request. If this option is disabled and a request that includes a nonce extension is received, the Online Responder will reject the request with an "unauthorized" error.

    Note

    The Microsoft OCSP client does not support the nonce extension.

  • Use any valid OCSP signing certificate. By default, the Online Responder will only use signing certificates that are issued by the same certification authority (CA) that issued the certificate being validated. This option allows modifying the default behavior and instructs the Online Responder to use any valid existing certificate that includes the OCSP Signing EKU extension.

    Note

    Clients running versions of Windows earlier than Windows Vista with Service Pack 1 (SP1) do not support this option, and certificate status requests from these clients will fail if this option is selected.

The following Online Responder identifier options can be used to select whether to include the key hash or the subject of the signing certificate in the response:

  • Key hash of the signing certificate. Some cryptographic service providers (CSPs) require the key hash of the signing certificate in order to access private keys.

  • Subject of the signing certificate. Some CSPs require the subject of the signing certificate in order to access private keys.

Additional references

  • Creating a Revocation Configuration


Verify an Online Responder Installation

After you have completed setting up an Online Responder, you can verify that it is functioning properly by confirming that you can autoenroll certificates, revoke certificates, and make accurate revocation data available from the Online Responder.

You must be a certification authority (CA) administrator to complete this procedure. For more information about administering a public key infrastructure (PKI), see Implement Role-Based Administration.

To verify that the Online Responder functions properly

  1. On the CA, configure several certificate templates for autoenrollment by computers and users.

  2. After the new certificate templates have been published to Active Directory Domain Services (AD DS), open a command prompt on the client computer and enter the following command to start certificate autoenrollment:

    certutil -pulse

    Note

    It can take several hours for information about new certificates to be replicated to all domain controllers.

  3. On the client computer, use the Certificates snap-in to verify that the new certificates have been issued. If they have not been issued, repeat step 2. You can also restart the client computer to start certificate autoenrollment.

  4. On the CA, use the Certification Authority snap-in to view and revoke one or more of the issued certificates by clicking Certification Authority (Computer)\CA name\Issued Certificates and selecting the certificate you want to revoke. On the Action menu, point to All Tasks, and then click Revoke Certificate. Select the reason for revoking the certificate, and click Yes.

  5. In the Certification Authority snap-in, publish a new certificate revocation list (CRL) by clicking Certification Authority (Computer)\CA name\Revoked Certificates in the console tree. Then, on the Action menu, point to All Tasks, and then click Publish.

  6. On the client computer, use the Certificates snap-in to export one of the issued certificates and save it as an X.509 file.

  7. Open a command prompt, and type the following command:

    certutil –url <exportedcert.cer>

  8. In the URL Retrieval Tool dialog box, select OCSP (from AIA), and then click Retrieve. After the CRL is retrieved, the status will display Verified.

Additional references

  • Setting Up Online Responder Services in a Network


Setting Up Certificate Enrollment Web Services

Use Server Manager to install and configure the certificate enrollment Web services, which include the Certificate Enrollment Web Service and the Certificate Enrollment Policy Web Service. See "Additional references" for installation and configuration procedures.

Installation requirements

Before installing the certificate enrollment Web services, ensure that your environment meets these requirements:

  • A host computer as a domain member running Windows Server 2008 R2.

  • An Active Directory forest with a Windows Server 2008 R2 schema. See Prepare a Windows 2000 or Windows Server 2003 Forest Schema for a Domain Controller That Runs Windows Server 2008 or Windows Server 2008 R2 (http://go.microsoft.com/fwlink/?LinkID=93242).

  • An enterprise certification authority (CA) running Windows Server 2008 R2, Windows Server 2008, or Windows Server 2003.

    • If the Certificate Enrollment Web Service is configured for client certificate authentication, the CA must be running Windows Server 2008 R2 or Windows Server 2008.

    • For enrollment across forests, the CA must be installed on a computer running Windows Server 2008 R2 Enterprise or Windows Server 2008 R2 Datacenter. See Configuring Certificate Enrollment Web Services for Enrollment Across Forest Boundaries.

  • Client computers running Windows 7 or Windows Server 2008 R2.

  • A Server Authentication certificate installed for HTTPS.

During installation of certificate enrollment Web services, the following server roles and features will be installed if they are not already installed:

  • Web Server (IIS)

  • Microsoft .NET Framework version 3.5

Installation options

The following installation options are available for the certificate enrollment Web services:

  • The Certificate Enrollment Web Service and the Certificate Enrollment Policy Web Service should be installed on different computers.

  • The CA can be installed on the same computer as the Certificate Enrollment Web Service or the Certificate Enrollment Policy Web Service.

  • The Certificate Enrollment Web Service or the Certificate Enrollment Policy Web Service can be installed on the same computer as these other Web-based AD CS role services:

    • CA Web Enrollment

    • Network Device Enrollment Service

    • Online Responder

  • The Certificate Enrollment Policy Web Service can be installed on multiple computers in an enterprise; however, only a single instance of this service can be installed on each computer.

  • Multiple instances of the Certificate Enrollment Web Service can be installed on a single computer in order to support multiple CAs.

  • The certificate enrollment Web services are not supported on the Server Core installation option of Windows Server 2008 R2.

Authentication options

The following authentication options are available for the certificate enrollment Web services:

  • Windows integrated authentication

  • User name and password

  • Client certificate

Additional references

  • Installing the Certificate Enrollment Web Service

  • Installing the Certificate Enrollment Policy Web Service

  • Configuring Server Certificates for Certificate Enrollment Web Services

  • Configuring Group Policy to Support the Certificate Enrollment Policy Web Service

  • Configuring Delegation Settings for the Certificate Enrollment Web Service Account

  • Configuring the Certificate Enrollment Web Service for Renewal Only Mode

  • Configuring Certificate Enrollment Web Services for Enrollment Across Forest Boundaries

  • Advanced Configuration Options for the Certificate Enrollment Web Services

  • Prepare a Windows 2000 or Windows Server 2003 Forest Schema for a Domain Controller That Runs Windows Server 2008 or Windows Server 2008 R2 (http://go.microsoft.com/fwlink/?LinkID=93242)


Installing the Certificate Enrollment Web Service

This topic provides step-by-step procedures to install the Certificate Enrollment Web Service.

Important

Before beginning installation, review the requirements and configuration options for this role service in Setting Up Certificate Enrollment Web Services.

Enterprise Admins is the minimum group membership required to complete this procedure.

To install the Certificate Enrollment Web Service

  1. Open Server Manager.

  2. In the console tree, click Roles.

  3. If Active Directory Certificate Services is displayed on the Roles Summary page, click Add Role Services, and continue to the next step. If it is not displayed, complete the following steps before continuing:

    1. On the Roles Summary page, click Add Roles.

    2. On the Before You Begin page, click Next.

    3. On the Select Server Roles page, click Active Directory Certificate Services, and then click Next.

    4. Review the information on the Introduction to Active Directory Certificate Services page, and then click Next.

  4. On the Select Role Services page, select the Certificate Enrollment Web Service check box.

    Note

    The Certification Authority role service is automatically selected when the AD CS role is added, but it cannot be installed at the same time as the Certificate Enrollment Web Service. If you intend to install both the CA and the Certificate Enrollment Web Service, complete the CA installation first. See Setting Up Active Directory Certificate Services.

  5. Click Add Required Role Services when prompted to install required role services and features, and then click Next.

  6. To specify a CA, click either CA name or Computer name, and then click Browse. Select a CA or type a computer name, and then click OK.

  7. Select the Configure the Certificate Enrollment Web Service for renewal-only mode check box if you want to configure the Web service to accept only certificate renewal requests and reject enrollment requests for new certificates. See Configuring the Certificate Enrollment Web Service for Renewal Only Mode.

  8. Select the authentication type that the Certificate Enrollment Web Service will use to authenticate client requests, and then click Next.

  9. On the Specify Account Credentials page, click either Specify service account or Use built-in application pool identity. To specify a service account, click Select, type a domain account user name and password, and click OK. Click Next.

  10. Select an existing server certificate, click Import to import a certificate file or click Choose and assign a server certificate later, and then click Next. See Configuring Server Certificates for Certificate Enrollment Web Services for details.

  11. On the Introduction to Web Server (IIS) page, click Next.

  12. On the Select Role Services page, review the selected role services, and then click Next.

  13. Review the information on the Confirm Installation Selections page, and then click Install.

  14. Review the Installation Results page for messages. Additional tasks may be required to configure the Certificate Enrollment Web Service before users can submit requests.

Additional references

  • Configuring Server Certificates for Certificate Enrollment Web Services

  • Configuring the Certificate Enrollment Web Service for Renewal Only Mode

  • Installing the Certificate Enrollment Policy Web Service

  • Setting Up Certificate Enrollment Web Services


Installing the Certificate Enrollment Policy Web Service

This topic provides step-by-step procedures to install the Certificate Enrollment Policy Web Service.

Important

Before beginning installation, review the requirements and configuration options for this role service in Setting Up Certificate Enrollment Web Services.

Enterprise Admins is the minimum group membership required to complete this procedure.

To install the Certificate Enrollment Policy Web Service

  1. Open Server Manager.

  2. In the console tree, click Roles.

  3. If Active Directory Certificate Services is displayed on the Roles Summary page, click Add Role Services, and continue to the next step. If it is not displayed, complete the following steps before continuing:

    1. On the Roles Summary page, click Add Roles.

    2. On the Before You Begin page, click Next.

    3. On the Select Server Roles page, click Active Directory Certificate Services, and then click Next.

    4. Review the information on the Introduction to Active Directory Certificate Services page, and then click Next.

  4. On the Select Role Services page, select the Certificate Enrollment Policy Web Service check box.

    Note

    The Certification Authority (CA) role service is automatically selected when the AD CS role is added, but it is not required. Clear the Certification Authority check box unless you intend to install both the CA and the Certificate Enrollment Policy Web Service. See Setting Up Active Directory Certificate Services.

  5. Click Add Required Role Services when prompted to install required role services and features, and then click Next.

  6. Select the authentication type that the Certificate Enrollment Policy Web Service will use to authenticate client requests, and then click Next.

  7. On the Specify Account Credentials page, select either Specify service account or Use built-in application pool identity. To specify a service account, click Select, type a domain user account and password and click OK. Click Next.

  8. Select an existing server certificate, click Import to import a certificate file or select Choose and assign a server certificate later, and then click Next. See Configuring Server Certificates for Certificate Enrollment Web Services for details.

  9. On the Introduction to Web Server (IIS) page, click Next.

  10. On the Select Role Services page, review the selected role services, and then click Next.

  11. Review the information on the Confirm Installation Selections page, and then click Install.

  12. Review the Installation Results page for messages. Additional tasks may be required to configure the Certificate Enrollment Policy Web Service before users can submit requests.

Additional references

  • Configuring Server Certificates for Certificate Enrollment Web Services

  • Configuring Group Policy to Support the Certificate Enrollment Policy Web Service

  • Installing the Certificate Enrollment Web Service

  • Setting Up Certificate Enrollment Web Services


Configuring Server Certificates for Certificate Enrollment Web Services

The certificate enrollment Web services require HTTPS connections. Follow this procedure to select a Server Authentication certificate and configure the HTTPS binding.

To configure the HTTPS binding

  1. Open Server Manager.

  2. In the console tree, expand Roles, and then expand Web Server (IIS).

  3. Click Internet Information Services (IIS) Manager.

  4. In the console tree under Connections, expand the Web server, expand Sites, and then click the Web site that hosts the Web service.

  5. In the Actions pane, click Bindings.

  6. In the Type list, click https, and then click Edit.

    Note

    If https is not in the list, click Add, click https, and then select the IP address and port of the site that hosts the Web service.

  7. In the SSL Certificate list, select a certificate.

    Note

    The specified certificate must include the Server Authentication purpose and have a subject name that matches the host name that client computers will use to access the Web service. To request a Server Authentication certificate, see Request Certificates by Using the Certificate Request Wizard (http://go.microsoft.com/fwlink/?LinkId=143456).

  8. Click OK to save the binding.

Additional references

  • Checklist: Authenticate Web Servers with Certificates Issued by a Windows-Based CA

  • Setting Up Certificate Enrollment Web Services

  • Installing the Certificate Enrollment Web Service

  • Installing the Certificate Enrollment Policy Web Service


Configuring Group Policy to Support the Certificate Enrollment Policy Web Service

Before client computers can use the Certificate Enrollment Policy Web Service, a Group Policy setting must be configured to provide the location of Web service to domain members.

To configure certificate enrollment policy

  1. On the Web server that hosts the Certificate Enrollment Policy Web Service, open Server Manager.

  2. In the console tree, expand Roles, and then expand Web Server (IIS).

  3. Click Internet Information Services (IIS) Manager.

  4. In the console tree, expand Sites, and click the Web service application that begins with ADPolicyProvider_CEP.

    Note

    The name of the application is ADPolicyProvider_CEP_AuthenticationType where AuthenticationType is the authentication type of the Web service.

  5. Under ASP.NET, double-click Application Settings.

  6. Double-click URI, and copy the URI value.

  7. Click Start, type gpmc.msc in the Search programs and files box, and press ENTER.

  8. In the console tree, expand the forest and domain that contain the policy that you want to edit, and click Group Policy Objects.

  9. Right-click the policy that you want to edit, and then click Edit.

  10. In the console tree under Computer Configuration\Policies\Windows Settings\Security Settings, click Public Key Policies.

  11. Double-click Certificate Services Client – Certificate Enrollment Policy.

  12. Click Add to open the Certificate Enrollment Policy Server dialog box.

  13. In the Enter enrollment policy server URI box, type or paste the certificate enrollment policy server URI obtained earlier.

  14. In the Authentication type list, select the authentication type required by the enrollment policy server.

  15. Click Validate, and review the messages in the Certificate enrollment policy server properties area. The Add button is available only when the enrollment policy server URI and authentication type are valid.

  16. Click Add.

Additional references

  • Setting Up Certificate Enrollment Web Services


Configuring Delegation Settings for the Certificate Enrollment Web Service Account

Depending on the installation options you selected for the Certificate Enrollment Web Service, you may also need to configure delegation for the Web service to submit certificate requests on behalf of domain users and computers.

If all of the following conditions are true, then you must configure delegation for the Web service account:

  • The certification authority (CA) and the Certificate Enrollment Web Service are installed on separate computers.

  • The Web service authentication type is Windows integrated authentication or client certificate authentication.

  • The Web service is not configured for renewal-only mode.

Domain Admins is the minimum group membership required to complete this procedure.

The Certificate Enrollment Web Service application pool can be configured to use a domain user account or a built-in account such as ApplicationPoolIdentity or Network Service. If a domain user account is specified, then complete the first step to add a service principal name (SPN) to the account object before configuring delegation.

To configure delegation

  1. (Domain user accounts only) To add an SPN for a domain user account, at a command prompt, type setspn –s http/Host Domain\Account, where Host is the computer name of the Web server hosting the Certificate Enrollment Web Service and Domain\Account is the domain account used by the Web service application pool.

  2. Open Active Directory Users and Computers.

  3. In the console tree, expand the domain that contains the account used by the application pool.

  4. If the application pool identity is Network Service, click Computers. Otherwise, click Users.

  5. In the details pane, double-click the account, and then click the Delegation tab.

  6. Click Trust this user for delegation to specified services only.

  7. If the Web service authentication type is Windows integrated authentication, select the Use Kerberos only check box. If the Web service authentication type is client certificate authentication, select the Use any authentication protocol check box.

  8. Click Add, and then click Users or Computers.

  9. Enter the name of the computer that hosts the CA, and then click OK.

  10. In the Available Services list, click HOST and rpcss, and then click OK. Hold down the CTRL key to select multiple items.

  11. Click OK to save the changes.

Additional references

  • Setspn command reference (http://go.microsoft.com/fwlink/?LinkId=143939)

  • Installing the Certificate Enrollment Web Service

  • Setting Up Certificate Enrollment Web Services


Configuring the Certificate Enrollment Web Service for Renewal Only Mode

The Certificate Enrollment Web Service can process enrollment requests for new certificates and for certificate renewal. In both cases, the client computer submits the request to the Web service and the Web service submits the request to the certification authority (CA) on behalf of the client computer. For this reason, the Web service account must be trusted for delegation in order to present the client identity to the CA.

The Certificate Enrollment Web Service accepting requests from the Internet presents an increased security risk, and some organizations may choose not to trust the Web service account for delegation. The Certificate Enrollment Web Service can be configured for renewal-only mode to mitigate the risk of accepting requests from the Internet.

In renewal-only mode, the Web service will accept only certificate renewal requests, and requests for new certificates will be rejected. To support renewal-only mode, the CA must be configured to authenticate the client computer by using the signature on the renewal request and the client computer's existing certificate. In this configuration, there is no requirement to trust the Web service account for delegation.

Renewal-only mode has these requirements:

  • Enterprise CA running Windows Server 2008 R2.

  • Client computers running Windows 7 or Windows Server 2008 R2.

  • Client computers requesting certificate renewal must have a certificate that is not expired and can be verified by the issuing CA.

Enterprise Admins is the minimum group membership required to complete this procedure.

To configure the Certificate Enrollment Web Service for renewal-only mode

  1. Open Server Manager.

  2. In the console tree, click Roles.

  3. If Active Directory Certificate Services is displayed on the Roles Summary page, click Add Role Services, and continue to the next step. If it is not displayed, complete the following steps before continuing:

    1. On the Roles Summary page, click Add Roles.

    2. On the Before You Begin page, click Next.

    3. On the Select Server Roles page, click Active Directory Certificate Services, and then click Next.

    4. Review the information on the Introduction to Active Directory Certificate Services page, and then click Next.

  4. On the Select Role Services page, select the Certificate Enrollment Web Service check box.

    Note

    The Certification Authority role service is automatically selected when the AD CS role is added, but it cannot be installed at the same time as the Certificate Enrollment Web Service. If you intend to install both the CA and the Certificate Enrollment Web Service, complete the CA installation first. See Setting Up Active Directory Certificate Services.

  5. Click Add Required Role Services when prompted to install required role services and features, and then click Next.

  6. To specify a CA, click either CA name or Computer name, and then click Browse. Select a CA or type a computer name, and then click OK.

  7. Select the Configure the Certificate Enrollment Web Service for renewal-only mode check box.

  8. On the Select Authentication Type page, click Username and password or Client certificate authentication.

  9. On the Specify Account Credentials page, click either Specify service account or Use built-in application pool identity. To specify a service account, click Select, type a domain account user name and password, and click OK. Click Next.

  10. Select an existing server certificate, click Import to import a certificate file or click Choose and assign a server certificate later, and then click Next. See Configuring Server Certificates for Certificate Enrollment Web Services for details.

  11. On the Introduction to Web Server (IIS) page, click Next.

  12. On the Select Role Services page, review the selected role services, and then click Next.

  13. Review the information on the Confirm Installation Selections page, and then click Install.

  14. Review the Installation Results page for messages. Additional tasks may be required to configure the Certificate Enrollment Web Service before users can submit requests.

Use these commands to configure and restart Active Directory Certificate Services. In this configuration, the CA can also process requests for new certificates.

To configure the CA to support renewal-only mode

  1. On the CA at a command prompt, type certutil –setreg policy\editflags +enablerenewonbehalfof, and press ENTER.

  2. Open the Certification Authority snap-in.

  3. In the console tree, right-click the CA, and then click Properties.

  4. Click the Security tab.

  5. If the Web service account is displayed in Group or user names, verify that the Read permission is selected. If the Web service account is not displayed, complete the following steps:

    1. Click Add.

    2. Type the account name, and click Check Names. If the name is not found, click Object Types, and ensure that the correct account type is selected. Click OK after the correct account name is found.

    3. Select the Read check box, and then click OK.

  6. Type sc stop certsvc, and press ENTER.

  7. Type sc start certsvc, and press ENTER.

Additional references

  • Installing the Certificate Enrollment Web Service

  • Setting Up Certificate Enrollment Web Services


Configuring Certificate Enrollment Web Services for Enrollment Across Forest Boundaries

The certificate enrollment Web services can be deployed in multiple-forest environments to enable policy-based certificate enrollment across forest boundaries. In previous versions of Active Directory Certificate Services (AD CS), policy-based certificate enrollment can be completed only by domain member client computers that are using the DCOM protocol. This limits certificate enrollment to the trust boundaries established by Active Directory forests and results in the deployment of per-forest PKI.

Organizations with multiple forests and per-forest PKI deployments can benefit from certification authority (CA) consolidation by deploying the certificate enrollment Web services to enable enrollment across forest boundaries. Guidance for the design and deployment of this type of scenario is available at http://go.microsoft.com/fwlink/?LinkId=143457.

Additional references

  • Setting Up Certificate Enrollment Web Services

  • Certificate Enrollment Web Service Overview

  • Certificate Enrollment Policy Web Service Overview


Advanced Configuration Options for the Certificate Enrollment Web Services

Advanced configuration options for certificate enrollment Web services include:

  • Deploy multiple instances of the Certificate Enrollment Web Service on one computer.

  • View and configure settings for certificate enrollment Web services.

  • Enabling logging and tracing for troubleshooting.

For more information about these and other advanced configuration and deployment options, see http://go.microsoft.com/fwlink/?LinkId=143458.

Additional references

  • Setting Up Certificate Enrollment Web Services


Managing a Certification Authority

Management of a certification authority (CA) involves two broad categories of tasks: infrequent tasks, which include key configuration tasks and implementing a management framework, and recurring tasks, which include the common daily operations of a CA, such as issuing and revoking certificates and publishing revocation data.

  • Install and Use the Certification Authority Snap-In

  • Infrequent Management Tasks

  • Recurring Management Tasks


Install and Use the Certification Authority Snap-In

The Certification Authority snap-in can be used to administer a certification authority (CA) on this computer or on another computer. The snap-in is installed automatically on a computer that has a CA installed. Otherwise, you must first install the Active Directory Certificate Services (AD CS) Remote Server Administration Tools.

You must be a CA administrator to complete this procedure. For more information, see Implement Role-Based Administration.

To administer a CA on this computer

  1. If this is the first time you are using the Certification Authority snap-in on this computer, click Start, click Run, type mmc, and then press ENTER.

  2. On the File menu, click Add/Remove Snap-in.

  3. Add the Certification Authority snap-in to the list on the right.

  4. Select the computer hosting the CA that you want to administer, and then click OK.

You can also use an existing instance of the Certification Authority snap-in to switch from administering one CA to administering another CA.

You must be a CA administrator on the remote CA to complete this procedure. For more information, see Implement Role-Based Administration.

To administer a CA on another computer

  1. Open the Certification Authority snap-in.

  2. On the Action menu, click Retarget Certification Authority.

  3. Click Another computer, and type the name of the computer.

You can also customize the Certification Authority snap-in by using display filters. With filters, you can restrict the items displayed in the details pane of the Certification Authority snap-in to items that meet a set of criteria you establish. For example, you can create a filter that will display in the Issued Certificates folder only those certificates that were effective after a specific date.

You do not need to be a CA administrator, but you must have permissions to perform administration tasks on the CA to complete this procedure. For more information, see Implement Role-Based Administration.

To set display filters for the Certification Authority snap-in

  1. Open the Certification Authority snap-in.

  2. Click any of the displayed folders except Certificate templates.

  3. On the View menu, click Filter.

  4. For each of the selection criteria:

    • Click Add.

    • In Field, click the field on which to filter.

    • In Operation, click the operation to qualify the filter value for this field.

    • In Value, type the qualification value.

  5. To remove a filter, select it in the Filter dialog box, and then click Remove.

  6. To remove all existing filters, in the Filter dialog box, click Reset.

The Remote Server Administration Tools can be installed on a computer running Windows Server 2008 R2 or Windows Server 2008 by using the Add Features Wizard.

You must be an administrator on the server to complete this procedure. For more information, see Implement Role-Based Administration.

To install the AD CS Remote Server Administration Tools

  1. Open Server Manager.

  2. Under Features Summary, click Add Features to start the Add Features Wizard.

  3. On the Select Features page, click the plus sign to the left of the Remote Server Administration Tools check box, and then click the plus sign to the left of the Role Administration Tools check box.

  4. Select the Active Directory Certificate Services check box, click Next, and then click Install.

  5. When installation is complete, click Close.

To perform remote administration tasks from a computer running Windows Vista, you can obtain the Remote Server Administration Tools Pack from the Microsoft Download Center (http://go.microsoft.com/fwlink/?LinkId=89361).

Additional references

  • Managing a Certification Authority


Infrequent Management Tasks

The following management tasks need to be performed when a certification authority (CA) is initially deployed or when significant changes are needed.

  • Securing Active Directory Certificate Services

  • Configuring Certificate Revocation

  • Deploying Certificate Templates (http://go.microsoft.com/fwlink/?LinkId=142228)

  • Managing Key Archival and Recovery

  • Managing Policy and Exit Modules

  • Protecting a CA from Data Loss


Securing Active Directory Certificate Services

It is important to define and implement an Active Directory Certificate Services (AD CS) management model when you develop a certification authority (CA) infrastructure. This management model should complement your existing security management delegation plan and, if necessary, can help you meet Common Criteria requirements for role separation.

To ensure that a single individual cannot compromise public key infrastructure (PKI) services, it is best to distribute management roles across different individuals in your organization.

To understand the roles and activities associated with managing AD CS, see Implement Role-Based Administration.

For additional important security and management role-related tasks, see:

  • Restrict Certificate Managers

  • Establish Restricted Enrollment Agents

  • Configure CA Event Auditing

  • Send E-mail When a Certification Event Occurs


Implement Role-Based Administration

You can use role-based administration to organize certification authority (CA) administrators into separate, predefined CA roles, each with its own set of tasks. Roles are assigned by using each user's security settings. You assign a role to a user by assigning that user the specific security settings that are associated with the role. A user that has one type of permission, such as Manage CA permission, can perform specific CA tasks that a user with another type of permission, such as Issue and Manage Certificates permission, cannot perform.

The following table describes the roles, users, and groups that can be used to implement role-based administration. To assign a role to a user or group, you must assign the role's corresponding security permissions, group memberships, or user rights to the user or group. These security permissions, group memberships, and user rights are used to distinguish which users have which roles.

Roles and groups | Security permission | Description
CA administrator | Manage CA | Configure and maintain the CA. This is a CA role and includes the ability to assign all other CA roles and renew the CA certificate. These permissions are assigned by using the Certification Authority snap-in.
Certificate manager | Issue and Manage Certificates | Approve certificate enrollment and revocation requests. This is a CA role. This role is sometimes referred to as CA officer. These permissions are assigned by using the Certification Authority snap-in.
Backup operator | Back up file and directories Restore file and directories | Perform system backup and recovery. Backup is an operating system feature.
Auditor | Manage auditing and security log | Configure, view, and maintain audit logs. Auditing is an operating system feature. Auditor is an operating system role.
Enrollees | Read Enroll | Enrollees are clients who are authorized to request certificates from a CA. This is not a CA role.

All CA roles are assigned and modified by members of local Administrators, Enterprise Admins, or Domain Admins. On enterprise CAs, local administrators, enterprise administrators, and domain administrators are CA administrators by default. Only local administrators are CA administrators by default on a stand-alone CA. If a stand-alone CA is installed on a server that is joined to an Active Directory domain, domain administrators are also CA administrators.

The CA administrator and certificate manager roles can be assigned to Active Directory users or local users in the Security Accounts Manager (SAM) of the local computer, which is the local security account database. As a best practice, you should assign roles to group accounts instead of individual user accounts.

Only CA administrator, certificate manager, auditor, and backup operator are CA roles. The other users described in the table are relevant to role-based administration and should be understood before assigning CA roles.

Only CA administrators and certificate managers are assigned by using the Certification Authority snap-in. To change the permissions of a user or group, you must change the user's security permissions, group membership, or user rights.

To set CA administrator and certificate manager security permissions for a CA

  1. Open the Certification Authority snap-in.

  2. In the console tree, click the name of the CA.

  3. On the Action menu, click Properties.

  4. Click the Security tab, and specify the security permissions.

Roles and activities

Each CA role has a specific list of CA administration tasks associated with it. The following table lists all the CA administration tasks along with the roles in which they are performed.

Activity | CA administrator | Certificate manager | Auditor | Backup operator | Local administrator | Notes
Install CAs |  |  |  |  | X |
Configure policy and exit modules | X |  |  |  |  |
Stop and start the Active Directory Certificate Services (AD CS) service | X |  |  |  |  |
Configure extensions | X |  |  |  |  |
Configure roles | X |  |  |  |  |
Renew CA keys |  |  |  |  | X |
Define key recovery agents | X |  |  |  |  |
Configure certificate manager restrictions | X |  |  |  |  |
Delete a single row in the CA database | X |  |  |  |  |
Delete multiple rows in the CA database (bulk deletion) | X | X |  |  |  | The user must be both a CA administrator and a certificate manager. This activity cannot be performed when role separation is enforced.
Enable role separation |  |  |  |  | X |
Issue and approve certificates |  | X |  |  |  |
Deny certificates |  | X |  |  |  |
Revoke certificates |  | X |  |  |  |
Reactivate certificates that are placed on hold |  | X |  |  |  |
Renew certificates |  | X |  |  |  |
Enable, publish, or configure certificate revocation list (CRL) schedules | X |  |  |  |  |
Recover archived keys |  | X |  |  |  | Only a certificate manager can retrieve the encrypted key data structure from the CA database. The private key of a valid key recovery agent is required to decrypt the key data structure and generate a PKCS #12 file.
Configure audit parameters |  |  | X |  |  | By default, the local administrator holds the system audit user right.
Audit logs |  |  | X |  |  | By default, the local administrator holds the system audit user right.
Back up the system |  |  |  | X |  | By default, the local administrator holds the system backup user right.
Restore the system |  |  |  | X |  | By default, the local administrator holds the system backup user right.
Read the CA database | X | X | X | X |  | By default, the local administrator holds the system audit and system backup user rights.
Read CA configuration information | X | X | X | X |  | By default, the local administrator holds the system audit and system backup user rights.

Additional considerations

  • Enrollees are allowed to read CA properties and CRLs, and they can request certificates. On an enterprise CA, a user must have Read and Enroll permissions on the certificate template to request a certificate. CA administrators, certificate managers, auditors, and backup operators have implicit Read permissions.

  • An auditor holds the system audit user right.

  • A backup operator holds the system backup user right. In addition, the backup operator has the ability to start and stop the Active Directory Certificate Services (AD CS) service.

Assigning roles

The CA administrator for a CA assigns users to the separate roles of role-based administration by applying the security settings required by a role to the user's account. The CA administrator can assign a user to more than one role, but the CA is more secure when each user is assigned to only one role. When this delegation strategy is used, fewer CA tasks can be compromised if a user's account becomes compromised.

Administrator concerns

The default installation setting for a stand-alone CA is to have members of the local Administrators group as CA administrators. The default installation setting for an enterprise CA is to have members of the local Administrators, Enterprise Admins, and Domain Admins groups as CA administrators. To limit the power of any of these accounts, they should be removed from the CA administrator and certificate manager roles when all CA roles are assigned.

As a best practice, group accounts that have been assigned CA administrator or certificate manager roles should not be members of the local Administrators group. Also, CA roles should only be assigned to group accounts and not individual user accounts.

Note

Membership in the local Administrators group on the CA is required to renew a CA certificate. Members of this group can assume administrative authority over all other CA roles.


Restrict Certificate Managers

A certificate manager can approve certificate enrollment and revocation requests, issue certificates, and manage certificates. This role can be configured by assigning a user or group the Issue and Manage Certificates permission.

When you assign this permission to a user or group, you can further refine their ability to manage certificates by group and by certificate template. For example, you might want to implement a restriction that they can only approve requests or revoke smart card logon certificates for users in a certain office or organizational unit that is the basis for a security group.

This restriction is based on a subset of the certificate templates enabled for the certification authority (CA) and the user groups that have Enroll permissions for that certificate template from that CA.

You must be a CA administrator or a member of Enterprise Admins, or equivalent, to complete this procedure. For more information, see Implement Role-Based Administration.

To configure certificate manager restrictions for a CA

  1. Open the Certification Authority snap-in, and right-click the name of the CA.

  2. Click Properties, and then click the Security tab.

  3. Verify that the user or group that you have selected has Issue and Manage Certificates permission. If they do not yet have this permission, select the Allow check box, and then click Apply.

  4. Click the Certificate Managers tab.

  5. Click Restrict certificate managers, and verify that the name of the group or user is displayed.

  6. Under Certificate Templates, click Add, select the template for the certificates that you want this user or group to manage, and then click OK. Repeat this step until you have selected all certificate templates that you want to allow this certificate manager to manage.

  7. Under Permissions, click Add, type the name of the client for whom you want the certificate manager to manage the defined certificate types, and then click OK.

  8. If you want to block the certificate manager from managing certificates for a specific user, computer, or group, under Permissions, select this user, computer, or group, and click Deny.

  9. When you are finished configuring certificate manager restrictions, click OK or Apply.

Additional references

  • Securing Active Directory Certificate Services


Establish Restricted Enrollment Agents

An enrollment agent is a user who can 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.

Windows Server 2008 R2 includes three certificate templates that enable different types of enrollment agents:

  • Enrollment Agent. Used to request certificates on behalf of another subject.

  • Enrollment Agent (Computer). Used to request certificates on behalf of another computer subject.

  • Exchange Enrollment Agent (Offline Request). Used to request certificates on behalf of another subject and supply the subject name in the request. This template is used by the Network Device Enrollment Service for its enrollment agent certificate.

When you create an enrollment agent, you can further refine the agent's ability to enroll for certificates on behalf of others by group and by certificate template. For example, you might want to implement a restriction that the enrollment agent can only enroll for smart card logon certificates for users in a certain office or organizational unit that is the basis for a security group.

This restriction is based on a subset of the certificate templates enabled for the certification authority (CA) and the user groups that have Enroll permissions for that certificate template from that CA.

Important

You can only apply enrollment agent restrictions on Windows Server 2008–based CAs. Enrollment agent policy must also be configured properly.

You must be a CA administrator or a member of Enterprise Admins, or equivalent, to complete this procedure. For more information, see Implement Role-Based Administration.

To configure enrollment agent restrictions for a CA

  1. Open the Certification Authority snap-in, right-click the name of the CA, and then click Properties.

  2. Click the Enrollment Agents tab, click Restrict enrollment agents, and click OK on the message that appears.

  3. Under Enrollment agents, click Add, type the names of the users or groups that you want to configure, and then click OK. Click Everyone, and then click Remove.

  4. Under Certificate Templates, click Add, select the template for the certificates that you want this user or group to be able to enroll from, and then click OK. Repeat this step until you have selected all certificate templates that you want to enable for this enrollment agent. When you have finished adding the names of certificate templates, click <All>, and then click Remove.

  5. Under Permissions, click Add, type the names of the users or groups for whom you want the enrollment agent to manage the defined certificate types, and then click OK. Click Everyone, and then click Remove.

  6. If you want to block the enrollment agent from managing certificates for a user, computer, or group, under Permissions, select this user, computer, or group, and then click Deny.

  7. When you are finished configuring enrollment agent restrictions, click OK or Apply.
Note

The user or group that you applied enrollment agent restrictions to must have a valid enrollment agent certificate for the CA before they can act as an enrollment agent, whether restricted enrollment agent permissions have or have not been configured.

Additional references

  • Securing Active Directory Certificate Services


Configure CA Event Auditing

You can audit a variety of events relating to the management and activities of a certification authority (CA):

  • Back up and restore the CA database.

  • Change the CA configuration.

  • Change CA security settings.

  • Issue and manage certificate requests.

  • Revoke certificates and publish certificate revocation lists (CRLs).

  • Store and retrieve archived keys.

  • Start and stop Active Directory Certificate Services (AD CS).

You must be a CA administrator or a CA auditor to complete this procedure. The CA auditor must perform this procedure if the CA has been configured to enforce role-based administration. For more information, see Implement Role-Based Administration.

To configure CA event auditing

  1. Open the Certification Authority snap-in.

  2. In the console tree, click the name of the CA.

  3. On the Action menu, click Properties.

  4. On the Auditing tab, click the events that you want to audit, and then click OK.

  5. On the Action menu, point to All Tasks, and then click Stop Service.

  6. On the Action menu, point to All Tasks, and then click Start Service.

Additional considerations

  • To audit events, the computer must also be configured for auditing of object access. Audit policy options can be viewed and managed in local or domain Group Policy under Computer Configuration\Windows Settings\Security Settings\Local Policies.

Additional references

  • Securing Active Directory Certificate Services

  • Protecting a CA from Data Loss


Send E-mail When a Certification Event Occurs

The following procedure configures a certification authority (CA) to send e-mail when a certification event occurs.

Membership in Domain Admins or local Administrators, or equivalent, is the minimum required to complete this procedure. For more information, see Implement Role-Based Administration.

To send e-mail when a certification event occurs

  • At an elevated command prompt, type:

    certutil -setreg exit\smtp\<smtpserverServerName>

    certutil -setreg exit\smtp\<eventfilter +Event>
Caution

Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up data on your computer.

The following tables explain the command values and options available for this procedure.

Value | Description
certutil | The name of the command-line tool.
-setreg | Modifies the registry.
exit\smtp\smtpserver | The registry value that contains the name of the Simple Mail Transfer Protocol (SMTP) server.
exit\smtp\eventfilter | The registry value that contains the list of events that the CA should monitor. When any of these events occur, the CA will send e-mail.
+ | Indicates that, if there are current entries stored in this registry value, this entry should be appended to them.
Event | Specifies the event to add to the list of events for the CA to monitor. An event can be any value in the following table.

Event value | Description
ExitEvent_CertIssued | Specifies the action of issuing a certificate.
ExitEvent_CertPending | Specifies the action of a certificate request being received by the CA and set to pending.
ExitEvent_CertDenied | Specifies the action of a certificate request being received by the CA and that request being denied.
ExitEvent_CertRevoked | Specifies the action of a revocation of an existing certificate.
ExitEvent_CRLIssued | Specifies the action of a certificate revocation list (CRL) being issued.
ExitEvent_Startup | Specifies the action of the CA during startup.
ExitEvent_Shutdown | Specifies the action of the CA during shutdown.

Additional considerations

  • To open a command prompt, click Start, point to All Programs, click Accessories, and then click Command Prompt.

  • When the ExitEvent_CRLIssued, ExitEvent_Startup, and ExitEvent_Shutdown events occur, the CA does not contain an e-mail address because there is no user associated with this event. Therefore, an e-mail address must be configured when using these events. To configure the e-mail address to send e-mail when these events occur, type the following certutil commands at a command prompt:

    certutil -setreg exit\smtp\CRLIssued\To<E-mailString>
certutil -setreg exit\smtp\Startup\To<E-mailString>
certutil -setreg exit\smtp\Shutdown\To<E-mailString>
    E-mailString specifies an e-mail address or a string of e-mail addresses that are separated by semicolons.

  • If the SMTP server is not set to accept anonymous connections, the CA must be configured to provide a user name and password when it connects. To configure the CA to authenticate with the SMTP server, type the following certutil commands at a command prompt:

    certutil -setreg exit\smtp\SMTPAuthenticate 1
certutil -setsmtpinfo<UserName>
    UserName specifies the user name of a valid account on the SMTP server. You will be prompted to provide the password for this user name.

  • To view the complete syntax for this command, at a command prompt, type:

    certutil -setreg -?
  • For more information about the certutil command-line tool, see the certutil command reference (http://go.microsoft.com/fwlink/?LinkId=81249).

Additional references

  • Securing Active Directory Certificate Services


Configuring Certificate Revocation

Every certificate is issued with a specific validity period. Revoking a certificate invalidates it as a trusted security credential before its original validity period expires. There are a number of reasons why a certificate can become untrustworthy as a security credential before its scheduled expiration. Examples include:

  • Compromise, or suspected compromise, of the certificate subject's private key.

  • Compromise, or suspected compromise, of a certification authority's (CA) private key.

  • Discovery that a certificate was obtained fraudulently.

  • Change in the status of the certificate subject as a trusted entity.

  • Change in the name of the certificate subject.

It is not always possible to contact a CA or other trusted server for information about the validity of a certificate. To effectively support certificate status checking, a client must be able to access revocation data to determine whether the certificate is valid or has been revoked. To support a variety of scenarios, Active Directory Certificate Services (AD CS) supports industry-standard methods of certificate revocation. These include publication of certificate revocation lists (CRLs) and delta CRLs, which can be made available to clients from a variety of locations, including Active Directory Domain Services (AD DS), Web servers, and network file shares.

Note

In Windows Server 2008 R2 and Windows Server 2008, an Online Responder can be used to make CRL data more readily accessible in complex network environments. An Online Responder uses the certificate revocation data from CRLs and processes certificate status requests from clients individually.

CRLs are complete, digitally signed lists of certificates that have been revoked. These lists are published periodically and can be retrieved and cached by clients (based on the configured lifetime of the CRL) and used to verify a certificate's revocation status.

Because CRLs can become large, depending on the number of certificates issued and revoked by a CA, you can also publish smaller, interim CRLs called delta CRLs. Delta CRLs contain only the certificates revoked since the last regular CRL was published. This allows clients to retrieve the smaller delta CRL and more quickly build a complete list of revoked certificates. The use of delta CRLs also allows revocation data to be published more frequently because the size of the delta CRL usually does not require as much time to transfer as a full CRL.

Additional references

  • Specify CRL Distribution Points

  • Configure CRL and Delta CRL Overlap Periods

  • Schedule Publication of Certificate Revocation Lists

  • Manage Certificate Revocation

  • Setting Up Online Responder Services in a Network


Specify CRL Distribution Points

You can add, remove, or modify certificate revocation list (CRL) distribution points in issued certificates by using the following procedure. However, modifying the URL for a CRL distribution point only affects newly issued certificates. Previously issued certificates will continue to reference the original location.

You must be a certification authority (CA) administrator to complete this procedure. For more information, see Implement Role-Based Administration.

To specify CRL distribution points in issued certificates

  1. Open the Certification Authority snap-in.

  2. In the console tree, click the name of the CA.

  3. On the Action menu, click Properties, and then click the Extensions tab. Confirm that Select extension is set to CRL Distribution Point (CDP).

  4. Do one or more of the following. (The list of CRL distribution points is in the Specify locations from which users can obtain a certificate revocation list (CRL) box.)

    To add a new CRL distribution point

    Click Add, type the name of the new CRL distribution point, and then click OK.

    To remove a CRL distribution point from the list

    Click the CRL distribution point, click Remove, and then click OK.

    To indicate that you want to use a URL as a CRL distribution point

    Click the CRL distribution point, select the Include in the CDP extension of issued certificates check box, and then click OK.

    To indicate that you do not want to use a URL as a CRL distribution point

    Click the CRL distribution point, clear the Include in the CDP extension of issued certificates check box, and then click OK.

    To indicate that you want to use a URL as a delta CRL distribution point

    Click the CRL distribution point, select the Publish Delta CRLs to this location check box, and then click OK.

    To indicate that you do not want to use a URL as a delta CRL distribution point

    Click the CRL distribution point, clear the Publish Delta CRLs to this location check box, and then click OK.

    To indicate that you want to publish this location in CRLs to point clients to a delta CRL

    Click the CRL distribution point, select the Include in CRLs. Clients use this to find Delta CRL locations check box, and then click OK.

    To indicate that you do not want to publish this location in CRLs to point clients to a delta CRL

    Click the CRL distribution point, clear the Include in CRLs. Clients use this to find Delta CRL locations check box, and then click OK.

  5. Click Yes to stop and restart Active Directory Certificate Services (AD CS).

CRL URLs can be HTTP, FTP, LDAP, or FILE addresses. You can use the following variables when specifying the address of the CRL.

Variable | Value
CAName | The name of the CA
CAObjectClass | The object class identifier for a CA, used when publishing to an LDAP URL
CATruncatedName | The "sanitized" name of the CA, truncated to 32 characters with a hash at the end
CDPObjectClass | The object class identifier for CRL distribution points, used when publishing to an LDAP URL
CertificateName | The renewal extension of the CA
ConfigurationContainer | The location of the Configuration container in Active Directory Domain Services (AD DS)
CRLNameSuffix | Inserts a name suffix at the end of the file name when publishing a CRL to a file or URL location
DeltaCRLAllowed | When a delta CRL is published, this replaces the CRLNameSuffix variable with a separate suffix to distinguish the delta CRL from the CRL
ServerDNSName | The DNS name of the CA server
ServerShortName | The NetBIOS name of the CA server

Additional references

  • Configuring Certificate Revocation

  • Manage Certificate Revocation


Configure CRL and Delta CRL Overlap Periods

You can adjust the relationship between a certificate revocation list (CRL) and delta CRL by configuring an overlap period between the two. This setting is particularly useful when publication of the next base or delta CRL is delayed or the client is unable to obtain a new CRL or delta CRL at the scheduled publication time.

The overlap period for CRLs is the amount of time at the end of a published CRL's lifetime that a client can use to obtain a new CRL before the old CRL is considered unusable. The default setting for this value is 10 percent of the CRL's lifetime. Because some environments may require longer periods to replicate a CRL, this setting can be configured manually.

Note

The maximum value for either the CRL or delta CRL overlap period is 12 hours.

When both a base CRL and delta CRL have been recently published, a revoked certificate may appear in both CRLs. This is because the newer delta CRL may still point to the older base CRL while the new base CRL is being replicated. Having the certificate appear in both CRLs ensures the revocation information is available.

You must be a certification authority (CA) administrator to complete this procedure. For more information, see Implement Role-Based Administration.

To configure a CRL and delta CRL overlap period

  1. At a command prompt, type:

    certutil -setreg ca\CRLOverlapUnits Value

    certutil -setreg ca\CRLOverlapPeriod Units

    certutil -setreg ca\CRLDeltaOverlapUnits Value

    certutil -setreg ca\DeltaOverlapPeriod Units

  2. Open the Certification Authority snap-in.

  3. In the console tree, click the name of the CA.

  4. On the Action menu, point to All Tasks, and click Stop Service to stop the service.

  5. On the Action menu, point to All Tasks, and click Start Service to start the service.
Caution

Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on your computer.

The following table lists the values that can be used in the Certutil syntax described in this procedure.

Value | Description
Certutil | Specifies the name of the command-line tool.
-setreg | Modifies the registry.
ca\CRLOverlapUnits | Indicates the registry value that stores the value for the CRL overlap setting.
ca\CRLDelataOverlapUnits | Indicates the registry value that stores the value for the delta CRL overlap setting.
Value | Provides the numerical value to set this option to.
ca\CRLOverlapPeriod | Indicates the registry value that stores the value for the CRL overlap unit type setting.
ca\DeltaOverlapPeriod | Indicates the registry value that stores the value for the delta CRL overlap unit type setting.
Units | Provides the type of units for the overlap period. Valid values are Minutes, Hours, and Days.
Note

If your environment is not configured to issue delta CRLs, the settings for CRLDeltaOverlapUnits and DeltaOverlapPeriod will have no effect.

Additional considerations

  • To open a command prompt, click Start, point to All Programs, click Accessories, and then click Command Prompt.

Additional references

  • Configuring Certificate Revocation

  • Schedule Publication of Certificate Revocation Lists


Schedule Publication of Certificate Revocation Lists

You must establish a regular publication schedule for certificate revocation data so that a highly accurate certificate revocation list (CRL) is always available to clients. When establishing this schedule, the need for accurate, up-to-date data must be balanced against the impact that frequent downloads of new CRLs can have on clients.

You must be a certification authority (CA) administrator to complete this procedure. For more information, see Implement Role-Based Administration.

To schedule the publication of the CRL

  1. Open the Certification Authority snap-in.

  2. In the console tree, click Revoked Certificates.

  3. On the Action menu, click Properties.

  4. In CRL publication interval, type the increment and click the unit of time to use for the automatic publishing of the CRL.

At the defined interval, a new CRL will be published by default in the following folder: systemroot\system32\CertSrv\CertEnroll\. If the computer is a domain member and has permission to write to Active Directory Domain Services (AD DS), then the CRL is also published to AD DS.

The publishing period for a CRL is not the same as the validity period for a CRL. By default, the validity period of a CRL exceeds the publishing period of a CRL by 10 percent (up to a 12-hour maximum) to allow for directory replication.

Scheduling publication of delta CRLs

You can extend your CRL publication schedule by also establishing a schedule for the publication of delta CRLs.

You must be a CA administrator to complete this procedure. For more information, see Implement Role-Based Administration.

To schedule the publication of the delta CRL

  1. Open the Certification Authority snap-in.

  2. In the console tree, click Revoked Certificates.

  3. On the Action menu, click Properties.

  4. Select the Publish Delta CRLs check box.

  5. In Publication interval, type the increment and click the unit of time to use for the automatic publishing of the delta CRL.

Additional references

  • Configuring Certificate Revocation

  • Configure CRL and Delta CRL Overlap Periods


Managing Key Archival and Recovery

When users lose their private keys, any information that was persistently encrypted with the corresponding public key is no longer accessible. Using key archival and recovery helps protect encrypted data from permanent loss if, for example, an operating system needs to be reinstalled, the user account to which the encryption key was originally issued is no longer available, or the key is otherwise no longer accessible. To help protect private keys, Microsoft enterprise certification authorities (CAs) can archive a user's keys in its database when certificates are issued. These keys are encrypted and stored by the CA.

This private key archive makes it possible for the key to be recovered at a later time. The key recovery process requires an administrator to retrieve the encrypted certificate and private key and then a key recovery agent to decrypt them. When a correctly signed key recovery request is received, the user's certificate and private key are provided to the requester. The requester would then use the key as appropriate or securely transfer the key to the user for continued use. As long as the private key is not compromised, the certificate does not have to be replaced or renewed with a different key.

Key archival and recovery are not enabled by default. This is because many organizations would consider the storage of the private key in multiple locations to be a security vulnerability. Requiring organizations to make explicit decisions about which certificates are covered by key archival and recovery and who can recover archived keys helps ensure that key archival and recovery are used to enhance security rather than detract from security.

You must be a CA administrator to complete this procedure. For more information, see Implement Role-Based Administration.

To configure your environment for key archival of Encrypting File System (EFS) certificates

  1. Create a key recovery agent account or designate an existing user to serve as the key recovery agent.

  2. Configure the key recovery agent certificate template and enroll the key recovery agent for a key recovery agent certificate. For information, see Identify a Key Recovery Agent.

  3. Register the new key recovery agent with the CA. For information, see Enable Key Archival for a CA.

  4. Configure a certificate template, such as Basic EFS, for key archival, and enroll users for the new certificate. If users already have EFS certificates, ensure that the new certificate will supersede the certificate that does not include key archival. For information, see Configure a Certificate Template for Key Archival.

  5. Enroll users for encryption certificates based on the new certificate template.

    Users are not protected by key archival until they have enrolled for a certificate that has key recovery enabled. If they have identical certificates that were issued before key recovery was enabled, data encrypted with these certificates is not covered by key archival.

For more information about key archival and recovery, see Key Archival and Recovery in Windows Server 2008 (http://go.microsoft.com/fwlink/?LinkID=92523).

Additional references

  • Recover a Lost Key


Identify a Key Recovery Agent

A key recovery agent is a person who is authorized to recover a certificate on behalf of an end user. Because the role of key recovery agents can involve sensitive data, only highly trusted individuals should be assigned to this role.

To identify a key recovery agent, you must configure the Key Recovery Agent certificate template to allow the person assigned to this role to enroll for a key recovery agent certificate.

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. For more information, see Implement Role-Based Administration.

To configure the Key Recovery Agent certificate template

  1. Open the Certificate Templates snap-in.

  2. In the console tree, right-click the Key Recovery Agent certificate template.

  3. Click Duplicate Template.

  4. In the Duplicate Template dialog box, click Windows Server 2003 Enterprise unless all of your certification authorities (CAs) and client computers are running Windows Server 2008 R2, Windows Server 2008, Windows 7, or Windows Vista.

  5. In Template, type a new template display name, and then modify any other optional properties as needed.

  6. On the Security tab, click Add, type the name of the users you want to issue the key recovery agent certificates to, and then click OK.

  7. Under Group or user names, select the user names that you just added. Under Permissions, select the Read and Enroll check boxes, and then click OK.

    Note

    To enhance security and control of the key recovery process, you should not use autoenrollment for key recovery agent certificates.

Before the new key recovery agent can enroll for a certificate based on the new certificate template that you created, the template must first be added to the CA. For information about how to complete this procedure, see Add a Certificate Template to a Certification Authority (http://go.microsoft.com/fwlink/?LinkId=147110).

If the certificate was configured with Read and Enroll permissions, the new key recovery agent must use the Certificates snap-in and the Certificate Import Wizard to obtain a key recovery certificate. If the certificate template was configured with Autoenroll permissions, the certificate will be issued automatically the next time the user logs on to the network.

Note

By default, the CA certificate manager approval check box is selected on the Issuance Requirements tab. Unless you clear this check box, a CA manager must approve the certificate request before a key recovery agent certificate is issued.

The next procedure, Enable Key Archival for a CA, cannot be completed until the key recovery agent has obtained this certificate.

Additional references

  • Managing Key Archival and Recovery


Enable Key Archival for a CA

Before a key recovery agent can use a key recovery certificate, the key recovery agent must have enrolled for the key recovery certificate and be registered as the recovery agent for the certification authority (CA).

You must be a CA administrator to complete this procedure. For more information, see Implement Role-Based Administration.

To enable key archival for a CA

  1. Open the Certification Authority snap-in.

  2. In the console tree, click the name of the CA.

  3. On the Action menu, click Properties.

  4. Click the Recovery Agents tab, and then click Archive the key.

  5. In Number of recovery agents to use, type the number of key recovery agents that will be used to encrypt the archived key.

    The Number of recovery agents to use must be between one and the number of key recovery agent certificates that have been configured.

  6. Click Add. Then, in Key Recovery Agent Selection, click the key recovery certificates that are displayed, and click OK.

  7. The certificates should appear in the Key recovery agent certificates list, but their status is listed as Not loaded.

  8. Click OK or Apply. When prompted to restart the CA, click Yes. When the CA has restarted, the status of the certificates should be listed as Valid.

The list of Key recovery agent certificates can include the status values and causes in the following table.

Status | Cause
Expired | The certificate's expiration date has passed, so the certificate cannot be used.
Invalid | The certificate may be malformed or causes an error when loading.
Not found | The certificate was configured but cannot be located by the CA.
Not loaded | The certificate was configured but has not yet been loaded by the CA.
Revoked | The certificate has been revoked and cannot be used.
Untrusted | The root CA for this certificate is not trusted by the CA.
Valid | The certificate has been loaded by the CA and is operating normally.

If the Number of recovery agents to use value exceeds the number of recovery agent certificates with the status of Valid, enrollment requests that require key archival will fail.

Additional references

  • Managing Key Archival and Recovery


Configure a Certificate Template for Key Archival

The key archival process takes place when a certificate is issued. Therefore, a certificate template must be modified to archive keys before any certificates are issued based on this template.

Key archival is strongly recommended for use with the Basic Encrypting File System (EFS) certificate template in order to protect users from data loss, but it can also be useful when applied to other types of certificates.

Membership in Domain Admins or Enterprise Admins, or equivalent, is the minimum required to complete this procedure. For more information, see Implement Role-Based Administration.

To configure a certificate template for key archival and recovery

  1. Open the Certificate Templates snap-in.

  2. In the details pane, right-click the certificate template that you want to change, and then click Duplicate Template.

  3. In the Duplicate Template dialog box, click Windows Server 2003 Enterprise unless all of your certification authorities (CAs) and client computers are running Windows Server 2008 R2, Windows Server 2008, Windows 7, or Windows Vista.

  4. In Template, type a new template display name, and then modify any other optional properties as needed.

  5. On the Security tab, click Add, type the name of the users or groups you want to issue the certificates to, and then click OK.

  6. Under Group or user names, select the user or group names that you just added. Under Permissions, select the Read and Enroll check boxes, and if you want to automatically issue the certificate, also select the Autoenroll check box.

    Note

    To implement autoenrollment, all three check boxes must be selected.

  7. On the Request Handling tab, select the Archive subject's encryption private key check box.

  8. If users already have EFS certificates that are not configured for key archival and recovery, click the Superseded Templates tab, click Add, and then click the name of the template that you want to replace.

  9. Click OK.

Users are not protected by key archival until they have enrolled for a certificate that has key recovery enabled. If they have identical certificates that were issued before key recovery was enabled, they are not covered by key archival. Clients must be re-enrolled to receive a certificate that is based on the changed template if they already have a valid certificate that is based on the old template. For more information about re-enrolling clients, see Re-Enroll All Certificate Holders (http://go.microsoft.com/fwlink/?LinkId=147103).

Additional references

  • Managing Key Archival and Recovery


Recover a Lost Key

Users who lose a private key will be unable to recover data that is encrypted with that key. By recovering a key and restoring it to the client computer, the data can be decrypted and used.

The complete recovery process includes three procedures:

  • Obtain the serial number of the archived certificate.

  • Perform the key recovery.

  • Restore the key to the client's computer.

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. For more information, see Implement Role-Based Administration.

To obtain the serial number of an archived certificate

  1. Log on to the computer hosting the certification authority (CA).

  2. Open the Certification Authority snap-in.

  3. In the console tree, click the CA name, and then click Issued Certificates.

  4. On the View menu, click Add/Remove Columns.

  5. Under Available Column, click Archived Key, and then click Add.

    Archived Key should now appear in Displayed Columns.

  6. Click OK, and then, in the details pane, scroll to the right and confirm that the last certificate issued to the user has a Yes value in the Archived Key column.

  7. Double-click the certificate.

  8. Click the Details tab. Record the serial number of the certificate. (Do not include spacing between digit pairs.) You will need this information to complete the recovery procedure.

    The serial number will be a hexadecimal string that is 20 characters long. The serial number of the private key is the same as the serial number of the certificate. For the purposes of this procedure, the serial number will be referred to as serialnumber.

  9. Click OK, and close the Certification Authority snap-in.

  10. At a command prompt, type:

    Certutil -getkey <serialnumber> outputblob
    Note

    The Recipient Info section in the output of this command identifies the serial numbers of the key recovery agent certificates whose private keys are needed to decrypt the blob and recover the key.

  11. At a command prompt, type:

    dir outputblob
    Note

    If the file outputblob does not exist, you might have typed the serial number incorrectly for the certificate. The outputblob file is a PKCS #7 file containing the key recovery agent certificates and the user certificate and chain. The inner content is an encrypted PKCS #7 file containing the private key (encrypted to the key recovery agent certificates).

The domain administrator must transfer the output file to the key recovery agent, who performs the actual recovery procedure.

You must be a user with a key recovery agent certificate registered with the CA to complete this procedure. The key recovery agent must be stored in the key recovery agent's Personal certificate store on the computer where the key recovery procedure will take place. For more information, see Implement Role-Based Administration.

To recover the archived certificate

  1. At a command prompt, type:

    Certutil -recoverkey outputblob <filename>.pfx

  2. When prompted, enter a new password. When requested, confirm the new password by typing it a second time.

  3. Copy the saved .pfx file to the computer where recovery is to be completed.

  4. Close all windows and log off the computer.

After the key has been recovered, it must be imported on the computer where the data is stored.

You must be the client to whom the certificate was issued or an administrator on the client computer to complete this procedure. For more information, see Implement Role-Based Administration.

To import the recovered key

  1. Open the Certificates snap-in for the user to whom the certificate was issued.

  2. In the console tree, right-click Personal, click All Tasks, and then click Import.

  3. In the Certificate Import Wizard, click Next.

  4. In File name, type the path and file name of the .pfx file, and then click Next.

  5. In Password, type the password you entered in the previous procedure, and then click Next.

  6. On the Certificate Store page, click Automatically select the certificate store based on the type of certificate, and then click Next.

  7. On the Completing the Certificate Import Wizard page, click Finish.

  8. To verify that the recovered certificate has been imported successfully, in the console tree, double-click Personal, and then click Certificates.

  9. Double-click the certificate. Click the Details tab, and then verify that the serial number matches the original.

Additional considerations

  • To open a command prompt, click Start, point to All Programs, click Accessories, and then click Command Prompt.

Additional references

  • Managing Key Archival and Recovery


Managing Policy and Exit Modules

Policy modules determine whether a certificate request should be automatically approved, denied, or marked as pending. Exit modules provide an opportunity to perform certain tasks after a certificate is issued.

Active Directory Certificate Services (AD CS) includes one policy module (Certpdef.dll) and one exit module (Certxds.dll). The policy module includes two separate policies: enterprise and stand-alone. To compare a certification authority (CA) that uses an enterprise policy and a CA that uses a stand-alone policy, see Enterprise Certification Authorities and Stand-Alone Certification Authorities.

As a CA administrator, you can replace these default modules with your own custom policy and exit modules or another vendor's policy and exit modules. In addition, if you have upgraded to AD CS in Windows Server 2008 R2 or Windows Server 2008 from Certificate Services in an earlier version of Windows, you can use the same policy module you used prior to upgrading. When you view the properties of the CA, the policy module will be listed either as a legacy policy module or with its original name, depending on how it was created.

Policy module

The policy module provided with a Windows Server 2008 R2–based CA determines the default action of a CA upon receiving a certificate request: approve, deny, or mark as pending.

In the majority of instances, the administrator of a stand-alone CA should set all incoming certificate requests to pending. Otherwise, because the stand-alone CA does not verify the identity of requesters via Active Directory Domain Services (AD DS), there is no way to verify the identity and validity of the certificate requester.

The CA can have only one policy module loaded at a time.

Exit module

The exit module that is provided with a Windows Server 2008 R2–based CA can be configured to perform the following functions:

  • Send e-mail when a certification event occurs.

  • Publish certificates to the file system.

This is not an exhaustive list of the functions of the exit module. Unlike the policy module, multiple exit modules can be used by a CA simultaneously.

Customizing AD CS policy and exit modules

To configure the settings of the default policy and exit modules, see Configuring the Policy and Exit Modules.

To configure options for sending e-mail, see Send E-mail When a Certification Event Occurs.

Programmable interfaces are included in AD CS for developers to create customized policy modules. For more information, see Certificate Services Architecture (http://go.microsoft.com/fwlink/?LinkId=91405).

If you have created a customized policy module and you want to change the policy module, see Select a Different Policy Module.

If you have created a customized exit module and you want to change or add an exit module, see Select a Different Exit Module.


Configuring the Policy and Exit Modules

The administrator of a certification authority (CA) can configure settings in the default policy and exit modules provided with Active Directory Certificate Services (AD CS) by using the Certification Authority snap-in.

You can configure the following policy module settings:

  • The default action of the CA upon receiving a valid certificate request. You can specify whether a stand-alone CA will hold incoming certificate requests as pending or automatically issue the certificate. In most cases, for security reasons, it is recommended that all incoming certificate requests to a stand-alone CA be marked as pending.

    To change the default action of a CA upon receipt of a certificate request, see Set the Default Action Upon Receipt of a Certificate Request.

You can configure the following exit module settings:

  • Allow certificate publication to the file system. You can select whether to allow the publishing of certificates to the file system. Actual publication will only occur if the certificate request specifies a file system location where the certificate is to be published.

    To allow or disallow the publishing of certificates to the file system, see Publish Certificates to the File System.

  • Send e-mail when a certification event occurs. You can configure the CA to send e-mail when a certification event occurs, such as the issuance of a certificate or when a certificate request is set to pending.

    To configure options for sending e-mail, see Send E-mail When a Certification Event Occurs.

Additional references

  • Managing Policy and Exit Modules


Select a Different Policy Module

You must be a certification authority (CA) administrator to complete this procedure. For more information, see Implement Role-Based Administration.

To select a different policy module

  1. Open the Certification Authority snap-in.

  2. In the console tree, click the name of the CA.

  3. On the Action menu, click Properties.

  4. On the Policy Module tab, click Select.

  5. Click the new policy module, and then click OK.

  6. If the policy module has its own configuration interface, you can configure it by clicking Properties.

  7. Stop and restart the CA.

Additional considerations

  • To register a new policy module so that it is available in the list of policy modules, see Certificate Services Architecture (http://go.microsoft.com/fwlink/?LinkId=91405).

  • Only one policy module can be active at a time.

  • To stop and restart the CA, at the command prompt, type:

    net stop certsvc
net start certsvc

Additional references

  • Managing Policy and Exit Modules


Select a Different Exit Module

An exit module provides an opportunity to perform certain tasks after a certificate is issued. You can replace the default exit module with a different exit module. To register a new exit module so that it is available in the list of exit modules, see Exit Modules (http://go.microsoft.com/fwlink/?LinkId=91407).

Note

Multiple exit modules can be enabled at the same time.

You must be a certification authority (CA) administrator to complete this procedure. For more information, see Implement Role-Based Administration.

To select a different exit module

  1. Open the Certification Authority snap-in.

  2. In the console tree, click the name of the CA.

  3. On the Action menu, click Properties.

  4. On the Exit Module tab, click Add.

  5. Click the new exit module, and then click OK.

  6. If the exit module has its own configuration interface, you can configure it by clicking Properties.

  7. Stop and restart Active Directory Certificate Services (AD CS).

Additional references

  • Managing Policy and Exit Modules


Protecting a CA from Data Loss

A certification authority (CA) is an important resource for any organization. Therefore, it is important to plan for potential problems, such as hard disk failure or database corruption, by backing up and restoring a CA regularly. A complete backup of a server will also provide backup for the CA installed on the server. However, you can also back up and restore just the CA. Also, for hardware that is several years old, some organizations might decide to move a CA to new hardware both to improve performance and to remove older hardware from service before a critical component failure occurs.

  • Back Up a Certification Authority

  • Restore a CA from a Backup Copy


Back Up a Certification Authority

You can back up a certification authority (CA) without having to back up the entire server on which the CA is installed. However, in most situations you should use the Backup snap-in to back up and restore both the CA and the server at the same time.

You must be a CA administrator or a member of the Backup Operators group, or equivalent, to complete this procedure. For more information, see Implement Role-Based Administration.

To back up a CA by using the Certification Authority snap-in

  1. Open the Certification Authority snap-in.

  2. In the console tree, click the name of the CA.

  3. On the Action menu, point to All Tasks, and click Back Up CA.

  4. Follow the instructions in the CA Backup Wizard.

You can also back up a CA by using the Certutil command-line tool.

You must be a CA administrator or a member of the Backup Operators group, or equivalent, to complete this procedure. For more information, see Implement Role-Based Administration.

To back up a CA by using Certutil

  • At a command prompt, type:

    certutil -backup <BackupDirectory>

    BackupDirectory is the path used to store the backup data.

Additional considerations

  • To open a command prompt, click Start, point to All Programs, click Accessories, and then click Command Prompt.

Additional references

  • Protecting a CA from Data Loss


Restore a CA from a Backup Copy

In general, you should use the Backup snap-in to back up and restore both a certification authority (CA) and the server at the same time. However, there may be times when you want to restore just a CA without restoring the entire server on which the CA is installed.

You must be a CA administrator or a member of the Backup Operators group, or equivalent, to complete this procedure. For more information, see Implement Role-Based Administration.

To restore a CA from a backup copy by using the Certification Authority snap-in

  1. Open the Certification Authority snap-in.

  2. In the console tree, click the name of the CA.

  3. On the Action menu, point to All Tasks, and click Restore CA.

  4. Follow the instructions in the Certification Authority Restore Wizard.

You can also complete this procedure by using the Certutil command-line tool.

You must be a CA administrator or a member of the Backup Operators group, or equivalent, to complete this procedure. For more information, see Implement Role-Based Administration.

To restore a CA from a backup copy by using Certutil

  • At a command prompt, type:

    certutil -restore <BackupDirectory>

    BackupDirectory specifies the path where the backup data is located.

Additional considerations

  • To open a command prompt, click Start, point to All Programs, click Accessories, and then click Command Prompt.

Additional references

  • Protecting a CA from Data Loss


Recurring Management Tasks

The following tasks will likely be performed on a daily, weekly, or other frequent basis.

  • Managing Certificate Enrollment

  • Manage Certificate Revocation


Managing Certificate Enrollment

The administrator of a certification authority (CA) can manage certificate enrollment by:

  • Configuring certificate enrollment and autoenrollment options on certificate templates. For more information, see Issuing Certificates Based on Certificate Templates (http://go.microsoft.com/fwlink/?LinkId=142333).

  • Enabling certificate autoenrollment options in Group Policy. For more information, see Configure Certificate Autoenrollment.

  • Configuring the default request handling options for the CA. For more information, see Set the Default Action Upon Receipt of a Certificate Request.

    Note

    You can specify whether a stand-alone CA will hold incoming certificate requests as pending or automatically issue the certificate. In most cases, for security reasons, all incoming certificate requests to a stand-alone CA should be marked as pending.

  • Selecting whether to allow certificates to be published to the file system. Actual publication will only occur if the certificate request specifies a file system location where the certificate is to be published. For more information, see Publish Certificates to the File System.

  • Evaluating and acting on pending certificate requests. For more information, see Review Pending Certificate Requests.

Additional references

  • Recurring Management Tasks


Configure Certificate Autoenrollment

Many certificates can be distributed without the client even being aware that enrollment is taking place. These can include most types of certificates issued to computers and services, as well as many certificates issued to users.

To automatically enroll clients for certificates in a domain environment, you must:

  • Configure a certificate template with Autoenroll permissions. For more information, see Issuing Certificates Based on Certificate Templates (http://go.microsoft.com/fwlink/?LinkId=142333).

  • Configure an autoenrollment policy for the domain.

Membership in Domain Admins or Enterprise Admins, or equivalent, is the minimum required to complete this procedure. For more information, see Implement Role-Based Administration.

To configure autoenrollment Group Policy for a domain

  1. On a domain controller running Windows Server 2008 R2 or Windows Server 2008, click Start, point to Administrative Tools, and then click Group Policy Management.

  2. In the console tree, double-click Group Policy Objects in the forest and domain containing the Default Domain Policy Group Policy object (GPO) that you want to edit.

  3. Right-click the Default Domain Policy GPO, and then click Edit.

  4. In the Group Policy Management Console (GPMC), go to User Configuration, Windows Settings, Security Settings, and then click Public Key Policies.

  5. Double-click Certificate Services Client - Auto-Enrollment.

  6. Select the Enroll certificates automatically check box to enable autoenrollment. If you want to block autoenrollment from occurring, select the Do not enroll certificates automatically check box.

  7. If you are enabling certificate autoenrollment, you can select the following check boxes:

    • Renew expired certificates, update pending certificates, and remove revoked certificates enables autoenrollment for certificate renewal, issuance of pending certificate requests, and the automatic removal of revoked certificates from a user's certificate store.

    • Update certificates that use certificate templates enables autoenrollment for issuance of certificates that supersede issued certificates.

  8. Click OK to accept your changes.

Additional references

  • Managing Certificate Enrollment


Set the Default Action Upon Receipt of a Certificate Request

You can configure the policy module to automatically approve all certificate requests or to mark requests as pending until an administrator can review and act upon the request. The choice will likely depend on the security implications of the certificates being issued, the intended recipients of the certificates, and other factors.

You must be a certification authority (CA) administrator to complete this procedure. For more information, see Implement Role-Based Administration.

To set the default action upon receipt of a certificate request

  1. Open the Certification Authority snap-in.

  2. In the console tree, click the name of the CA.

  3. On the Action menu, click Properties.

  4. On the Policy Module tab, click Properties.

  5. Click the option you want:

    • To have the CA administrator review every certificate request before issuing a certificate, click Set the certificate request status to pending.

    • To have the CA issue certificates based on the configuration of the certificate template, click Follow the settings in the certificate template, if applicable. Otherwise, automatically issue the certificate.

  6. Stop and restart the CA.
Caution

In most cases, for security reasons, it is recommended that all incoming certificate requests to a stand-alone CA be marked as pending. Unlike enterprise CAs, stand-alone CAs do not use Active Directory Domain Services (AD DS), even if it is available, to verify that an individual or computer is authorized to be issued a certificate from the CA automatically. For stand-alone CAs, the CA administrator is responsible for verifying the identity of the certificate requester.

If you change the setting from Set the certificate request status to pending to Follow the settings in the certificate template, if applicable. Otherwise, automatically issue the certificate, this will apply only to certificate requests submitted to the CA after the default action has been changed. If there are pending requests held by the CA, these requests will remain pending until the CA administrator issues the certificates or denies the requests.

Additional references

  • Managing Certificate Enrollment

  • Review Pending Certificate Requests


Review Pending Certificate Requests

One of the most important and common duties of a certification authority (CA) administrator or certificate manager is to review pending certificate requests to decide whether the requested certificate should be issued or not.

In most cases, for security reasons, it is strongly recommended that all incoming certificate requests to a stand-alone CA be marked as pending. Unlike enterprise CAs, stand-alone CAs do not use Active Directory Domain Services (AD DS), even if it is available, to verify that an individual or computer is authorized to be issued a certificate from the CA automatically. For stand-alone CAs, the CA administrator is responsible for verifying the identity of the certificate requester.

You must be a CA administrator or certificate manager to complete this procedure. For more information, see Implement Role-Based Administration.

To review pending certificate requests

  1. Open the Certification Authority snap-in.

  2. In the console tree, click Pending Requests.

  3. In the details pane, examine each certificate request by noting the values for requester name, requester e-mail address, and any other fields that you consider critical information for issuing the certificate.

Additional considerations

  • Failed certificate requests can also be issued by using the same procedure in the Failed Requests container. However, not all of the security requirements for the certificate can be verified when issuing a failed request. Caution should be used.

Additional references

  • Managing Certificate Enrollment

  • Set the Default Action Upon Receipt of a Certificate Request


Publish Certificates to the File System

The following procedure can be used to publish issued certificates to the file system.

To request a certificate and have it published to the file system, certificate requestors must include a certfile:true attribute in their request. After the certificate is issued, it is copied to FileName.cer, where FileName is the request ID of the certificate request.

The file is copied to the CertEnroll folder on the certification authority (CA).

Note

You cannot use this method to overwrite files.

You must be a CA administrator to complete this procedure. For more information, see Implement Role-Based Administration.

To publish certificates to the file system

  1. Open the Certification Authority snap-in.

  2. In the console tree, click the name of the CA.

  3. On the Action menu, click Properties.

  4. On the Exit Module tab, click Properties.

  5. On the Publication Settings tab, select the Allow certificates to be published to the file system check box, and then click OK.

  6. Stop and restart the CA.

Additional references

  • Managing Certificate Enrollment


Manage Certificate Revocation

Certificates can be revoked for a variety of reasons, including:

  • The key has been compromised.

  • The certification authority (CA) that issued the certificate has been compromised.

  • The certificate is no longer valid for the intended purpose or has been superseded by another certificate.

  • The client no longer qualifies for the certificate.

You must be a CA administrator or certificate manager to complete this procedure. For more information, see Implement Role-Based Administration.

To revoke a certificate

  1. Open the Certification Authority snap-in.

  2. In the console tree, click Issued Certificates.

  3. In the details pane, click the certificate you want to revoke.

  4. On the Action menu, point to All Tasks, and click Revoke Certificate.

  5. Select the reason for revoking the certificate, adjust the time of the revocation, if necessary, and then click Yes.

The following reason codes are available:

  • Unspecified

  • Key Compromise

  • CA Compromise

  • Change of Affiliation

  • Superseded

  • Cease of Operation

  • Certificate Hold

If you specify "Certificate Hold" as the reason for revoking the certificate, it typically means that you may want to unrevoke the certificate at a future time. Only certificates that have been revoked with the reason of "Certificate Hold" can be unrevoked.

You must be a CA administrator or certificate manager to complete this procedure. For more information, see Implement Role-Based Administration.

To unrevoke a certificate

  1. Open the Certification Authority snap-in.

  2. In the console tree, click Revoked Certificates.

  3. In the details pane, click the certificate you want to unrevoke.

  4. On the Action menu, point to All Tasks, and click Unrevoke Certificate.

  5. Select the reason for unrevoking the certificate, adjust the time of the revocation, if necessary, and then click Yes.

To be meaningful, certificate revocation must be combined with the publication and distribution of certificate revocation data.

Additional references

  • Configuring Certificate Revocation


Use the Network Device Enrollment Service

The Network Device Enrollment Service allows software on routers and other network devices running without domain credentials to obtain certificates based on the Simple Certificate Enrollment Protocol (SCEP).

Note

SCEP was developed to support the secure, scalable issuance of certificates to network devices by using existing certification authorities (CAs). The protocol supports CA and registration authority public key distribution, certificate enrollment, certificate revocation, certificate queries, and certificate revocation queries.

The Network Device Enrollment Service performs the following functions:

  • Generates and provides one-time enrollment passwords to administrators.

  • Submits SCEP enrollment requests to the CA.

  • Retrieves enrolled certificates from the CA and forwards them to the network device.

Enrolling for a certificate with the Network Device Enrollment Service involves the software used to manage the network device, the registration authority, the computer hosting the Network Device Enrollment Service, and the CA.

You must be a registration authority for the CA and an administrator on the network device to complete this procedure. For more information, see Implement Role-Based Administration.

To request and enroll for a certificate by using the Network Device Enrollment Service

  1. Run the software used to manage the network device, and use this software to generate an RSA public/private key pair configured for one of the following:

    • Signing and signature verification

    • Encryption and decryption

    • Signing, signature verification, encryption, and decryption

  2. Use the device software to forward this key pair to the registration authority on the computer hosting the Network Device Enrollment Service.

  3. Open a Web browser, and go to http://localhost/certsrv/mscep_admin.

  4. If the password table is not full, the Network Device Enrollment Service will create a random password and embed it in an HTML page that is returned to the caller.

    Note

    Every time you connect to this URL, a different challenge password is displayed. Each challenge password is valid for 60 minutes and can only be used once.

  5. Use the device software, along with the password, to submit a certificate request through the Network Device Enrollment Service, which relays the request to the CA.

  6. If the enrollment request is successful, the requested certificate is returned to the device from the CA through the Network Device Enrollment Service.

By default, the Network Device Enrollment Service can only cache five passwords at a time. If the password cache is full when you submit a password request, you must do one of the following before resubmitting your request:

  • Wait until one of the passwords has expired before submitting a new request.

  • Stop and restart Internet Information Services (IIS) to delete all passwords stored in the cache.

  • Configure the service to cache more than five passwords at a time.

Additional references

  • Managing a Certification Authority

  • Configure the Network Device Enrollment Service


Using Policy to Manage Active Directory Certificate Services

Domain Group Policy can be used to manage the following types of certificate-related activities in an Active Directory Domain Services (AD DS) environment:

  • Credential roaming

  • Autoenrollment of certificates

  • Certificate path validation

  • Certificate distribution

Credential roaming

Credential roaming allows X.509 certificates, certificate requests, and private keys specific to a user in AD DS to be stored independently from the user profile and used on any computer on the network.

Digital certificates and private keys involve comparatively small amounts of data that need to be stored in a secure manner. Credential roaming policy provides a means for managing the use of these credentials on multiple computers in a manner that addresses the secure storage and size requirements of digital certificates and private keys. In Windows Server 2008 R2 and Windows Server 2008, credential roaming policy includes stored user names and passwords as well as certificates and keys.

For more information, see Enable Credential Roaming.

For more information about credential roaming and significant differences between its implementation in Windows Server 2008, Windows Server 2003, Windows Vista, and Windows XP, see Configuring and Troubleshooting Certificate Services Client–Credential Roaming (http://go.microsoft.com/fwlink/?LinkID=85332).

Certificate autoenrollment

Many organizations use Group Policy to automatically enroll users, computers, or services for certificates.

For more information, see Configure Certificate Autoenrollment.

Certificate path validation

As certificate use for secure communication and data protection is increasing, administrators can use certificate trust policy to enhance their control of certificate use and public key infrastructure performance by using certificate path validation options.

Certificate path validation settings in Group Policy allow administrators to manage stores, trusted publishers, network retrieval, and revocation checking.

For more information, see Manage Certificate Path Validation.

Certificate distribution

The certificate distribution capabilities in Group Policy are useful for managing certificate-related trust in an organization. It allows you to ensure that certain certificates are trusted and that certificate chain building occurs with little or no user intervention. You can also block the use of certificates that you cannot directly revoke because they were issued by an external certification authority (CA).

For more information, see Use Policy to Distribute Certificates.

Additional references

  • Managing a Certification Authority


Enable Credential Roaming

To use credential roaming, all of your organization's domain controllers should be running Windows Server 2008 R2, Windows Server 2008, or Windows Server 2003 Service Pack 1 (SP1). In addition, clients used for credential roaming must also be running Windows 7, Windows Vista, Windows XP Service Pack 2 (SP2), Windows Server 2003 SP1, or Windows Server 2008.

If you have at least one domain controller running Windows Server 2008 R2 or Windows Server 2008 in your Active Directory environment, you can use Group Policy to configure credential roaming.

If you do not have a domain controller running Windows Server 2008 R2 or Windows Server 2008, you must complete the following steps before configuring credential roaming through Group Policy:

  1. Prepare Active Directory Domain Services (AD DS). AD DS needs to be prepared to store users' certificates, keys, and Data Protection application programming interface (DPAPI) master keys.

  2. Exclude directories in roaming profiles. If roaming profiles are used, certain directories have to be excluded from roaming to avoid conflicts with credential roaming.

  3. Install the Group Policy ADM template. Credential roaming will be enabled through a Group Policy ADM template that sets the appropriate registry values on a client computer.

For assistance with these preparatory steps in networks with domain controllers that are still running Windows Server 2003, see Configuring and Troubleshooting Certificate Services Client–Credential Roaming (http://go.microsoft.com/fwlink/?LinkID=85332).

Membership in Enterprise Admins or Domain Admins, or equivalent, is the minimum required to complete this procedure. For more information, see Implement Role-Based Administration.

To configure credential roaming for a domain by using Group Policy

  1. On a domain controller running Windows Server 2008 R2 or Windows Server 2008, click Start, point to Administrative Tools, and then click Group Policy Management.

  2. In the console tree, double-click Group Policy Objects in the forest and domain containing the Default Domain Policy Group Policy object (GPO) that you want to edit.

  3. Right-click the Default Domain Policy GPO, and then click Edit.

  4. In the Group Policy Management Console (GPMC), go to User Configuration, Windows Settings, Security Settings, and then click Public Key Policies.

  5. Double-click Certificate Services Client - Credential Roaming.

  6. Click Enabled to configure credential roaming or Disabled to block its use.

  7. If you clicked Enabled, you can also customize the following options:

    • Maximum tombstone credentials lifetime in days. Allows you to define how long a roaming credential will remain in AD DS for a certificate or key that has been deleted locally.

    • Maximum number of roaming credentials per user. Allows you to define a maximum number of certificates and keys that can be used with credential roaming.

    • Maximum size (in bytes) of a roaming credential. Allows you to restrict roaming for credentials that exceed a defined size.

    • Roam stored user names and passwords. Allows you to include or exclude stored user names and passwords from the credential roaming policy.

  8. Click OK to accept your changes.

The default options for credential roaming in step 7 will be acceptable to many organizations. However, credential roaming can affect the size of the Active Directory database if an organization has a large number of users and credentials. For information that can help you estimate the potential impact of credential roaming on your Active Directory database, see Configuring and Troubleshooting Certificate Services Client–Credential Roaming (http://go.microsoft.com/fwlink/?LinkID=85332).

Additional references

  • Using Policy to Manage Active Directory Certificate Services


Manage Certificate Path Validation

Certificate path validation settings in Windows Server 2008 R2 and Windows Server 2008 allow you to manage the settings for certificate path discovery and validation for all users in a domain. You can use Group Policy to easily configure and manage these certificate validation settings. The following are some of the tasks you can perform with these settings:

  • Deploy intermediate certification authority (CA) certificates.

  • Block certificates that are not trusted.

  • Manage certificates used for code signing.

  • Configure retrieval settings for certificates and certificate revocation lists (CRLs).

Certificate path validation settings are available in Group Policy at the following location: Computer Configuration\Windows Settings\Security Settings\Public Key Policies.

When you double-click Certificate Path Validation Settings at this location, additional options are available by selecting the following tabs:

  • Stores

  • Trusted Publishers

  • Network Retrieval

  • Revocation

The following procedure describes how to configure certificate path validation settings. The sections following the procedure will describe the settings in each of these areas.

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. For more information, see Implement Role-Based Administration.

To configure path validation Group Policy for a domain

  1. On a domain controller, click Start, point to Administrative Tools, and then click Group Policy Management.

  2. In the console tree, double-click Group Policy Objects in the forest and domain containing the Default Domain Policy Group Policy object (GPO) that you want to edit.

  3. Right-click the Default Domain Policy GPO, and then click Edit.

  4. In the Group Policy Management Console (GPMC), go to Computer Configuration, Windows Settings, Security Settings, and then click Public Key Policies.

  5. Double-click Certificate Path Validation Settings, and then click the Stores tab.

  6. Select the Define these policy settings check box.

  7. Configure the optional settings that you need to apply.

  8. When you are finished making changes, you can select a different tab to modify additional settings, or click OK to apply the new settings.

Stores tab

Some organizations want to prevent users in the domain from configuring their own set of trusted root certificates and to decide which root certificates within the organization can be trusted. The Stores tab can be used to accomplish this.

The following options are available on the Stores tab:

  • Allow user trusted root CAs to be used to validate certificates. Clearing this check box prevents users from deciding which root CA certificates to use to validate certificates. Although this option can help prevent users from trusting and validating certificates from a chain that is not secure, it can also result in application failures or lead users to disregard root certificate trust as a means of validating a certificate that is presented to them.

  • Allow users to trust peer trust certificates. Clearing this check box prevents users from deciding which peer certificates to trust. Although this option can help prevent users from trusting certificates from a source that is not secure, it can also result in application failures or lead users to disregard certificates as a means of establishing trust. You can also select the certificate purposes, such as signing or encryption, for which peer trust certificates can be used.

  • Root CAs the client computer can trust. In this section, you can identify specific root CAs that can be trusted by users in the domain:

    • Third-Party Root CAs and Enterprise Root CAs. By including both non-Microsoft and enterprise root CAs, you broaden the range of root CA certificates that a user can trust.

    • Only Enterprise Root CAs. By restricting trust to only enterprise root CAs, you effectively restrict trust to certificates issued by an internal enterprise CA that obtains authentication information from and publishes certificates to Active Directory Domain Services (AD DS).

  • CAs must also be compliant with User Principal Name constraints. These settings also restrict trust to internal enterprise CAs. In addition, the user principal name constraint would prevent them from trusting authentication-related certificates that do not conform to conditions related to user principal names.

In addition, some organizations may want to identify and distribute specific trusted root certificates to enable business scenarios where additional trust relationships are needed. To identify the trusted root certificates that you would like to distribute to clients in your domain, see Use Policy to Distribute Certificates.

Trusted Publishers tab

Software signing is being used by a growing number of software publishers and application developers to verify that their applications come from a trusted source. However, many users do not understand or ignore the signing certificates associated with applications that they install.

The policy options on the Trusted Publishers tab of the certificate path validation policy allow you to control who can make decisions about trusted publishers:

  • Administrators and users

  • Only administrators

  • Only enterprise administrators

In addition, policy options on this tab allow you to require that trusted publisher certificates be checked that they:

  • Have not been revoked

  • Have valid time stamps

Network Retrieval tab

To be effective, certificate-related data such as certificate revocation lists (CRLs) and certificates in the Microsoft Root Certificate Program must be updated regularly. However, problems can arise if validation checking and retrieval of certificate revocation data and cross-certificates are interrupted because more data is being transferred than originally anticipated.

Network retrieval settings allow administrators to:

  • Automatically update certificates in the Microsoft Root Certificate Program.

  • Configure retrieval timeout values for CRLs and path validation (larger default values may be useful if network conditions are not optimal).

  • Enable issuer certificate retrieval during path validation.

  • Define how frequently cross-certificates are downloaded.

Revocation tab

To support revocation checking, Active Directory Certificate Services (AD CS) supports the use of CRLs and delta CRLs as well as Online Certificate Status Protocol (OCSP) responses distributed by Online Responders.

Path validation Group Policy settings allow administrators to optimize the use of CRLs and Online Responders, particularly in situations where extremely large CRLs or network conditions detract from performance.

The following settings are available:

  • Always prefer Certificate Revocation Lists (CRLs) over Online Certificate Status Protocol (OCSP) responses. In general, clients should use the most recent revocation data that is available, regardless of whether it comes from a CRL or Online Responder. If this option is selected, a revocation check from an Online Responder will only be used if a valid CRL or delta CRL is not available.

  • Allow CRL and OCSP responses to be valid longer than their lifetime. It is generally not recommended to allow CRLs and OCSP responses to be valid beyond their validity period. However, this option might be needed in situations where clients are unable to connect to a CRL distribution point or Online Responder for an extended amount of time. However, the length of time beyond the stated validity period that a CRL or OCSP response can be used is also configurable under this policy setting.

Additional references

  • Using Policy to Manage Active Directory Certificate Services


Use Policy to Distribute Certificates

Certificates are important credentials. Administrators may not want to let users decide which certificates to trust and which not to trust. Often the decision to trust or not trust a particular certificate should be made by an administrator or individual who is knowledgeable about the particular certificate and its trust implications for the organization.

You can use Group Policy to distribute the following types of certificates to clients.

Type of certificate | Description
Trusted Root Certification Authorities | Implicitly trusted certification authorities (CAs). Includes all of the certificates in the Third-Party Root Certification Authorities store plus root certificates from your own organization and Microsoft.
Enterprise Trust | A certificate trust list provides a mechanism for trusting self-signed root certificates from other organizations and limiting the purposes for which these certificates are trusted.
Intermediate Certification Authorities | Certificates issued to subordinate CAs.
Trusted Publishers | Certificates from CAs that are trusted.
Untrusted Certificates | Certificates that you have explicitly decided not to trust because they are no longer valid for their intended purpose or because they are from a source that domain clients should not trust.
Trusted People | Certificates issued to people or end entities that are explicitly trusted. Most often these are self-signed certificates or certificates explicitly trusted in an application such as Microsoft Outlook.

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. For more information, see Implement Role-Based Administration.

To add certificates to the Trusted Root Certification Authorities store for a domain

  1. Click Start, point to Administrative Tools, and then click Group Policy Management.

  2. In the console tree, double-click Group Policy Objects in the forest and domain containing the Default Domain Policy Group Policy object (GPO) that you want to edit.

  3. Right-click the Default Domain Policy GPO, and then click Edit.

  4. In the Group Policy Management Console (GPMC), go to Computer Configuration, Windows Settings, Security Settings, and then click Public Key Policies.

  5. Right-click the Trusted Root Certification Authorities store.

  6. Click Import and follow the steps in the Certificate Import Wizard to import the certificates.

Additional references

  • Using Policy to Manage Active Directory Certificate Services


Troubleshoot Active Directory Certificate Services

This section lists a few common issues you may encounter when using the Certification Authority snap-in or working with certification authorities (CAs). For more information about troubleshooting and resolving problems with CAs, see Active Directory Certificate Services Troubleshooting (http://go.microsoft.com/fwlink/?LinkId=89215).

What problem are you having?

  • Clients do not automatically enroll for certificates after autoenrollment is configured

  • A CA could not be installed as an enterprise CA, or CA Web enrollment support could not be installed to recognize a stand-alone CA

  • Error when accessing the CA Web pages

  • A user tries to log on with the smart card and receives this message: "The system cannot log you on to this domain because the system's computer account in its primary domain is missing or the password on the account is incorrect."

  • When trying to enroll for a certificate from a computer or account belonging to a child domain of the domain where the CA is located, the following message appears: "No template could be found. There are no CAs from which you have permission to request a certificate, or an error occurred while accessing the Active Directory."

  • An enrollment agent cannot enroll on behalf of a user for a specific certificate template

  • Restricted certificate manager or enrollment agent operations cannot be completed after a domain is renamed

  • I cannot add a new version 2 or version 3 certificate template to my CA

  • I have a problem that is not listed here
Clients do not automatically enroll for certificates after autoenrollment is configured.
  • Cause: The Group Policy information used for autoenrollment has not yet replicated to the client computers. By default, this information can take up to two hours to replicate to all computers.

  • Solution: Wait for Group Policy to complete replication or use the Gpupdate command-line tool to force replication to occur immediately. For more information, see Gpupdate (http://go.microsoft.com/fwlink/?LinkId=94248).

A CA could not be installed as an enterprise CA, or CA Web enrollment support could not be installed to recognize a stand-alone CA.
  • Cause: The CA was installed by a user who is not a member of the Enterprise Admins or Domain Admins group; therefore, the enterprise CA option was not available and information about the CA cannot be published to Active Directory Domain Services (AD DS).

  • Solution: Log on as a user who is a member of the Enterprise Admins or Domain Admins group to install the CA and CA Web enrollment support.

  • Cause: The domain was not accessible during CA setup.

  • Solution: Ensure that you have network connectivity to a domain controller during CA setup.

Error when accessing the CA Web pages.
  • Cause: The user accessing the Web pages is not a member of the Administrators or Power Users group on the local computer. When a newer version of the Web enrollment software is available on the CA, the client computer must install that software. The user must be a member of the Administrators or Power Users group to install the software.

  • Solution: Log on as a user who is a member of the Administrators or Power Users group to access the Web enrollment pages and download the newer version of the software.

  • Cause: Web pages aren't installed on the CA.

  • Solution: From a command prompt on the CA, run certutil -vroot to install the Web enrollment pages.

A user tries to log on with the smart card and receives this message: "The system cannot log you on to this domain because the system's computer account in its primary domain is missing or the password on the account is incorrect."
  • Cause: The computer account may be disabled, or the CA that issued the smart card certificate is not trusted by the computer.

  • Solution:

    1. Verify that the computer account is enabled in the domain.

    2. Use the Certificates snap-in to verify that the root CA's certificate is in the Trusted Root Certification Authorities store on the user's computer.

    3. Use the Certificates snap-in to verify that the domain controller has been issued a domain controller certificate that can be verified to a trusted root.

When trying to enroll for a certificate from a computer or account belonging to a child domain of the domain where the CA is located, the following error appears: "No template could be found. There are no CAs from which you have permission to request a certificate, or an error occurred while accessing the Active Directory."
  • Cause: The necessary security permissions are not set on the certificate templates.

  • Solution: Modify the security permissions for the certificate templates to include the child domain accounts from which you want to allow enrollment. To set access control for certificate templates, see Issuing Certificates Based on Certificate Templates (http://go.microsoft.com/fwlink/?LinkID=142333).

    Some access control caches must time out after changes are made to security permissions, so you might have to wait a short period of time before the new security permissions are replicated through the network.

An enrollment agent cannot enroll on behalf of a user for a specific certificate template.
  • Cause: Enrollment agent restrictions may have been configured to prevent the enrollment agent from enrolling for certificates based on the certificate template for this user group.

  • Solution: This behavior may be by design, if you do intend for the enrollment agent to enroll for certificates based on this certificate template or for this group of users. If it is not by design, follow the steps in Establish Restricted Enrollment Agents to configure the correct enrollment agent permissions for this group and certificate template.

  • Cause: The enrollment agent certificate is configured with a Cryptography Next Generation (CNG) key, and the certificate is being requested from a Windows Server 2003–based CA.

  • Solution: Use an enrollment agent certificate that is compatible with Windows Server 2003–based CAs, or request the certificate from a CA on a computer running Windows Server 2008 R2 or Windows Server 2008.

Restricted certificate manager or enrollment agent operations cannot be completed after a domain is renamed.
  • Cause: For restricted officer operations, a CA relies on the Security Accounts Manager (SAM) name of the requester that is stored in the Active Directory database to verify that the officer has rights to manage the request. However, the SAM name contains the domain name and the restricted officer operation will fail if the domain name is changed (instead of just the DNS portion of the name).

  • Solution: Disable or reconfigure the restricted officer permissions before attempting the enrollment operation again.

I cannot add a new version 2 or version 3 certificate template to my CA.
  • Cause: The CA is installed on a server running Windows Server 2008 R2 Standard or Windows Server 2008 Standard. Version 2 and version 3 certificate templates and certificate autoenrollment can only be used with CAs installed on Windows Server 2008 R2 Enterprise, Windows Server 2008 R2 Datacenter, Windows Server 2008 Enterprise, or Windows Server 2008 Datacenter.

  • Solution: Upgrade to Windows Server 2008 R2 Enterprise, Windows Server 2008 R2 Datacenter, Windows Server 2008 Enterprise, or Windows Server 2008 Datacenter.

I have a problem that is not listed here.
  • Cause: Check the event log of the server. It often contains more detailed error messages that can help you diagnose and solve the problem you are having.

  • Solution: For more information about events that are logged by Active Directory Certificate Services, see Active Directory Certificate Services Troubleshooting (http://go.microsoft.com/fwlink/?LinkId=89215).


Active Directory Certificate Services Resources

  • For extensive evaluation, design, deployment, troubleshooting, and technical reference information, including white papers and Knowledge Base (KB) articles, see Active Directory Certificate Services (http://go.microsoft.com/fwlink/?LinkID=85613).

  • For information about developing applications that use Active Directory Certificate Services (AD CS), see Win32 and COM Security Development (http://go.microsoft.com/fwlink/?LinkId=92771).

  • For public information about public key infrastructures (PKIs), see the National Institute of Standards and Technology (NIST) PKI Web site (http://go.microsoft.com/fwlink/?LinkId=92772).

  • For information about the PKI X.509 (pkix) working group, see the Internet Engineering Task Force (IETF) Web site (http://go.microsoft.com/fwlink/?LinkID=29885).


Add the Online Responder Snap-in to a Console

You can use the Online Responder snap-in to monitor and manage the Online Responder service and revocation configurations on this computer or another computer.

You must have Manage Online Responder permissions on the server hosting the Online Responder to complete this procedure. For more information about administering a public key infrastructure (PKI), see Implement Role-Based Administration.

To add the Online Responder snap-in to a console

  1. Click Start, type mmc, and then press ENTER.

  2. On the File menu, click Add/Remove Snap-in.

  3. Under Available snap-ins, double-click Online Responder, select the computer on which the Online Responder is installed, and then click Finish.

  4. If you have no more snap-ins to add to the console, click OK.

  5. To save this console, on the File menu, click Save.

Additional references

  • Administer an Online Responder from Another Computer


Managing Online Responders

Procedures are available to complete the following basic Online Responder management tasks:

  • Add the Online Responder Snap-in to a Console

  • Audit Online Responder Operations

  • Administer an Online Responder from Another Computer

  • Modify the Online Responder Web Proxy

  • Add OCSP Locations to Issued Certificates

  • Renew OCSP Response Signing Certificates with an Existing Key


Administer an Online Responder from Another Computer

One advantage of Online Responders is that they can be deployed to provide revocation checking services at a remote location or even outside of the local intranet. However, this would frequently require the ability to manage the Online Responder from another computer.

By default, the Online Responder snap-in is installed automatically when an Online Responder is installed on a server. The Online Responder can be installed on a different server by using Server Manager to install Active Directory Certificate Services (AD CS) tools.

Before you can enable remote administration, you must configure Online Responder–related firewall settings on the computer hosting the Online Responder.

You must be a local administrator to configure firewall settings. For more information about administering a public key infrastructure (PKI), see Implement Role-Based Administration.

To configure firewall settings to enable remote administration of an Online Responder

  1. Open Server Manager.

  2. Under Configuration, expand Windows Firewall with Advanced Security.

  3. Expand Inbound Rules, and click Online Responder Service (DCOM-In).

  4. In the Actions pane, click Enable Rule.

  5. Click Online Responder Service (RPC-In), and in the Action pane, click Enable Rule.

  6. To identify authorized users or computers that can access the Online Responder through each inbound Online Responder firewall rule, in the Actions pane, click Properties for each of these rules, and then click the Users and Computers tab.

You must be a local administrator on the remote computer to install the Remote Server Administration Tools. You must have Manage Online Responder permissions on the server hosting the Online Responder to complete this procedure. For more information about administering a PKI, see Implement Role-Based Administration.

To administer a remote Online Responder

  1. On the remote computer, open Server Manager.

  2. Under Features Summary, click Add Features.

  3. Expand Remote Server Administration Tools and Role Administration Tools.

  4. Select the Active Directory Certificate Services check box, click Next, and then click Install.

  5. When the installation process is finished, click Close.

  6. Click Start, type mmc, and press ENTER.

  7. On the File menu, click Add/Remove Snap-in.

  8. Click the Online Responder snap-in, click Add, and then click OK.

  9. In the console tree, click the Online Responder.

  10. On the Action menu, click Retarget Responder to identify the Online Responder that you want to manage.

Additional considerations

  • If the computer you want to perform remote administration tasks from is running Windows Vista, you can obtain the Remote Server Administration Tools Pack from the Microsoft Download Center (http://go.microsoft.com/fwlink/?LinkID=89361).

  • If there is a firewall between the Online Responder and the remote computer, the firewall must be configured to allow data to pass through port 80 between Internet Information Services (IIS) and the Online Responder. Similar results can be achieved by using the reverse-proxy capability of Microsoft Internet Security and Acceleration (ISA) Server.

  • It may also be necessary to configure DCOM permissions to enable the Online Responders in an Array to authenticate to each other.

Additional references

  • Managing Online Responders


Certification Authorities

The Certification Authority snap-in allows you to perform a variety of administrative tasks, including:

  • Start and stop the certification authority (CA).

  • Back up and restore the CA.

  • Change exit and policy modules.

  • View the CA certificate.

  • Install or reinstall a CA certificate for the CA.

  • Set security permissions and delegate administrative control for the CA.

  • Revoke certificates.

  • View or modify certificate revocation list (CRL) distribution points.

  • Publish CRLs and schedule CRL publication.

  • Configure the types of certificates that are to be issued by the CA.

  • View information about certificates that have been issued or revoked.

  • View, approve, or deny pending certificate requests.

  • View failed certificate requests.

  • Renew the CA's certificate.

For more information about installing, configuring, and using the Certification Authority snap-in, see Managing a Certification Authority.


Modify the Online Responder Web Proxy

The Online Responder Web proxy cache represents the service interface for the Online Responder. It is implemented as an Internet Server Application Programming Interface (ISAPI) extension hosted by Internet Information Services (IIS), and it performs the following operations:

  • Request decoding. After a request is received by the Online Responder Web proxy, the decoder component will try to decode the request and extract the certificate serial number to be validated.

  • Response caching. After a request is received and a certificate serial number is extracted, the Online Responder Web proxy will check the local cache for a valid response. The cache item validity period is set by default to the certificate revocation list (CRL) validity period from which the response was generated.

You can modify the following Web proxy–related settings for an Online Responder:

  • Web proxy threads. This setting refers to the number of threads that will be allocated by the Online Responder ISAPI extension for handling requests. Increasing the number of threads will use more of the server's memory and reducing the number of threads will reduce the number of clients that can be served concurrently.

  • Cache entries allowed. The cache is implemented as part of the Online Responder's ISAPI extension and is an in-memory cache only. The recommended cache size is between 1,000 and 10,000 entries. The minimum cache entries allowed is five. A small cache size will cause more cache faults and will result in a higher load on the Online Responder service for lookup and signing operations; a large cache size will increase the Online Responder's memory usage.

You must have Manage Online Responder permissions on the server hosting the Online Responder to complete this procedure. For more information about administering a public key infrastructure (PKI), see Implement Role-Based Administration.

To modify the Online Responder Web proxy

  1. Open the Online Responder snap-in, and select the Online Responder.

  2. Click Responder Properties on the Action menu, or click Responder Properties in the Action pane.

  3. Click the Web Proxy tab, modify the Web proxy options that you want to change, and then click OK.

Additional references

  • Managing Online Responders


Renew OCSP Response Signing Certificates with an Existing Key

Online Certificate Status Protocol (OCSP) Response Signing certificates need to be signed by the same certification authority (CA) key that was used to sign the end-entity certificates that they provide status for.

After a CA key is renewed, the CA will be using the new key to sign newly issued certificates. In the period between the time a CA certificate is renewed and the expiration date of the original CA certificate, the CA cannot issue or renew OCSP Response Signing certificates, which may prevent an Online Responder from signing OCSP responses.

To overcome this issue, Windows Server 2008 R2–based CAs and Windows Server 2008–based CAs can be configured to modify the default behavior and allow OCSP Response Signing certificates to be issued by using a renewed CA key.

You must be an administrator on the server hosting the CA to complete this procedure. For more information about administering a public key infrastructure (PKI), see Implement Role-Based Administration.

To allow OCSP Response Signing certificates to be renewed by using existing CA keys

  1. On the CA computer, open a command prompt, and type:

    certutil -setreg ca\UseDefinedCACertInRequest 1

  2. Press ENTER.

  3. Restart the CA service.

Additional references

  • Managing Online Responders


Audit Online Responder Operations

You can monitor the operations of an Online Responder by logging events to the Windows security event log. The Online Responder allows the configuration of the following audit events:

  • Start/Stop the Online Responder Service. Every Start/Stop event of the Online Responder service will be logged.

  • Changes to the Online Responder configuration. All Online Responder configuration changes, including audit settings changes, will be logged.

  • Changes to the Online Responder security settings. All changes to the Online Responder service request and management interfaces access control list (ACL) will be logged.

  • Requests submitted to the Online Responder. All requests processed by the Online Responder service will be logged. This option can create a high load on the service and should be evaluated on an individual basis. Note that only requests that require a signing operation by the Online Responder will generate and audit events; requests for previously cached responses will not be logged.

You must have Manage Online Responder permissions on the server hosting the Online Responder to complete this procedure. For more information about administering a public key infrastructure (PKI), see Implement Role-Based Administration.

To enable auditing of Online Responder operations

  1. Open the Online Responder snap-in, and select the Online Responder.

  2. Click Responder Properties on the Action menu, or click Responder Properties in the Action pane.

  3. Click the Audit tab, select the Online Responder audit options that you want to have logged, and then click OK.

Audit events will be logged to the Windows security log only if the Audit object access policy is enabled.

You must be an administrator on the server hosting the Online Responder to complete this procedure. For more information about administering a PKI, see Implement Role-Based Administration.

To enable the Audit object access policy

  1. Open the Local Group Policy Editor.

  2. Under Computer Configuration, expand Windows Settings, Security Settings, and Local Policies, and then click Audit Policy.

  3. Double-click the Audit object access policy.

  4. Select the Success and Failure check boxes, and click OK.

Additional references

  • Managing Online Responders

  • Audit Revocation Configuration Changes


Add OCSP Locations to Issued Certificates

The location of an Online Responder is specified as a URL in the authority information access extension in a certificate. When a certification authority (CA) issues a certificate, it adds the authority information access extension to the certificate; when a client needs to check the revocation status of a certificate, it will send the certificate status request to this URL.

The OCSP Properties tab allows you to add Online Responder URLs to previously issued certificates that did not contain an authority information access extension. If an organization adds an Online Responder to an existing public key infrastructure (PKI), this setting allows you to use Online Certificate Status Protocol (OCSP) responses for existing certificates, eliminating the need to reissue the certificates. When you add an OCSP download location for a root or intermediate CA certificate, that location will be used to retrieve the OCSP response for all certificates issued by that particular CA.

Note

The OCSP download locations added through the OCSP Properties tab are checked before any download locations that already exist in a certificate. If you need to add a placeholder URL, use the following address: http://localhost.

Additional references

  • Managing Online Responders


Set Up and Use a Smart Card Enrollment Station

A smart card enrollment station allows a designated employee or agent to issue smart cards from one centralized workstation or from one of any number of designated workstations. Designating enrollment stations and agents simplifies the physical preparation of the card to be issued, reduces the chance for certificate service interruption, and prevents users and managers from validating their own identification and issuing their own certificates, especially for organizations or environments in which different levels of security and access exist.

Prepare a smart card certificate enrollment station

Before requesting smart card logon certificates for users:

  • The enrollment agent and smart card logon or smart card user certificates must be configured and enabled for the certification authority (CA).

  • If desired, enrollment agent restrictions must be configured.

  • The enrollment agent has to be enrolled on behalf of other users for the enrollment agent certificate.

  • On the computer that you will use to set up smart cards, follow the manufacturer's instructions to install a smart card reader.

The following procedures explain how to enroll for smart card certificates on behalf of other users and how to prepare the enrollment station once the enrollment agent certificate is available. These procedures can be completed on any computer running Windows 7 or Windows Vista, or on a Windows Server 2008 R2 or Windows Server 2008 member server that you want to use as a smart card certificate enrollment station.

Membership in the Users group and an enrollment agent certificate are the minimum requirements to complete this procedure.

To enroll for a certificate on behalf of other users

  1. Open the Certificates snap-in for a user.

  2. To confirm that you are in Logical certificate stores view, right-click Certificates - Current User, point to View, click Options, verify that Logical certificate stores is selected, and then click OK.

  3. In the console tree, expand the Personal store, and then click Certificates.

  4. On the Action menu, point to All Tasks, click Advanced Operations, and then click Enroll on behalf of to open the Certificate Enrollment Wizard. Click Next.

  5. Browse to the enrollment agent certificate that you will use to sign the certificate request that you are processing. Click Next.

  6. Select the type of certificate that you want to enroll for. When you are ready to request a certificate, click Enroll.

  7. After the Certificate Enrollment Wizard has successfully finished, click Close.

To complete the following procedure, you must be logged on as a domain user with appropriate privileges to add snap-ins.

To prepare a smart card certificate enrollment station

  1. Click Start, click Run, type mmc, and then click OK.

  2. On the File menu, click Add/Remove Snap-in, and then click Add.

  3. In Snap-in, double-click Certificates.

  4. Click My user account, and then click Finish.

  5. Click Close, and then click OK.

  6. Double-click Certificates - Current User.

  7. In the console tree, click Personal.

  8. On the Action menu, point to All Tasks, and then click Request New Certificate.

  9. In the Certificate Enrollment Wizard, click the Enrollment Agent certificate template and provide the requested information.

  10. When prompted by the Certificate Enrollment Wizard, click Install Certificate.

Additional considerations

  • You can install the enrollment agent certificate on a smart card. To do this, you must use the smart card manufacturer's cryptographic service provider (CSP) when requesting the certificate. (In the Certificate Request Wizard, click Advanced Options to select a smart card CSP for the enrollment agent certificate.)

  • Once someone has an enrollment agent certificate, that person can enroll for a certificate and generate a smart card on behalf of anyone in the organization. The resulting smart card could then be used to log on to the network and impersonate the real user. Therefore, it is recommended that your organization maintain very strong security policies to restrict the use of enrollment agent certificates.

Additional references

  • To configure an enrollment agent certificate template for issuance from a CA, see Managing Certificate Templates (http://go.microsoft.com/fwlink/?LinkId=142230).

  • To configure a restricted enrollment agent, see Establish Restricted Enrollment Agents.


CA Certificates

Certification authority (CA) certificates are certificates that are issued by a CA to itself or to a second CA for the purpose of creating a defined relationship between the two CAs.

A certificate that is issued by a CA to itself is referred to as a trusted root certificate, because it is intended to establish a point of ultimate trust for a CA hierarchy.

Once the trusted root has been established, it can be used to authorize subordinate CAs to issue certificates on its behalf.

CA certificates can also be used to establish trust relationships between CAs in two different public key infrastructure (PKI) hierarchies.

In all of these cases, the CA certificate is critical to defining the certificate path and usage restrictions for all end-entity certificates issued for use in the PKI.

The appropriate configuration of CA certificates for the organization's needs is one of the most powerful tools that an organization has to implement appropriate PKI security. CA certificates contain special configuration data that regulate the CAs to which they are issued. These configuration options can:

  • Define the organizational namespace in which certificates issued by the subordinate CA can be issued and trusted.

  • Specify the acceptable uses of certificates issued by the subordinate CA.

  • Define the issuance guidelines that must be followed in order for a certificate issued by the subordinate CA to be considered valid.

  • Create a managed trust between separate certification hierarchies.