Certificate Templates

Certificate templates can greatly simplify the task of administering a certification authority (CA) by allowing an administrator to issue certificates that have been preconfigured for selected tasks. The Certificate Templates snap-in allows an administrator to perform the following tasks:

  • View properties for each certificate template.

  • Copy and modify certificate templates.

  • Control which users and computers can read templates and enroll for certificates.

  • Perform other administrative tasks relating to certificate templates.

Additional references

  • Certificate Template Concepts

  • Managing Certificate Templates

  • Troubleshooting Certificate Templates

  • Additional Resources for Certificate Templates


Certificate Template Concepts

Certificate templates are an integral part of an enterprise certification authority (CA). They are an important element of the certificate policy for an environment, which is the set of rules and formats for certificate enrollment, use, and management.

When a CA receives a request for a certificate, groups of rules and settings must be applied to that request to perform the requested function, such as certificate issuance or renewal. These rules can be simple or complex and may apply to all users or specific groups of users. Certificate templates are the sets of rules and settings that are configured on a CA to be applied against incoming certificate requests. Certificate templates also give instructions to the client on how to create and submit a valid certificate request.

Certificates based on a certificate template can only be issued by an enterprise CA. The templates are stored in Active Directory Domain Services (AD DS) for use by every CA in the forest. This allows the CA to always have access to the current standard template and ensures consistent application of the certificate policy across the forest.

Administrators of Windows Server 2008–based enterprise CAs can use a number of predefined certificate templates. For more information, see Default Certificate Templates.

Certificate templates introduced in Windows Server 2008, Windows Server 2003, and Windows 2000 have different levels of configurability. For more information, see Certificate Template Versions.


Default Certificate Templates

A number of preconfigured certificate templates that are designed to meet the needs of most organizations are included with Windows Server 2008–based enterprise certification authorities (CAs). These templates are described in the following table.

Name | Description | Key usage | Subject type | Published to Active Directory Domain Services (AD DS)? | Template version
Administrator | Allows trust list signing and user authentication. | Signature and encryption | User | Yes | 1
Authenticated Session | Allows the subject to authenticate to a Web server. | Signature | User | No | 1
Basic EFS | Used by Encrypting File System (EFS) to encrypt data. | Encryption | User | Yes | 1
CA Exchange | Used to store keys that are configured for private key archival. | Encryption | Computer | No | 2
CEP Encryption | Allows the certificate holder to act as a registration authority for Simple Certificate Enrollment Protocol (SCEP) requests. | Encryption | Computer | No | 1
Code Signing | Used to digitally sign software. | Signature | User | No | 1
Computer | Allows a computer to authenticate itself on the network. | Signature and encryption | Computer | No | 1
Cross-Certification Authority | Used for cross-certification and qualified subordination. | Signature | Cross-certified CA | Yes | 2
Directory E-mail Replication | Used to replicate e-mail within AD DS. | Signature and encryption | Computer | Yes | 2
Domain Controller | Used by domain controllers as all-purpose certificates. | Signature and encryption | Computer | Yes | 1
Domain Controller Authentication | Used to authenticate Active Directory computers and users. | Signature and encryption | Computer | No | 2
EFS Recovery Agent | Allows the subject to decrypt files that were previously encrypted with EFS. | Encryption | User | No | 1
Enrollment Agent | Used to request certificates on behalf of another subject. | Signature | User | No | 1
Enrollment Agent (Computer) | Used to request certificates on behalf of another computer subject. | Signature | Computer | No | 1
Exchange Enrollment Agent (Offline request) | Used to request certificates on behalf of another subject and supply the subject name in the request. | Signature | User | No | 1
Exchange Signature Only | Used by the Microsoft Exchange Key Management Service to issue certificates to Exchange users for digitally signing e-mail. | Signature | User | No | 1
Exchange User | Used by the Microsoft Exchange Key Management Service to issue certificates to Exchange users for encrypting e-mail. | Encryption | User | Yes | 1
IPSEC | Used by Internet Protocol security (IPsec) to digitally sign, encrypt, and decrypt network communication. | Signature and encryption | Computer | No | 1
IPSEC (Offline request) | Used by IPsec to digitally sign, encrypt, and decrypt network communication when the subject name is supplied in the request. | Signature and encryption | Computer | No | 1
Kerberos Authentication | Used to authenticate Active Directory computers and users. | Signature and encryption | Computer | No | 2
Key Recovery Agent | Recovers private keys that are archived on the CA. | Encryption | Key recovery agent | No | 2
OCSP Response Signing | Used by an Online Responder to sign responses to certificate status requests. | Signature | Computer | No | 3
RAS and IAS Server | Enables remote access servers and Internet Authentication Service (IAS) servers to authenticate their identity to other computers. | Signature and encryption | Computer | No | 2
Root Certification Authority | Used to prove the identity of the root CA. | Signature | CA | No | 1
Router (Offline request) | Used by a router when requested through a SCEP request from a CA that holds a CEP Encryption certificate. | Signature and encryption | Computer | No | 1
Smartcard Logon | Allows the holder to authenticate by using a smart card. | Signature and encryption | User | No | 1
Smartcard User | Allows the holder to authenticate and protect e-mail by using a smart card. | Signature and encryption | User | Yes | 1
Subordinate Certification Authority | Used to prove the identity of the root CA. It is issued by the parent or root CA. | Signature | CA | No | 1
Trust List Signing | Allows the holder to digitally sign a trust list. | Signature | User | No | 1
User | Used by users for e-mail, EFS, and client authentication. | Signature and encryption | User | Yes | 1
User Signature Only | Allows users to digitally sign data. | Signature | User | No | 1
Web Server | Proves the identity of a Web server. | Signature and encryption | Computer | No | 1
Workstation Authentication | Enables client computers to authenticate their identity to servers. | Signature and encryption | Computer | No | 2

When you duplicate a version 1 or version 2 certificate template, you can make the duplicate a version 2 or version 3 template in order to configure the advanced options available with the later versions. However, version 3 certificate templates can only be issued by Windows Server 2008–based enterprise CAs and used by clients on computers running Windows Server 2008 or Windows Vista. For more information, see Certificate Template Versions.

For information about configuration options for certificate templates, see Configuring a Certificate Template.

Additional references

  • Certificate Template Concepts


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 references

  • Certificate Template Concepts

  • Default Certificate Templates

  • Create a New Certificate Template

  • Set Up Automatic Certificate Enrollment


Managing Certificate Templates

The topics in this section describe how to complete the following basic certificate template management tasks.

  • Install the Certificate Templates Snap-In

  • Connect to a Writable Domain Controller

  • Upgrade Existing Templates

  • Create a New Certificate Template

  • Delete a Certificate Template

  • Rename a Certificate Template

  • Configuring a Certificate Template

  • Configuring a Certificate Template

  • Issuing Certificates Based on Certificate Templates


Install the Certificate Templates Snap-In

The Certificate Templates snap-in allows you to view and manage critical information about all the certificate templates in a domain.

Important fields in the Certificate Templates snap-in include:

  • Template Display Name. This field describes the purpose of the certificate. When an organization creates a custom certificate template, it may be useful to use a naming convention that helps administrators identify the certification authority (CA) or portion of the organization associated with the template.

  • Minimum Supported CAs. The configurable options in Windows-based certificate templates differ based on the operating system version. Therefore, not all certificate templates are supported by all Windows Server–based CAs.

  • Version. If certificate template configurations evolve over time, the ability to track version information becomes important for compatibility and support.

You must be a local administrator to install the Certificate Templates snap-in and a member of Domain Admins to use the Certificate Templates snap-in. For more information, see Implement Role-Based Administration.

To install the Certificate Templates snap-in

  1. Click Start, click Run, and then type mmc.

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

  3. On the Add and Remove Snap-ins dialog box, double-click the Certificate Templates snap-in to add it to the list. Click OK.

By default, the Certificate Templates snap-in is installed automatically when a CA is installed on a server. The Certificate Templates snap-in can be installed on a different server by using Server Manager to install Active Directory Certificate Services (AD CS) tools.

You must be local administrator to install Remote Server Administration Tools. You must be a member of Domain Admins to access and administer certificate templates for a domain. For more information, see Implement Role-Based Administration.

To administer certificate templates from a remote server

  1. 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 Certificate Templates snap-in, click Add, verify that the domain controller hosting the certificate templates you want to manage is selected, and then click OK.

You can use the Certificate Templates snap-in to manage certificate templates in a different domain.

You must be a domain or enterprise administrator for the other domain to complete this procedure. For more information, see Implement Role-Based Administration.

To manage certificate templates in a different domain

  1. Right-click the Certificate Templates snap-in, and click Connect to another writable domain controller.

  2. To type the name of a different domain, click Change. To select a different domain controller for the existing domain, click Select a Writable Domain Controller.

  3. If you have previously selected an alternate domain controller, you can revert to the original domain controller by clicking Default Writable Domain Controller.

Additional references

  • Managing Certificate Templates


Connect to a Writable Domain Controller

If you have multiple domain controllers, all certificate templates may not be replicated on all domain controllers, including read-only domain controllers.

Note

Read-only domain controllers, introduced in Windows Server 2008, are domain controllers that host a read-only copy of the domain database.

You can, however, retrieve or modify certificate templates from a specific writable domain controller.

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

To access certificate templates on a writable domain controller

  1. Open the Certificate Templates snap-in.

  2. In the console tree, right-click Certificate Templates, and then click Connect to another writable domain controller.

  3. Verify the domain name, and click OK.

Additional references

  • Managing Certificate Templates

  • Configure Certificate Publishing in Active Directory Domain Services


Upgrade Existing Templates

When you upgrade a certification authority (CA), you may need to update the Active Directory schema to support new certificate template attributes. For more information about updating the Active Directory schema with Adprep.exe, see the Command Line Reference (http://go.microsoft.com/fwlink/?LinkID=20331).

In addition, you need to upgrade the certificate templates to include and configure these attributes. Upgrading the certificate templates applies the proper security permissions on the existing certificate templates and installs any new certificate templates that are available.

If you do not perform this procedure before upgrading your CAs to Windows Server 2008 R2, you will be prompted when opening the Certificate Templates snap-in. If this procedure has already been performed in your enterprise, you will not receive a prompt when you open Certificate Templates.

Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure.

To install new templates and upgrade existing templates

  1. Open the Certificate Templates snap-in.

  2. When prompted to install new certificate templates, click OK.

Additional considerations

  • After a CA has been upgraded and certificate templates have been installed, you can create new version 2 or version 3 copies of any certificate template in the domain. For more information, see Create a New Certificate Template.

Additional references

  • Managing Certificate Templates


Create a New Certificate Template

You can create a new certificate template by duplicating an existing template and using the existing template's properties as the default for the new template. Different applications and types of certification authorities (CAs) support different certificate templates. For example, some certificate templates can only be issued and managed by enterprise CAs running Windows Server 2003, and some may require that the CA be running Windows Server 2008. Review the list of default certificate templates, and examine their properties to identify the existing certificate template that most closely meets your needs. This will minimize the amount of configuration work that you need to do.

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

To create a new certificate template

  1. Open the Certificate Templates snap-in.

  2. Right-click the template to copy from, and then click Duplicate Template.

  3. Choose the minimum version of CA that you want to support.

  4. Type a new name for this certificate template.

  5. Make any necessary changes, and click OK.

Additional references

  • Managing Certificate Templates

  • Default Certificate Templates


Delete a Certificate Template

You can delete a certificate template when you no longer want it to be available for use. When you delete a certificate template, certificates based on the template can no longer be issued. If you are using enterprise certification authorities (CAs), this will affect all CAs in a forest. Certificate templates cannot be recovered once they are deleted.

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 delete a certificate template

  1. Open the Certificate Templates snap-in.

  2. Right-click the template you want to delete, and then click Delete.

  3. Click Yes to confirm that you want to delete the template.

Additional references

  • Managing Certificate Templates


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

  1. On the CA, open the Certificate Templates snap-in.

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

  3. Type a new name in the Template name box or the Template display name box, or both.

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

Additional references

  • Default Certificate Templates


Configuring a Certificate Template

When you create a new certificate template, it is also possible to customize its general properties, extensions, and other important characteristics.

  • Managing Certificate Templates

  • Certificate Template General Properties

  • Certificate Template Extensions

  • Request Handling

  • Cryptography

  • Supersede Templates

  • Subject Names

  • Certificate Template Server


Certificate Template General Properties

The General tab contains validity and renewal information for certificates that will be issued based on a certificate template.

The default validity and renewal period settings for certificates issued by Active Directory Certificate Services (AD CS) are designed to meet most security needs. However, you might want to specify different validity and renewal settings, such as shorter lifetime or renewal periods for certificates that are used by certain user groups.

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 modify the validity or renewal period for a certificate template

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

  3. On the General tab, check the current validity period and renewal period values, modify them as needed, and then click Apply.

The Publish certificate in Active Directory option determines whether information about the certificate template will be made available throughout the enterprise.

The Do not automatically re-enroll if a duplicate certificate exists in Active Directory option is applied when the subject attempts to enroll for a certificate based on this template from a computer running Windows XP or later. With this option, certificate autoenrollment will not submit a re-enrollment request if a duplicate certificate exists in Active Directory Domain Services (AD DS). This allows certificates to be renewed but prevents multiple duplicate certificates from being issued.

The Smart card certificate keys option enables the existing key to be used if a new key cannot be created during renewal of a smart card certificate. This option helps prevent smart card certificate renewal failures that could result when a smart card runs out of disk space.

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 certificate publishing in AD DS

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

  3. On the General tab, select the appropriate Active Directory setting, and then click Apply.

Additional references

  • Configuring a Certificate Template


Certificate Template Extensions

A certification authority (CA) processes each certificate request by using a defined set of rules. Certificate templates can be customized with a number of extensions that regulate their use. These extensions can include:

  • Issuance policies. An issuance policy (also known as an enrollment or certificate policy) is a group of administrative rules that are implemented when issuing certificates. They are represented in a certificate by an object identifier (also known as an OID) that is defined at the CA. This object identifier is included in the issued certificate. When a subject presents its certificate, it can be examined by the target to verify the issuance policy and determine if that level of issuance policy is sufficient to perform the requested action. For more information, see Issuance Requirements.

  • Application policies. Application policies give you the important ability to decide which certificates can be used for certain purposes. This allows you to issue certificates widely without being concerned that they are misused for an unintended purpose. Application policies are sometimes called extended key usage or enhanced key usage. Because some implementations of public key infrastructure (PKI) applications cannot interpret application policies, both application policies and enhanced key usage sections appear in certificates issued by a Windows Server–based CA. For more information, see Application Policy.

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

  • Key archival. When subjects lose their private keys, any information that was persistently encrypted with the corresponding public key is inaccessible. To help prevent this, key archival allows you to encrypt and archive a subject's keys in the CA database when certificates are issued. If a subject loses its keys, the information can be retrieved from the database and provided to the subject. This allows the encrypted information to be recovered instead of lost. For more information, see Request Handling.

  • Basic constraints. Basic constraints are used to ensure that CA certificates are only used in certain applications. An example is the path length that can be specified as a basic constraint. A path length defines the number of CAs that are permitted below the current CA. This path length constraint ensures that CAs at the end of this path can only issue end-entity certificates, not CA certificates. For more information, see Basic Constraints.

  • OCSP No Revocation Checking. This extension appears only in the new OCSP Response Signing certificate template and duplicates derived from this template. It cannot be added to any other certificate templates. This extension instructs the CA to include the OCSP No Revocation Checking (id-pkix-ocsp-nocheck) extension in the issued certificate and not to include the authority information access and certificate revocation list (CRL) distribution point extensions in the certificate. This is because OCSP Response Signing certificates are not checked for revocation status. This extension only applies if the certificate request contains OCSP Response Signing in the enhanced key usage and application policies.

Additional references

  • Configuring a Certificate Template

  • Issuance Requirements

  • Application Policy

  • Key Usage

  • Basic Constraints

  • Make Issuance or Application Policy Critical


Issuance Requirements

A certification authority (CA) processes each certificate request by using a defined set of rules. The CA may issue some certificates with no proof of identification and require proof of identification before other types of certificates are issued. This provides different levels of assurance for different certificates. These levels of assurance are represented in certificates as issuance policies.

An issuance policy (also known as an enrollment or certificate policy) is a group of administrative rules that are implemented when issuing certificates. They are represented in a certificate by an object identifier (also known as an OID) that is defined at the CA. This object identifier is included in the issued certificate. When a subject presents its certificate, it can be examined by the target to verify the issuance policy, and determine if that level of issuance policy is sufficient to perform the requested action.

Windows Server 2008 R2, Windows Server 2008, and Windows Server 2003 include four predefined issuance policies:

  • All Issuance (2.5.29.32.0). The all issuance policy indicates that the issuance policy contains all other issuance policies. Typically, this object identifier is only assigned to CA certificates.

  • Low Assurance (1.3.6.1.4.1.311.21.8.x.y.z.1.400). The low assurance object identifier is used to represent certificates that are issued with no additional security requirements.

    Note

    The x.y.z portion of the object identifier is a randomly generated numeric sequence that is unique for each Active Directory forest.

  • Medium Assurance (1.3.6.1.4.1.311.21.8.x.y.z.1.401). The medium assurance object identifier is used to represent certificates that have additional security requirements for issuance. For example, a smart card certificate that is issued in a face-to-face meeting with a smart card issuer might be considered a medium assurance certificate and contain the medium assurance object identifier.

  • High Assurance (1.3.6.1.4.1.311.21.8.x.y.z.1.402). The high assurance object identifier is used to represent certificates that are issued with the highest security. For example, the issuance of a key recovery agent certificate might require additional background checks and a digital signature from a designated approver because a person holding this certificate can recover private key material from an enterprise CA.

In addition, you can create your own object identifiers to represent custom issuance policies.

When subjects submit certificate requests to a CA, the request can either be automatically approved or placed into a "pending" state. A pending state is normally used for certificates that require a higher level of assurance and consequently require more administration and further verification of the request. There are a number of settings that can configure the authentication and signature requirements for issuance certificates that are based on a template.

Setting | Description
CA certificate manager approval | All certificates are placed into the pending container for a certificate manager to issue or deny.
This number of authorized signatures | This setting requires the certificate request to be digitally signed by one or more subjects before it can be issued. This enables several other configuration parameters.
Policy type required in signature | The signatures that are required for issuing a certificate must contain either a specific application policy, issuance policy, or both. This is how the CA determines whether the signature is appropriate for authorizing the issuance of the subject's certificate. This option is enabled when This number of authorized signatures is set.
Application policy | Specifies the application policy to verify when signing a certificate request. This option is enabled when Policy type required in signature is set to either Application policy or Both application and issuance policy.
Issuance policy | Specifies the issuance policies to verify when signing a certificate request. This option is enabled when Policy type required in signature is set to either Issuance policy or Both application and issuance policy.

The ability to modify or create new application policies is available only with version 2 and version 3 certificate templates. For more information, see Default Certificate Templates.

Clients must be re-enrolled to receive a certificate based on a modified template if they already have a valid certificate based on the previous template. For more information about re-enrolling clients, see Re-Enroll All Certificate Holders.

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 modify an issuance policy

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

  3. Click the Issuance Requirements tab.

  4. Provide the requested information.

Additional references

  • Certificate Template Extensions

  • Make Issuance or Application Policy Critical


Application Policy

Application policies give you the important ability to decide which certificates can be used for certain purposes. This allows you to issue certificates widely without being concerned that they are used for an unintended purpose.

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

Application policies are sometimes called extended key usage or enhanced key usage. Because some implementations of public key infrastructure (PKI) applications cannot interpret application policies, both application policies and enhanced key usage sections appear in certificates issued by a Windows Server–based certification authority (CA). The following table lists some commonly used application policies.

Purpose | Object Identifier
Client Authentication | 1.3.6.1.5.5.7.3.2
CA Encryption Certificate | 1.3.6.1.4.1.311.21.5
Smart Card Logon | 1.3.6.1.4.1.311.20.2.2
Document Signing | 1.3.6.1.4.1.311.10.3.12
File Recovery | 1.3.6.1.4.1.311.10.3.4.1
Key Recovery | 1.3.6.1.4.1.311.10.3.11
Microsoft Trust List Signing | 1.3.6.1.4.1.311.10.3.1
Qualified Subordination | 1.3.6.1.4.1.311.10.3.10
Root List Signer | 1.3.6.1.4.1.311.10.3.9

The ability to modify or create new application policies is only available with version 2 and version 3 certificate templates. For more information, see Default Certificate Templates.

Clients must be re-enrolled to receive a certificate based on a modified template if they already have a valid certificate based on the previous template. For more information about re-enrolling clients, see Re-Enroll All Certificate Holders.

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 add an application policy

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

  3. On the Extensions tab, click Application Policies, and then click Edit.

  4. In Edit Application Policies Extension, click Add.

  5. In Add Application Policy, click the application policy that you want to add, and then click OK.

The application policy that you want may not be available. In this case, you can create a new application policy.

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 create an application policy

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

  3. On the Extensions tab, click Application Policies, and then click Edit.

  4. In Edit Application Policies Extension, click Add.

  5. In Add Application Policy, click New.

  6. Provide the requested information.

Additional references

  • Certificate Template Extensions

  • Make Issuance or Application Policy Critical


Key Usage

A certificate enables the subject to perform a specific task. To help control the usage of a certificate outside its intended purpose, restrictions are automatically placed on certificates. These restrictions can be applied by using the key usage extension.

Key usage is a restriction method that determines what a certificate can be used for. This allows the administrator to issue certificates that can only be used for specific tasks or certificates that be used for a broad range of functions. Key usage descriptions include "Digital signature" and "Allow key exchange only with key encryption."

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

To modify key usage

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

  3. On the Extensions tab, click Key Usage, and then click Edit.

  4. Select the key usage options that you want to add or remove, and then click OK twice.

    Note

    Not all key usage options can be modified on all certificate templates.

Certificate usage can also be managed by using the application policy extension. For more information, see Application Policy.

Additional references

  • Certificate Template Extensions


Basic Constraints

Certification authorities (CAs) must have a certificate before they can issue certificates. They use the private key associated with this certificate to digitally sign issued certificates. When a CA obtains a certificate from another CA, the parent CA may want to control whether that certificate can be used to issue certificates to other certificate servers. This is a basic constraint.

Basic constraints are used to ensure that a certificate is only used in certain applications. An example is the path length that can be specified as a basic constraint.

The following procedure only works with certificate templates that issue certificates that sign other certificates, such as cross-certified CAs and root CAs.

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 change basic constraints

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

  3. On the Extensions tab, click Basic Constraints, and then click Edit.

  4. In Edit Basic Constraints Extension, provide the requested information.

Additional considerations

  • This procedure is applicable to version 2 and version 3 templates. For more information, see Certificate Template Versions.

Additional references

  • Certificate Template Extensions


Make Issuance or Application Policy Critical

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

Issuance or application policies by default are not critical. Making them critical can help ensure that a certificate is not used improperly. However, it also increases the likelihood that the certificate may not be compatible with all applications.

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 make issuance or application policy critical

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

  3. On the Extensions tab, click Issuance Policies or Application Policies, and then click Edit.

  4. Select the Make this extension critical check box.

  5. Click OK.

Additional considerations

  • Clients must be re-enrolled to receive a certificate based on the changed template if they already have a valid certificate based on the old template. For more information, see Re-Enroll All Certificate Holders.

Additional references

  • Certificate Template Extensions

  • Object Identifiers

  • Issuance Requirements

  • Application Policy


Request Handling

The Request Handling tab defines the purpose of a certificate template, the supported cryptographic service providers (CSPs), minimum key length, exportability, autoenrollment settings, and whether strong private key protection should be required.

Certificate purpose

The certificate purpose defines the intended primary use of the certificate and can be one of four settings as described in the following table.

Setting | Purpose
Encryption | Contains cryptographic keys for encryption and decryption.
Signature | Contains cryptographic keys for signing data only.
Signature and encryption | Covers all primary uses of a certificate's cryptographic key, including encryption of data, decryption of data, initial logon, or digitally signing data.
Signature and smart card logon | Allows for initial logon with a smart card, and to digitally sign data; it cannot be used for data encryption.

Note

Key archival is only possible if the certificate purpose is set to Encryption or Signature and encryption.

Archive settings

Certification authorities (CAs) can archive a subject's keys in their databases when certificates are issued. If subjects lose their keys, the information can be retrieved from the database and securely provided to the subjects.

The key archival settings in the following table are defined in the Request Handling tab.

Setting | Purpose
Archive subject's encryption private key | If the issuing CA is configured for key archival, the subject's private key will be archived.
Allow private key to be exported | The subject's private key can be exported to a file for backup or transfer to another computer.
Deleting revoked or expired certificates (do not archive) | If a certificate is renewed due to expiration or revocation, the previously issued certificate is removed from the subject's certificate store. By default, this option is not enabled and the certificate is archived.
Include symmetric algorithms allowed by the subject | When the subject requests the certificate, a list of supported symmetric algorithms can be supplied by the subject. This option allows the issuing CA to include those algorithms in the certificate, even if they are not recognized or supported by that server.

User input settings

The Request Handling tab also allows several user input settings described in this table to be defined for a certificate template.

Setting | Purpose
Enroll subject without requiring any user input | This option allows autoenrollment without any user interaction and is the default setting for both computer and user certificates.
Prompt the user during enrollment | By disabling this option, users do not have to provide any input for the installation of a certificate based on the certificate template.
Prompt the user during enrollment and require user input when the private key is used | This option enables the user to set a strong private key protection password on the user's private key when the key is generated and requires the user to use it whenever the certificate and private key are used.

Other version 3 request handling settings

The Request Handling tab for version 3 certificate templates has been updated to provide support for the new options available on the Cryptography tab, along with other changes. The options are listed in the following table.

Setting Purpose

Use advanced Symmetric algorithm to send the key to the CA

This option allows the administrator to choose the Advanced Encryption Standard (AES) algorithm to encrypt private keys while they are transferred to the CA for key archival. If this option is selected, the client will use AES-256 symmetric encryption (along with the CA's exchange certificate for asymmetric encryption) to send the private key to the CA for archival. If this option is not selected, the 3DES symmetric algorithm is used. Because key archival is intended for encryption keys (not signing keys), this option is enabled only when the certificate purpose is set to Encryption.

Authorize additional service accounts to access the private key

This option allows a custom access control list (ACL) to be defined on the private keys of computer certificates based on any version 3 computer certificate template except the root CA, subordinate CA, or cross-CA templates. A custom ACL is necessary only when a service account that requires access to the private key is not included in the default permissions. The default permissions applied to the private key by the Microsoft certificate enrollment client and software key storage provider include Full Control permission for the Administrators group and the Local System account. Non-Microsoft providers may apply different default permissions and may not support custom ACLs defined by using this option. Refer to your provider's documentation for more information.

Note

This option has replaced the Add Read permissions to Network Service on the private key option. In Windows Server 2008 R2, the default permissions applied to the private key of OCSP Response Signing certificates include Read permission for Online Responder service account and Full Control permission for the Administrators group and the Local System account.

For more information about options associated with version 3 certificate templates, see Cryptography.

Other version 2 request handling settings

In addition to key archival settings, you can define general options that affect all certificates based on version 2 certificate templates. The options are listed in the following table.

Setting | Purpose
Minimum key size | This specifies the minimum size, in bits, of the key that will be generated for this certificate.
Cryptographic service providers | This is a list of cryptographic service providers (CSPs) that will be used to enroll certificates for the given template. Selecting one or more CSPs configures the certificate to only work with those CSPs. The CSP must be installed on the client computer for the CSP to be used during enrollment. If a specific CSP is chosen and not available on a client computer, enrollment will fail.

Additional references

  • Configuring a Certificate Template


Cryptography

The Cryptography tab is available for version 3 certificate templates. This tab replaces the cryptographic service provider (CSP) selection dialog box used to select CSPs for version 2 certificate templates. The Cryptography tab is used to configure the following properties:

  • Algorithm name. Select an algorithm that the issued certificate's key pair will support. The list displays only algorithms that support the cryptographic operations required for the certificate purpose that is selected on the Request Handling tab. The following table describes the relationship between the certificate purpose and the available algorithms.

    Purpose Algorithms

    Encryption

    ECDH_P256
    ECDH_P384
    ECDH_P521
    RSA

    Signature

    DSA
    ECDSA_P256
    ECDSA_P384
    ECDSA_P521
    RSA

    Signature and encryption

    ECDH_P256
    ECDH_P384
    ECDH_P521
    RSA

    Signature and smart card logon

    ECDH_P256
    ECDH_P384
    ECDH_P521
    RSA

  • Minimum key size. This option allows you to specify a minimum required size for the keys used with the chosen algorithm. By default, the minimum key length supported on the computer for the chosen algorithm will be used.

  • Providers. Version 2 templates offer a list of CryptoAPI CSPs, while version 3 templates offer a dynamically populated list of Cryptography Next Generation (CNG) providers. This list is populated with all providers available on the computer that meet the criteria specified by a combination of the following configuration options: Algorithm name and Minimum key size on the Cryptography tab, and Purpose and Allow private key to be exported on the Request Handling tab.

  • Hash algorithm. This option allows you to choose an advanced hash algorithm. By default, the following algorithms are available: AES-GMAC, MD2, MD4, MD5, SHA1, SHA256, SHA384, and SHA512.

  • Use alternate signature format. When the RSA algorithm is selected, this check box allows you to specify that certificate requests created for this template include a discrete signature in PKCS #1 V2.1 format.

    Note

    This setting applies to the certificate request only, not the certificate that is issued by the CA from this template.

Additional references

  • Configuring a Certificate Template

  • Request Handling


Supersede Templates

There may be times when you want to modify the properties of a type of certificate that has already been issued to clients. You can do this by creating an updated certificate template for that certificate purpose and specifying that you want subjects of certificates based on the old template to obtain new certificates based on the new template. This procedure forces subjects to obtain a new certificate before the renewal date specified in the original certificate template.

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

To supersede templates

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

  3. Click the Superseded Templates tab.

  4. Click Add.

  5. Click one or more templates to supersede, and then click OK.

  6. Make any other changes to the template that you want to include, and click OK.

Additional references

  • Configuring a Certificate Template


Subject Names

The holder of the private key associated with a certificate is known as the subject. This can be a user, a program, or virtually any object, computer, or service.

Because the subject name can vary greatly depending on who or what the subject is, some flexibility is needed when providing the subject name in the certificate request. Windows can build the subject name automatically from subject information stored in Active Directory Domain Services (AD DS) or the subject name can be supplied manually by the subject (for example, by using certificate enrollment Web pages to create and submit a certificate request).

Enterprise certification authorities (CAs) include the Certificate Templates snap-in to configure certificate templates. Use the Subject Name tab on the certificate template properties sheet to configure subject name options.

Supply in the request

When the Supply in the request option is selected, the Use subject information from existing certificates for autoenrollment renewal requests option is available to simplify the task of adding the subject name to the certificate renewal request and to allow computer certificates to be renewed automatically. Subject information from existing certificates is not used for automatic renewal of user certificates.

The Use subject information from existing certificates for autoenrollment renewal requests option causes the certificate enrollment client to read subject name and subject alternative name information from an existing computer certificate based on the same certificate template when creating renewal requests automatically or using the Certificates snap-in. This applies to computer certificates that are expired, revoked, or within their renewal period.

Build from AD DS

When the Build from this Active Directory information option is selected, the following additional options can be configured.

Subject name format

Setting | Description
Common name | The CA creates the subject name from the common name (CN) obtained from AD DS. This should be unique within a domain but might not be unique within an enterprise.
Fully distinguished name (DN) | The CA creates the subject name from the fully distinguished name obtained from AD DS. This ensures that the name is unique within an enterprise.
Include e-mail name in subject name | If the E-mail name field is populated in the Active Directory user object, this e-mail name will be included with either the common name or fully distinguished name as part of the subject name.
None | A name value is not required for this certificate.

Include this information in alternate subject name

Setting | Description
E-mail name | If the E-mail name field is populated in the Active Directory user object, this e-mail name will be used.
DNS name | This is the fully qualified domain name (FQDN) of the subject that requested the certificate. This is most frequently used in computer certificates.
User principal name (UPN) | The user principal name is part of the Active Directory user object and will be used.
Service principal name (SPN) | The service principal name is part of the Active Directory computer object and will be used.


Certificate Template Server

High-volume certificate issuance scenarios such as Network Access Protection (NAP) deployments with Internet Protocol security (IPsec) enforcement create unique public key infrastructure (PKI) needs. To address these needs, the following options introduced in Windows Server 2008 R2 can be used to configure certificate templates for use by high-volume certification authorities (CAs). These options are available on the Server tab of a certificate template's property sheet.

Do not store certificates and requests in the CA database

Certificates issued in high-volume scenarios typically expire within hours of being issued, and the issuing CA processes a high volume of certificate requests. By default, a record of each request and issued certificate is stored in the CA database. A high volume of requests increases the CA database growth rate and administration cost.

The Do not store certificates and requests in the CA database option configures the template so that the CA processes certificate requests without adding records to the CA database.

Important

The issuing CA must be configured to support certificate requests that have this option enabled. On the issuing CA, run the following command: CertUtil.exe –SetReg DBFlags +DBFLAGS_ENABLEVOLATILEREQUESTS.

Do not include revocation information in issued certificates

Revocation of certificates by some high-volume CAs is not beneficial because the certificates typically expire within hours of being issued.

The Do not include revocation information in issued certificates option configures the template so that the CA excludes revocation information from issued certificates. This prevents checking revocation status during certificate validation and reduces validation time.

Note

This option is recommended whenever the Do not store certificates and requests in the CA database option is used.

Additional references

  • Configuring a Certificate Template


Deploying Certificate Templates

When you create an enterprise certification authority (CA), certificate templates are stored in Active Directory Domain Services (AD DS) and can be made available to all enterprise CAs in the forest. This simplifies replication, security management, and the upgrade of certificate templates when a CA is upgraded to a more recent version of a Windows server operating system. Note that this requires the root domain's Domain Admins group to have Full Control permission on all certificate templates or for this permission to be granted to another user or group.

Once you have planned and created the appropriate certificate templates, they will be replicated automatically to all domain controllers in the enterprise. This replication normally takes approximately eight hours to complete. Because of this interval, you should create the certificate template and allow it to replicate before issuing certificates based on the certificate template to clients. This is best accomplished during an idle time in your environment. Configuring templates and using certificates before replication is completed can have unwanted effects.

  • Managing Certificate Templates

  • Add a Certificate Template to a Certification Authority

  • Remove a Certificate Template from a Certification Authority


Add a Certificate Template to a Certification Authority

Before certificates can be issued by a certification authority (CA), the certificate template must be added to a CA.

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 add a certificate template to a CA

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

  2. Right-click Certificate Templates, click New, and then click Certificate Template to Issue.

  3. Select the certificate template, and click OK.

Additional references

  • Deploying Certificate Templates


Remove a Certificate Template from a Certification Authority

At times it may be necessary to remove a certificate template from a certification authority (CA), such as to avoid confusion when a newer version of the certificate template is being added.

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 remove a certificate template from a CA

  1. Open the Certification Authority snap-in.

  2. In the console tree, click Certificate Templates.

  3. In the details pane, right-click the certificate template that you want to delete, and then click Delete.

Additional references

  • Deploying Certificate Templates


Issuing Certificates Based on Certificate Templates

Active Directory Certificate Services (AD CS) supports a variety of enrollment and renewal methods, including autoenrollment without any client interaction and interactive enrollment methods such as the Certificate Request Wizard and the AD CS Web pages.

Note

If you deploy non-Microsoft certification authorities (CAs) or custom certificate enrollment and renewal applications, you must perform any configuration required for those CAs and applications.

How a client obtains a certificate is primarily controlled by the security properties of the certificate template.

When certificate templates are published on a server, each template contains an access control list (ACL) that defines the specific operations a subject can perform with a certificate.

Setting Description

Full Control

The selected group or user can perform any action on this template.

Read

The selected group or user can read this template.

Write

The selected group or user can modify this template.

Enroll

The selected group or user can submit a certificate issuance or renewal request based on this template.

Note

To automatically retrieve OCSP Response Signing certificates, Online Responder service accounts require Enroll permission, not Autoenroll permission.

Autoenroll

The selected group or user can submit a certificate request based on this template by way of autoenrollment.

Note

Autoenroll permission does not include Enroll permission. To use Autoenroll permission, grant both permissions.

The most common use of certificates is for subject enrollment with autoenrollment permitted. In this case, the subject must be granted Read, Enroll, and Autoenroll permissions.

If you do not want to autoenroll users, but do want to make manual or Web-based enrollment available, granting the Read and Enroll permissions is appropriate.

When subjects already hold a certificate, they need only Read and Enroll permissions to renew that certificate, whether they use autoenrollment or not.

Write and Full Control permissions should be restricted to CA managers to ensure the templates are not improperly configured.

  • Managing Certificate Templates

  • Set Up Automatic Certificate Enrollment

  • Allow Subjects to Request a Certificate Based on a Template

  • Re-Enroll All Certificate Holders

  • Modify an Issuance Policy

  • Configure Certificate Publishing in Active Directory Domain Services


Set Up Automatic Certificate Enrollment

Autoenrollment is a useful feature of Active Directory Certificate Services (AD CS). It allows the administrator to configure subjects to automatically enroll for certificates, retrieve issued certificates, and renew expiring certificates without requiring subject interaction. The subject does not need to be aware of any certificate operations, unless you configure the certificate template to interact with the subject.

To properly configure subject autoenrollment, the administrator must plan the appropriate certificate template or templates to use. Several settings in the certificate template directly affect the behavior of subject autoenrollment. For more information on these settings, see:

  • Issuance Requirements

  • Application Policy

  • Key Usage

  • Supersede Templates

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

To set up automatic certificate enrollment

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

  3. Click the various Properties tabs, including General, Request Handling, and Issuance Requirements, and modify them if necessary.

  4. On the Security tab, select a group or user name. Select the Allow check box next to Autoenroll, and then click Apply.

Additional references

  • Issuing Certificates Based on Certificate Templates


Allow Subjects to Request a Certificate Based on a Template

Users can obtain certificates as needed by using the Certificate Request Wizard to request a certificate based on a certificate template. Before they can do this, you must enable the certificate template for these operations.

To properly configure subject enrollment, the administrator must plan the appropriate certificate template or templates to use. Several settings in the certificate template directly affect the behavior of certificate enrollment. For more information on these settings, see:

  • Issuance Requirements

  • Application Policy

  • Key Usage

  • Supersede Templates

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 allow subjects to request a certificate that is based on a template

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

  3. On the Security tab, add the groups, computers, or users from which you want to allow certificate requests.

  4. In Group or user names, click one of the new objects, and then, on Permissions for ObjectName, under the Allow column, select the Read and Enroll check boxes.

  5. Repeat the previous step for each new object.

Additional references

  • Issuing Certificates Based on Certificate Templates


Re-Enroll All Certificate Holders

This procedure is used when a critical change is made to the certificate template and you want all subjects that hold a certificate that is based on this template to re-enroll as quickly as possible. The next time the subject verifies the version of the certificate against the version of the template on the certification authority (CA), the subject will re-enroll.

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 re-enroll all certificate holders

  1. Open the Certificate Templates snap-in.

  2. Right-click the template that you want to use, and then click Reenroll All Certificate Holders.

Additional references

  • Issuing Certificates Based on Certificate Templates


Modify an Issuance Policy

Certificates can be requested by any subject that has at least Read and Enroll permissions for the corresponding certificate template. In some cases, the administrator may want to place some restrictions on the process that occurs after a certificate request is made. This gives the administrator control of what certificates are issued and how the issuance process is implemented. This type of restriction is known as an issuance policy (also known as an enrollment or certificate policy). Issuance policies can contain requirements for certificate manager approval, multiple authorized signature requirements, and whether application and issuance policies should be implemented for this certificate. For more information, see Application Policy.

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 modify an issuance policy

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

  3. Click the Issuance Requirements tab.

  4. Provide the requested information.

  5. Click Apply.

Additional considerations

  • This procedure is applicable to version 2 and version 3 certificate templates. For more information, see Certificate Template Versions.

Additional references

  • Issuing Certificates Based on Certificate Templates

  • Issuance Requirements


Configure Certificate Publishing in Active Directory Domain Services

A Windows Server–based certification authority (CA) can add certificates that have been issued to Active Directory subjects to the appropriate Active Directory object. This allows other users of Active Directory Domain Services (AD DS) to easily locate and use the subject's certificate. There are two settings (located on the General tab of the certificate template's property sheet) that affect the way this feature works:

  • Publish certificate in Active Directory. When a subject obtains a certificate based on this template, the issued certificate will be added to that subject's Active Directory object.

  • Do not automatically re-enroll if a duplicate certificate exists in Active Directory. When the subject attempts to enroll for a certificate based on this template, computers running Windows XP or later will search for a duplicate certificate in AD DS. If one exists, autoenrollment will not submit a re-enrollment request. This allows certificates to be renewed but prevents multiple duplicate certificates from being issued.

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 certificate publishing in AD DS

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

  3. On the General tab, select the check box for the appropriate Active Directory setting, and then click Apply.

Additional references

  • Issuing Certificates Based on Certificate Templates


Troubleshooting Certificate Templates

This section lists a few common issues you may encounter when using the Certificate Templates snap-in or working with certificate templates. For more information about troubleshooting and resolving problems with certificate templates, see Active Directory Certificate Services Troubleshooting (http://go.microsoft.com/fwlink/?LinkId=89215).

What problem are you having?

  • The Certificate Templates snap-in does not list any templates after prompting to install new certificate templates

  • Certificates are not being issued to clients

  • Certificates are issued to subjects, but cryptographic operations with those certificates fail

  • Domain controllers are not obtaining a domain controller certificate

  • Clients are unable to obtain certificates via autoenrollement

  • Names of certificate templates in the snap-in are inconsistent between views or windows

  • The private key cannot be exported from smart card certificates, even when Allow private key to be exported is selected in the certificate template

  • The certificate template is modified, but some certification authorities (CAs) still have the unmodified version

  • The private key is not being archived even though I selected the Archive subject's encryption private key option and configured the CA to require key recovery

  • Autoenrollment is prompting me to renew a certificate that isn't mine, and I have certificates in my Personal certificate store that I didn't put there

The Certificate Templates snap-in does not list any templates after prompting to install new certificate templates.
  • Cause: The certificate templates have not yet replicated to the certification authority (CA) that the computer is connected to. This replication is part of Active Directory replication.

  • Solution: Wait for the certificate templates to replicate and then reopen the Certificate Templates snap-in.

Certificates are not being issued to clients.
  • Cause: The issuing certificate used by the certification authority (CA) has a shorter remaining lifetime than the template overlap period configured for the request certificate template. This means that the issued certificate would be immediately eligible for re-enrollment. Instead of issuing and continuously renewing this certificate, the certificate request is not processed.

  • Solution: Renew the issuing certificate used by the CA.

Certificates are issued to subjects, but cryptographic operations with those certificates fail.
  • Cause: The cryptographic service provider (CSP) does not match key usage settings or does not exist.

  • Solution: Confirm that you set the CSP in the template to one that supports the type of cryptographic operation that the certificate will be used for.

Domain controllers are not obtaining a domain controller certificate.
  • Cause: Autoenrollment has been disabled by using Group Policy settings for domain controllers. Domain controllers obtain their certificates through autoenrollment.

  • Solution: Enable autoenrollment for domain controllers.

  • Cause: The default Automatic Certificate Request setting for domain controllers has been removed from the Default Domain Controllers policy.

  • Solution: Create a new Automatic Certificate Request in the Default Domain Controllers policy for the Domain Controller certificate template.

Clients are unable to obtain certificates via autoenrollement.
  • Cause: Security permissions must be set to allow intended subjects to both enroll and autoenroll on the certificate template. Both permissions are required to enable autoenrollment.

  • Solution: Modify the discretionary access control list (DACL) on the certificate template to grant Read, Enroll, and Autoenroll permissions for the subjects that you want.

Names of certificate templates in the snap-in are inconsistent between views or windows.
  • Cause: Active Directory Sites and Services is being used to view the certificate templates. This snap-in may not provide as accurate a display as Certificate Templates.

  • Solution: Use the Certificate Templates snap-in to administer certificate templates.

The private key cannot be exported from smart card certificates, even when Allow private key to be exported is selected in the certificate template.
  • Cause: Smart cards do not allow private keys to be exported once they are written to the smart card.

  • Solution: None

The certificate template is modified, but some certification authorities (CAs) still have the unmodified version.
  • Cause: Certificate templates are replicated between CAs with the Active Directory replication process. Because this replication is not instantaneous, there may be a short delay before the new version of the template is available on all CAs.

  • Solution: Wait until the modified template is replicated to all CAs. To display the certificate templates that are available on the CA, use the Certutil.exe command-line tool.

The private key is not being archived even though I selected the Archive subject's encryption private key option and configured the CA to require key recovery.
  • Cause: Private keys will not be archived when the key usage for the certificate template is set to Signature. This is because the digital signature usage requires the key to not be recoverable.

  • Solution: None

Autoenrollment is prompting me to renew a certificate that isn't mine, and I have certificates in my Personal certificate store that I didn't put there.
  • Cause: When using the smart card enrollment station on the administrator's computer to renew or change the certificate stored on the smart card, the certificate from the smart card is copied to the administrator's private certificate store. This certificate may be processed by autoenrollment and prompt you to begin the renewal process.

  • Solution: Click Start to begin the autoenrollment renewal process. Because the certificate is not yours, the autoenrollment process will end after you click Start. If you want to remove the certificates from your Personal certificate store, they can be deleted manually.


Additional Resources for Certificate Templates

For more information about certificate templates, see the following resources on the Microsoft Web site:

  • Implementing and Administering Certificate Templates in Windows Server 2008 (http://go.microsoft.com/fwlink/?LinkID=92522)

  • Certificates Technical Reference (http://go.microsoft.com/fwlink/?LinkId=64035)

  • Certificate Services Technical Reference (http://go.microsoft.com/fwlink/?LinkId=64036)

  • Certificate Autoenrollment in Windows Server (http://go.microsoft.com/fwlink/?LinkId=64037)

  • Windows Server Advanced Certificate Enrollment and Management (http://go.microsoft.com/fwlink/?LinkId=64038)

  • Certificate Key Archival and Management (http://go.microsoft.com/fwlink/?LinkId=89551)


Object Identifiers

Object identifiers (also known as OIDs) are numbers that identify an object class or attribute. An object identifier is represented as a dotted decimal string, such as 1.2.3.4, with each dot representing a new branch in the hierarchy.

Object identifiers are organized into an industry-wide global hierarchy. Registration authorities issue root object identifiers to individuals or organizations, who manage the hierarchy below their root object identifier.

Object identifiers must be unique within an enterprise.

To create a new object identifier

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

  3. On the Extensions tab, click Application Policies, and then click Edit.

  4. In Edit Application Policies Extension, click Add.

  5. In Add Application Policy, click New.

  6. Provide the requested information.


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.


Configure Certificate Enrollment

Active Directory Certificate Services (AD CS) supports a variety of enrollment and renewal methods, such as the Certificate Request Wizard and AD CS Web enrollment. However, if you deploy non-Microsoft certification authorities or custom certificate enrollment and renewal applications, you must perform any configuration required for those services and applications.