AD CS MMC Help
When using the Active Directory Certificate Services (AD CS) in the product, there are several references to find more information. This is the main landing page to guiding you to that additional information.
Active Server Pages and security
ASP has potential security risks because it supports the transfer of data over network.
Additional information
Array members (Online Responder)
When multiple Online Responders are used, they need to be organized into a logical framework called an Online Responder Array. Because Online Responders are designed to respond to individual certificate status requests, an Online Responder Array helps distribute status requests among multiple, geographically dispersed Online Responders (see Managing an Online Responder Array for more).
Additional information
- Implementing an OCSP Responder: Part V High Availability
- Online Responder Installation, Configuration, and Troubleshooting Guide
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.
The name you want to give to the CA. You can enter a string using any Unicode character. The name of the CA will also be the common name of the CA's distinguished name in Active Directory.
When special characters exist in the CA name, a sanitized CA name is used for operations that are unable to use the unmodified CA name. A CA's sanitized name is the name of the CA with all special characters encoded in a form that will allow them to be used for file names, CryptoAPI key container names, and Active Directory object names. Special characters are those characters that cannot be used in one or more of these names; the list includes all characters which are not ASCII characters and many ASCII punctuation characters.
Further, Active Directory object names are limited to 64 characters by the Lightweight Directory Access Protocol (LDAP) standard. To accommodate this limit, Active Directory object names are constructed by truncating the sanitized name and appending a hash computed over the truncated part of the sanitized name. The distinguished name suffix field is automatically filled with the distinguished name of the Active Directory domain. If you edit this distinguished name, you must conform with the LDAP standard.
Type certutil.exe at a command prompt without arguments to see the sanitized name for all of the published CAs. Type certutil.exe -v -ds to see all of the CA-related Active Directory names. The first column is a truncated CA name with the hash appended (the actual Active Directory object's container name, with special characters reverted back to their original form). A second column is displayed only if the truncated, sanitized name does not match the truncated CA name, and it is the actual Active Directory object's container name.
Additional information
- Certification Authority Naming
- Establishing a CA Naming Convention
- Installing and configuring a certification authority
Certificate template concepts
By default, Windows Server CAs are enabled upon installation to issue a variety of types of certificates. You can use the Certification Authority MMC snap-in to make the following modifications to this default configuration:
- Specify the certificate types that are to be issued by each CA
- Delete any default certificate templates that you do not want the CA to issue from the certificate templates container
- Add additional certificate templates that the CA can issue
You can configure CAs to support one or multiple security functions by:
- Configuring root or intermediate CAs to issue subordinate certification authority certificates only
- Configuring an issuing CA that supports secure Web communication services to issue authenticated session, computer, and Web server certificates only.
- Configuring an issuing CA that supports general business users to issue user certificates only, or configuring a CA that supports administrators to issue administrator certificates only.
- Configuring an issuing CA that supports smart card enrollment to issue smart card logon and smart card user certificates only.
The access control lists (ACLs) for each certificate template control the permissions needed to request certificate types. An enterprise CA grants certificate requests only for users, computers, or services that have the Enroll permission selected in the ACLs for that certificate template. The ACLs for certificate templates are preconfigured to enable various default user accounts and security groups to enroll for certificate types.
You can use the Certificate Templates MMC snap-in to modify the ACLs for each certificate template. For example, by default, only members of the Domain Administrators security group can request and obtain enrollment agent certificates. However, to specify that only certain members of your security department can request and obtain enrollment agent certificates, you can change the ACLs for the enrollment agent certificate template. You can remove domain admins from the ACL and add the appropriate user accounts or security groups.
Additional information
- Implementing and Administering Certificate Templates in Windows Server 2008
- AD CS: How to Obtain a List of Certificate Templates that are Superceding other Certificate Templates
- What is strong key protection in Windows?
Certificate template versions
Active Directory Certificate Services (AD CS) provides these versions of certificate templates that are available on enterprise certification authorities (CA).
Version 1 certificate templates
Version 1 certificate templates support general certificate needs and provide compatibility with clients and issuing CAs running Windows 2000 operating systems. Version 1 templates are installed by default during CA setup and cannot be deleted. The only property that can be modified on a version 1 template is the set of assigned permissions that controls access to the template.
Enrollment options
- Automatic enrollment
- Custom scripts
- Automatic certificate request settings in Group Policy can be used only for computer certificates
Manual enrollment
- Certificates snap-in
- CA Web enrollment pages
Template availability
- Windows Server 2008 R2, all editions
- Windows Server 2008, all editions
- Windows Server 2003 R2, all editions
- Windows Server 2003, all editions
- Windows 2000 Server, all editions
Version 2 certificate templates
Version 2 certificate templates were introduced in Windows Server 2003 and can be configured by an administrator to control the way certificates are requested, issued, and used. Version 2 templates provide support for certificate autoenrollment.
Enrollment options
- Automatic enrollment
- Autoenrollment in Windows Server 2008, Windows Vista, Windows Server 2003, and Windows XP Professional
- Custom scripts
Manual enrollment
- Certificate Enrollment Wizard
- CA Web enrollment pages
Template availability
- Windows Server 2008 R2, all editions
- Windows Server 2008, Enterprise and Datacenter editions
- Windows Server 2003 R2, Enterprise and Datacenter editions
- Windows Server 2003, Enterprise and Datacenter editions
Version 3 certificate templates
In addition to version 2 template features and autoenrollment, version 3 certificate templates provide support for Suite B cryptographic algorithms. Suite B was created by the U.S. National Security Agency to specify cryptographic algorithms that must be used by U.S. government agencies to secure confidential information.
Template availability
- Windows Server 2008 R2, all editions
- Windows Server 2008, Enterprise and Datacenter editions
Additional information
Creating object identifiers
Object identifiers are unique numeric values that are granted by various issuing authorities to identify data elements, syntaxes, and other parts of distributed applications. Because they are globally unique, object identifiers ensure that the objects that are defined by these issuing authorities do not conflict with one another when different directories, such as Active Directory and Novell Directory Services, are brought together in a global directory namespace. See Object Identifiers for more information.
Delegated enrollment agents
In releases of Windows Server prior to Windows Server 2008, enrollment agents were not limited in whom they could enroll on behalf of. In other words, once a user was given enrollment agent abilities, he was able to enroll on behalf of any other user in the forest. Of course, this meant that user could easily escalate his privilege by enrolling on behalf of an existing user and impersonating the user with the newly created certificate. In an attempt to thwart this threat, enrollment agent abilities were provided to only highly trusted individuals. While such an approach improved security, it also made deployment models less flexible, since only a small number of individuals possessed the ability to enroll on behalf of other users. As a result, large, geographically dispersed organization faced increased complexity when deploying certificates to end users (such as for smart cards).
Starting in Windows Server 2008, enrollment agents can be restricted on a much more granular level. Restrictions can be based on what users can be enrolled on behalf of, or by what templates can be enrolled against. For example, an organization may now provide a local IT professional with the ability to enroll on behalf of all the users at his branch, but not users in the Human Resources group. This granular approach to enrollment agents allows enterprises to more effectively and securely delegate enrollment capabilities throughout their organizations.
Delta CRL
CRLs can become very long on large CAs that have experienced significant amounts of certificate revocation. This can become a burden for clients to download frequently. To help minimize frequent downloads of lengthy CRLs, delta CRLs can be published. This allows the client to download the most current delta CRL and combine that with the most current base CRL to have a complete list of revoked certificates. Because the client will normally have the CRL cached locally, the use of delta CRLs can potentially improve performance.
To use delta CRLs, the client application must be aware of and explicitly use delta CRLs for revocation checking. If the client does not use delta CRLs, it will retrieve the CRL from the CA every time it refreshes its cache, regardless of whether a delta CRL exists or not. For this reason, you should verify that the intended applications use delta CRLs and configure the CA accordingly. If the clients do not support the use of delta CRLs, you should either not configure the CA to publish delta CRLs or configure it so CRLs and delta CRLs are published at the same interval. This would still allow future applications that support delta CRLs to use them, while providing current CRLs to all applications. Note that all applications that use CryptoAPI (starting with Windows XP and the Windows Server 2003 family) use delta CRLs.
Additional information
Configure CRL and Delta CRL Overlap Period
Enterprise PKI
The Enterprise PKI snap-in provides a view of the status of all certification authorities (CAs) in one or more public key infrastructures (PKIs) in your network. Having a view of multiple CAs and their current status enables administrators to manage CA hierarchies and troubleshoot possible CA errors more easily and effectively.
The Enterprise PKI snap-in is used to ensure that all of the following elements in a public key infrastructure (PKI) are functioning properly, available, and valid:
Certification authorities (CAs). A CA accepts a certificate request, verifies the requester's information according to the policy of the CA, and then uses its private key to sign the certificate. The CA then issues the certificate to the subject of the certificate for use as a security credential within a PKI. A CA is also responsible for revoking certificates and publishing a certificate revocation list (CRL).
CA certificates. A CA certificate is a certificate 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. CA certificates are critical to defining the certificate path and usage restrictions for all end-entity certificates issued for use in the PKI.
Authority information access locations. Authority information access locations are URLs that are added to a certificate in its authority information access extension. These URLs can be used by an application or service to retrieve the issuing CA certificate. These CA certificates are then used to validate the certificate signature and to build a path to a trusted certificate.
CRLs. CRLs are complete, digitally signed lists of unexpired certificates that have been revoked. This CRL is retrieved by clients who can then cache the CRL (based on the configured lifetime of the CRL) and use it to verify certificates presented for use.
CRL distribution points. CRL distribution points are locations, typically URLs, that are added to a certificate in its CRL distribution point extension. CRL distribution points can be used by an application or service to retrieve a CRL. CRL distribution points are contacted when an application or service must determine whether a certificate has been revoked before its validity period has expired.
The Certification Authority snap-in allows an administrator to monitor and manage these PKI elements for a single CA. However, separate instances of the snap-in need to be used to monitor and manage a PKI if more than one CA is involved. In addition, the Certification Authority snap-in cannot be used to integrate non-Microsoft CAs into the infrastructure and cannot be used to conveniently manage the authority information access locations and CRL distribution point stores. The Enterprise PKI snap-in, therefore, can be used to resolve these issues from a single snap-in.
The Enterprise PKI snap-in provides a view of the status of the certification authorities (CAs) and Online Responders in one or more PKIs. In addition, the Enterprise PKI snap-in can be used to verify the validity and accessibility of authority information access locations and certificate revocation list (CRL) distribution points.
For each CA selected, the Enterprise PKI snap-in indicates one of the CA health states listed in the following table.
| Indicator | CA State |
| Question mark | CA health state evaluation |
| Green indicator | CA has no problem |
| Yellow indicator | CA has one or more non-critical problems |
| Red indicator | CA has one or more critical problems |
| Red cross over CA icon | CA is offline |
If your environment includes one or more Online Responders, the Enterprise PKI snap-in can be used to monitor the status of these components. The indicators and health states in the following table apply to Online Responders.
| Indicator | Online Responder state |
| Question mark | Online Responder health state evaluation |
| Green indicator | Online Responder has no problems |
| Yellow indicator | Online Responder has one or more non-critical problems |
| Red indicator | Online Responder has one or more critical problems |
| Red cross over CA icon | Online Responder is offline |
The following status codes apply to CRL distribution points, delta CRL distribution points, and authority information access locations.
| Indicator | CRL distribution point or authority information access state |
| Question mark | Location health state evaluation |
| Green indicator | Data is available and has no problems |
| Yellow indicator | Data is available and has one or more non-critical problems |
| Red indicator | Data is available but has one or more critical problems |
| Red cross over CA icon | Data is not available |
For problems relating to the Online Responder, use the Online Responder snap-in to further diagnose and resolve the problem. For problems relating to CAs, CRL distribution points, and authority information access locations, use the Certification Authority snap-in to further diagnose and resolve the problem. In addition, check the Event log on the computers hosting the Active Directory Certificate Services (AD CS) role services for additional troubleshooting information that can help you identify and resolve any problems.
Exit Module
The exit module that is provided with a Windows Server 2008–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.
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.
Import a foreign certificate
By default, a CA does not allow certificates (or keys) to be imported on the CA that were issued by another CA. A CA must be enabled to accept certificates and keys into the database that were issued by a foreign CA. (An Exchange 5.5 KMS issuing version 1 certificates is also considered a foreign CA.)
To import a foreign CA
Run the following command in a command-prompt window on the CA.
certutil –setreg ca\KRAFlags +KRAF_ENABLEFOREIGN
net stop certsvc
net start certsvc
Note: When foreign certificates are being imported on a CA, the –f switch must be used with certutil to inform the CA that the keys and certificates will be foreign. The command line would be as follows: Certutil.exe –f –importKMS [name of import file]
For more information, see Key Archival and Recovery in Windows Server 2008.
Local CRLs and Online Responder performance
The Local CRL tab allows locally managing revoked certificates for a revocation configuration. When this option is used, the Online Responder manages a local list of revoked certificates in addition to the CA CRL and delta CRL. This feature is useful when the CA is not responding and cannot publish CRLs or when the Online Responder cannot retrieve the CRL. The local revocation information supersedes information in a CA-published CRL. For example, if a certificate is listed as revoked in the local CRL but is not listed in the CA-published CRL, the Online Responder will still issue a response in which the specified certificate is revoked.
To add a certificate to the Local revoked certificates list, you first need to select the Enable local CRL check box and then click Add. The Revoked Certificate Details dialog box requires the certificate's serial number, the revocation reason, and the effective date for the revocation.
For more information, see Managing Revocation Configurations.
Online Responder auditing
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, see Audit Online Responder Operations.
Rename a certificate template
The names of custom certificate templates can be changed by an administrator. The names of default certificate templates cannot be changed. Use the Change Names dialog box to change the template name and the template display name.
The template name is the common name attribute of the certificate template object in Active Directory Domain Services (AD DS), and only that template object is updated when the template name is changed. If the modified template was previously published to issuing certification authorities (CAs) or added to a superseded templates list, then those actions must be repeated to maintain the consistency of the public key infrastructure (PKI) environment.
To change a certificate template name
- On the CA, open the Certificate Templates snap-in.
- Click the certificate template you want to modify. On the Action menu, click Change Names. Note: When a default certificate is selected, Change Names is not displayed. The names of default certificate templates cannot be changed.
- Type a new name in the Template name box or the Template display name box, or both.
- Click OK to save changes.
Important: Changes to the template name may require the following additional procedures:
- If the modified template is superseded by another template, then update the superseding template by adding the modified template to the list of superseded templates. See Supersede Templates.
- If the modified template has been published to issuing CAs, then update the list of certificate templates on each issuing CA. See Add a Certificate Template to a Certification Authority.
Setup
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
Verifying that a revocation configuration is functioning properly
An Online Responder serves as an intermediary between clients that need to check certificate validity and a certification authority (CA) that issues certificates and certificate revocation lists (CRLs). To verify that the Online Responder service is functioning properly, you need to isolate the Online Responder and client from the CA and any CRL distribution points to confirm that revocation checking continues to take place and that revocation data is originating only from the Online Responder. The best way to confirm this scenario is to complete the following steps that involve the CA, the client, CRL distribution points, and the Online Responder:
- Issue new certificates.
- Revoke a certificate.
- Publish a CRL.
- Remove CRL distribution point extensions from the issuing CA.
- Confirm that client computers can still obtain revocation data.
To perform these procedures, you must be a member of local Administrators on the computer hosting the Online Responder and on the client computer, and you must have Manage CA permissions on the computer hosting the CA, or you must have been delegated the appropriate authority.
Issue new certificates
To issue new certificates:
On the computer hosting the CA, click Start, point to Administrative Tools, and then click Certification Authority.
Configure several certificate templates to autoenroll certificates for a computer running Windows Vista or Windows XP Professional.
When information about the new certificates has been published to Active Directory domain controllers, open a command prompt window on the client computer and enter the following command to start certificate autoenrollment: certutil -pulse.
Note: It can take up to eight hours for information about new certificates to be replicated to Active Directory domain controllers.
On the client computer, use the Certificates snap-in to confirm that the certificates have been issued to the user and to the computer, as appropriate. If they have not been issued, repeat step 2. You can also stop and restart the client computer to initiate certificate autoenrollment.
Revoke a certificate
To revoke a certificate:
- On the computer hosting the CA, click Start, point to Administrative Tools, and then click Certification Authority.
- In the console tree, click Issued Certificates, and then select 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.
Publish a CRL
To publish a CRL:
- On the computer hosting the CA, clickStart, point to Administrative Tools, and then click Certification Authority.
- In the console tree, click Revoked Certificates.
- On the Action menu, point to All Tasks, and then click Publish.
Remove all CRL distribution point extensions from the issuing CA
To remove all CRL distribution point extensions from the issuing CA:
- On the computer hosting the CA, click Start, point to Administrative Tools, and then click Certification Authority.
- Select the CA.
- On the Action menu, click Properties.
- On the Extensions tab, confirm that Select extension is set to CRL Distribution Point (CDP).
- Click any CRL distribution points that are listed, click Remove, and click OK.
- Stop and restart the CA.
- Configure a new certificate template, and complete autoenrollment again.
Confirm that client computers can obtain revocation data
To confirm that client computers can obtain revocation data:
Open the mmc.
If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.
On the File menu, click Add/Remove Snap-in, click Certificates, and then click Add.
Select the user or computer account to whom the certificate was issued, click Finish, and then click OK.
Open the Personal Certificates store, right-click the most recently issued certificate, point to All Tasks, and then click Export to start the Certificate Export Wizard. Export the certificate to a .cer file.
Open a command prompt window.
Type certutil -url<exportedcert.cer> and press ENTER.
Exportedcert.cer is the file name of the certificate that was exported in the previous step.
In the Verify and Retrieve dialog box that appears, click From CDP and From OCSP, and confirm that the revocation data is retrieved from the Online Responder and not from a CRL distribution point.
Web Proxy (Online Responder)
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.
For additional information, see Modify the Online Responder Web Proxy.
Additional PKI Resources
- Community directory for documentation and information:
- Support forum:
- Product team blog: Windows PKI Blog
- Support Team Blog:
- Script repository:
- TechNet Script Center Repository (http://gallery.technet.microsoft.com/scriptcenter) search for Certification, Certificate, or PKI
- Technology overview:
- Technology FAQ: