Administering Certificate Templates

Applies To: Windows Server 2008

This topic includes detailed descriptions of the specific information that can be configured for certificate templates by using the Certificate Templates snap-in and procedures related to administering templates.

Configuring Certificate Templates

This topic describes the information that can be configured for certificate templates based on the Certificate Templates snap-in available in Windows Server® 2008 and Windows Server 2003. Items that are new in Windows Server 2008 are specifically noted. Items that do not specify an operating system version apply to templates for both Windows Server 2008 and Windows Server 2003.

General Tab

The General tab is the first tab that appears when you duplicate an existing certificate template.

On the General tab, you can configure the following attributes of the certificate template:

• Template display name. This is the display name that is shown in the Certificate Templates snap-in, Certificates snap-in, and in the Certification Authority snap-in.

• Template name. This is the name of the certificate template object created in the following container: CN=Certificate Templates,CN=Public Key Services,CN=Services,DC=ForestRootDomain.

• Validity period. This defines the validity period for an issued certificate. The validity period cannot be greater than the validity period of the CA's certificate. The minimum renewal period is 80 percent of the certificate lifetime or six weeks, whichever is greater.

• Renewal period. This is the period of time before the validity period expires when the certificate will be renewed if re-enrollment is supported for the certificate template.

• Publish options. You can choose whether to publish the certificate to Active Directory® Domain Services (AD DS) based on the certificate template. The certificates are published as an attribute of the security principal contained in the subject of the issued certificate.

• Re-enrollment option. If the certificate template is published in AD DS, you can prevent re-enrollment if a valid certificate of the same certificate template exists for the security principal indicated in the subject.

• Smart card certificate keys. For smart card renewal, this option enables the existing key to be used if a new key cannot be created. This helps prevent smart card renewal failures resulting from smart card capacity issues.

Request Handling Tab

The options on the Request Handling tab differ depending on whether you have duplicated a template to a version 2 certificate template in Windows Server 2003 or a version 3 template in Windows Vista® or Windows Server 2008.

Version 2 Templates

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

Certificate Purpose

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

• Encryption. This certificate contains cryptographic keys for encryption and decryption.

• Signature. This certificate contains cryptographic keys for signing data only.

• Signature and encryption. This certificate includes 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. This certificate allows for initial logon with a smart card, and to digitally sign data; it cannot be used for data encryption.

Archive Settings

When subjects lose their private keys due to user profile corruption or stolen computers, any information that was persistently encrypted with the corresponding public key is inaccessible. To help avoid this, a CA running on Windows Server 2008 Enterprise, Windows Server 2008 Datacenter, Windows Server 2003 Enterprise Edition, or Windows Server 2003 Datacenter Edition can archive a subject's keys in its database when certificates are issued. These keys are encrypted and stored by the CA. If subjects lose their keys, the information can be retrieved from the database and securely provided to the subjects. This allows the encrypted information to be recovered instead of lost.

The following key archival settings are defined on the Request Handling tab:

• Delete revoked or expired certificates (do not archive). If a certificate is renewed due to expiration or revocation, the previously issued certificate is removed from the subject's certificate store. By default, the certificate is archived.

• Include symmetric algorithms allowed by the subject. When the subject requests the certificate, a list of supported symmetric algorithms can be supplied by the subject. This option allows the issuing CA to include those algorithms in the certificate, even if they are not recognized or supported by that server. The algorithms are used by applications such as secure e-mail.

• Archive subject's encryption private key. If the issuing enterprise CA is configured for key archival, the subject's private key will be archived.

• Allow private key to be exported. When this option is specified, the subject's private key can be exported for backup or transfer.

To enable key archival and recovery, the following configuration settings in the certificate template and on the CA must be made:

• The specific certificate template must be configured to allow key archival.

• One or more key recovery agents must be identified on the CA, and key recovery agent certificates must be issued to those agents.

• Key archival must be configured on the CA.

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

• Minimum key size. This specifies the minimum size, in bits, of the key that will be generated for this certificate.

• CSPs. This is a list of CSPs that will be used to enroll certificates for the given template. Selecting one or more CSPs configures the certificate to work only with those CSPs. If you do not select a specific CSP, the certificate enrollment will work with any installed CSP but will use the first CSP in the list. The CSP must be installed on the client computer for the CSP to be used during enrollment. If a specific CSP is chosen and not available on a client computer, enrollment will fail.

The Request Handling tab also allows several user input settings to be defined for a certificate template. These settings include:

• Enroll subject without requiring any user input. This option allows autoenrollment without any user interaction and is the default setting for both computer and user certificates. This option must not be enabled for computer certificates.

• Prompt the user during enrollment. Although useful when testing initial autoenrollment deployments, typically, this option is disabled. By disabling this option, users do not have to provide any input for the installation of a certificate based on the certificate template.

• Prompt the user during enrollment and require user input when the private key is used. This option enables the user to set a strong private key protection password on the user's private key when the key is generated and requires the user to use it whenever the certificate and private key are used. This option must not be enabled for computer certificates or smart card user certificates.

You can force strong private key protection for all CSPs through the registry in Windows Server 2003 with SP2, Windows Server 2003 with SP1, Windows 2000 Server with Service Pack 4 (SP4), Windows Vista, Windows XP with SP2, or Windows XP with SP1. Three new keys can be added to HKLM\Software\Policies\Microsoft\Cryptography in the registry:

• ForceKeyProtection. This key will force the Data Protection application programming interface (DPAPI) to disable the option that allows the user to choose whether to use a password to protect their private key. When set, the user must use a password to protect their private key.

  <"0"> = Do not force UI on key protection

  <"1"> = Default to UI, but let user change selection

  <"2"> = Force UI on key protection; disable option for user

• CachePrivateKeys. Contains a 1 if the PrivateKeyLifetimeSeconds registry key is used.

• PrivateKeyLifetimeSeconds. Contains the number of seconds that a key will remain cached without being used. The key cache timer will be reset on every successful use in the CSP.

Windows Server 2008

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

Additions and changes to the Request Handling tab are:

• Use advanced Symmetric algorithm to send the key to the CA. This option allows the administrator to choose the Advanced Encryption Standard (AES) algorithm to encrypt private keys while they are transferred to the CA for key archival. If this option is selected, the client computer will use AES256 symmetric encryption (along with the CA's exchange certificate for asymmetric encryption) to send the private key to the CA for archival. If this option is not selected, the symmetric algorithm used is Triple Data Encryption Standard (3DES). Because key archival is intended for encryption keys (not signing keys), this option is enabled only when Encryption is selected in the Purpose box.

• Add Read permissions to Network Service on the private key. For computer templates, this option grants Read permission to Network Service for the certificate's private key on the computer to which the certificate is issued. This enables services such as the Online Responder and Internet Information Services (IIS) to use certificates and keys issued to the computer on which they run. In previous versions of Windows, these permissions had to be configured manually.

• The Minimum key size option has been enhanced and moved to the new Cryptography tab.

• The CSPs button has been removed.

Cryptography Tab

Windows Server 2008 contains a new Cryptography tab. This tab replaces and extends the CSP Selection dialog box accessible by clicking the CSPs button on the Request Handling tab of a version 2 template.

The Cryptography tab contains the following new options:

• Algorithm name. This option introduces the ability to select an advanced algorithm for encryption, signing, or both (depending on the template's purpose). By default, Windows offers the following algorithms: DSA, ECDH_P256, ECDH_P384, ECDH_P521, ECDSA_P256, ECDSA_P384, ECDSA_P521, and RSA.

• Minimum key size. This option introduces the ability to specify a minimum required size for the keys used with the chosen algorithm. The default is the minimum key length supported on the system for the chosen algorithm. However, the administrator can enter any number.

• Providers. Version 2 templates offered a list of CryptoAPI CSPs; version 3 templates offer a dynamically populated list of Cryptography Next Generation (CNG) providers. This list is populated with all providers available on the system that meet the criteria specified by 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 introduces the ability to choose an advanced hash algorithm. By default, the following algorithms are available: MD2, MD4, MD5, SHA1, SHA256, SHA384, and SHA512.

• Use alternate signature format. When the RSA algorithm is selected, this check box allows the administrator to specify that certificate requests created for this template include a discrete signature in Public Key Cryptography Standards (PKCS) #1 version 2.1 format. Activating this option for any algorithm will force a client computer that uses the certificate autoenrollment functionality or that enrolls a certificate by using the Certificates snap-in to generate a certificate request that includes a discrete signature.

Subject Name Tab

When establishing a certificate template, the subject name must be defined. This is included in the issued certificate template and must uniquely identify the subject. The subject name can either be built automatically during the certificate request by using the authentication name of the subject, or explicitly defined by the subject and included in the certificate request.

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

• None. Does not enforce any name format for this field.

• Common name. The CA creates the subject name from the common name (CN) of the requester obtained from AD DS. These should be unique within a domain but do not have to be unique within an enterprise.

• Fully distinguished name. The CA creates the subject name from the fully distinguished name obtained from AD DS. This ensures that the name is unique within an enterprise.

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

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

• E-mail name. If the E-mail name field is populated in the Active Directory user object, that e-mail name will be used for user accounts.

• DNS name. The fully qualified domain name (FQDN) of the subject that requested the certificate is used for computer accounts.

• User principal name (UPN). This is part of the Active Directory user object and will be used for user accounts.

• Service principal name (SPN). This is part of the Active Directory computer object and will be used for computer accounts.

If the Subject Name option is set to Supply in the request, you should set one or more issuance requirements for the template to prevent subjects from requesting certificates by using any subject name. Issuance requirements ensure that the certificate request is inspected and validated before the certificate is issued.

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

The Issuance Requirements Tab

The Issuance Requirements tab allows certificates with a higher assurance level to be placed in a pending state until the certificate is reviewed before issuance. This allows for multiple signers of a Common Messaging Calls (CMC) request to exist. For more information about CMC, see Request for Comment (RFC) 2797, "Certificate Management Messages over CMS." You can obtain RFCs and Internet drafts from the Internet Engineering Task Force Web site (https://go.microsoft.com/fwlink/?LinkId=121).

When CA certificate manager approval is selected, the certificate is placed into a pending state, rather than being issued immediately. In its pending state, the certificate request can be reviewed by certificate managers, ensuring a higher level of assurance for the issued certificate.

The following settings configure the authentication and signature requirements for issuance certificates that are based on a template.

• CA certificate manager approval. All certificates are placed into the pending container for a certificate manager to issue or deny. Any defined certificate manager can issue or deny a certificate request of this type.

• This number of authorized signatures. This setting requires the CMC certificate request to be digitally signed by one or more authorized parties before it can be issued.

• Policy type required in signature. This option is only enabled when the number of authorized signatures value is set. This option defines which specific application policy, issuance policy, or both are required in the signing certificate. This is how the CA determines whether the signature is appropriate for authorizing the issuance of the subject's certificate.

• Application policy. This option specifies the application policy that must be included in the signing certificate used to sign the certificate request. It is enabled when Policy type required in signature is set to either Application policy or Both application and issuance policy.

• Issuance policy. This option specifies the issuance policy that must be included in the signing certificate used to sign the certificate request. This option is enabled when Policy type required in signature is set to either Issuance policy or Both application and issuance policy.

An example of where issuance requirements are defined is for the issuance of cross-certified CA certificates. The template for this certificate requires that the signing certificate includes the Qualified Subordination object identifier as shown in the following figure.

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

Superseded Templates Tab

The Superseded Templates tab, shown in the following figure, allows you to supersede existing certificate templates with a modified version 2 certificate template.

This tab allows you to redeploy certificates and ensure that the updated certificates replace previous versions of the certificate or other certificate templates that were used for the same purposes. You can supersede the following:

• A version 1, 2, or 3 certificate template with a version 2 or 3 certificate template

• Multiple existing certificate templates with a common version 2 or 3 certificate template

Extensions Tab

The Extensions tab shown in the following figure allows you to define specific application policies, issuance policies, certificate subject types, and key usage attributes for a certificate template. The following sections provide specific information about each form of extension defined in a certificate template.

Application Policies

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

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

The following table shows some of the more commonly used application policies and their related object identifiers.

For Windows Server 2008–based CAs, the new OCSP Response Signing default template contains an additional custom extension called OCSP no revocation checking. This template 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 commonly used authority information access and CRL distribution point extensions in the certificate. This is because OCSP Response Signing certificates are not checked for revocation status. Instead, they tend to be relatively short-lived certificates (the default template validity period is two weeks). Note that the extension only has this effect if the certificate request contains OCSP Response Signing in the enhanced key usage and application policies, as shown in the following figure.

Certificate Policies

Certificate policies, also referred to as issuance policies, define the level of assurance for an issued certificate. A CA processes each certificate request by a defined set of rules. The CA may issue some certificates with no proof of identification and require subjects of another type to submit proof. This provides different levels of assurance for different certificates. These levels of assurance are represented in certificates as issuance policies.

An issuance policy is a group of administrative rules that are implemented when issuing certificates. They are represented in a certificate by an object identifier 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.

An issuance policy describes the conditions under which a certificate is issued. This provides a level of assurance that the subject's certificate request was verified in a specific way.

One or more issuance policies may be selected for a certificate template. Because these issuance policies are simply text labels with an associated object identifier, no options are associated with them. The only special issuance policy is All issuance policies, which indicates that this policy includes all others. This is normally reserved for certificates held by CAs.

Issuance policies are often used when configuring qualified subordination (cross-certification) between PKI hierarchies to ensure that certificates recognized by another organization's PKI meet issuance requirements required by your organization.

Certificate Template Information

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

• Key recovery agent

• Directory e-mail replication

• Cross-certified CA

• CA

• Computer

• User

The certificate template information extension cannot be edited. If you require a specific subject type to be applied to a certificate, you should duplicate a certificate template that includes the required subject type. Some of the internal flags that are defined for specific subject types limit the display of the certificate template to computers or users. Choosing to duplicate an incorrect certificate template will prevent the certificate template from being displayed to the desired enrollment audience. For example, a computer certificate template cannot be enrolled for use by a user account.

Key Usage

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

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

• Digital signature

• Signature is a proof of origin (nonrepudiation)

• Certificate signing

• CRL signing

For encryption key usage, the following options are available:

• Key exchange without key encryption

• Key exchange only with key encryption

Security Tab

The Security tab, shown in the following figure, allows you to define the discretionary access control list (DACL) for a specific certificate template. The permissions that you assign to the certificate template define which security principals can read, modify, enroll, or autoenroll for a specific certificate template.

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

• Full Control. This allows a security principal to modify all attributes of a certificate template, including the permissions for the certificate template.

• Read. This allows a security principal to see the certificate template when enrolling for certificates. It is required for a security principal to enroll or autoenroll a certificate; it is required by the certificate server to find the certificate templates in AD DS.

• Write. This allows a security principal to modify the attributes of a certificate template, including the permissions assigned to the certificate template.

• Enroll. This allows a security principal to enroll for a certificate based on the certificate template. To enroll for a certificate, the security principal must also have Read permission for the certificate template.

• Autoenroll. This allows a security principal to receive a certificate through the autoenrollment process. Autoenrollment permissions require that the user has both Read and Enroll permissions in addition to the Autoenroll permission.

It should be considered a best practice to keep the Read permission assignment for the Authenticated Users group. This permission assignment allows all users and computers to view the certificate templates in AD DS. This includes the CA running under the System context of a computer account to view the certificate templates when issuing certificates to users and computers.

Delegating Template Management

You can delegate the ability to manage individual certificate templates or to create any certificate templates by defining appropriate permissions to global groups or universal groups that a user belongs to.

There are three levels of delegation for certificate template administration:

• Modify existing templates

• Create new templates (by duplicating existing templates)

• Full delegation (including modifying all existing templates and creating new ones)

Modify Existing Templates

To delegate modification of a specific certificate template, assign a global or universal group the Read and Write permissions on the Security tab (see Security Tab) of the certificate template. Once a delegated administrator has Write permission on a template, the administrator needs to take ownership of the specific template before applying any changes.

To take ownership of a template

1. Open the Certificate Templates snap-in.

2. Double-click the appropriate template.

3. On the Security tab, click Advanced.

4. In the Advanced Security Settings dialog box, on the Owner tab, select the current user's name, and then click Apply.

5. Ensure that the Current owner of this item dialog box displays the current user's name, and then click OK.

Create New Templates

To delegate the ability to create certificate templates to users who are not members of the Domain Admins group in the forest root domain, or members of the Enterprise Admins group, it is necessary to define the appropriate permissions in the Configuration naming context of AD DS.

To delegate the ability to duplicate and create new certificate templates, you must make the following permission assignments to a global or universal group of which the user is a member:

• Grant Create All Child Objects permission on the following container: CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=ForestRoot.

• Grant Full Control permission to every certificate template in the following container: CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=ForestRoot. The permissions assigned to the Certificate Templates container are not inherited by the individual certificate templates.

• Grant Create All Child Objects permission on the following container: CN=OID,CN=Public Key Services,CN=Services,CN=Configuration,DC=ForestRoot container.

Full Delegation

To delegate the ability to modify all existing templates and create new ones

1. For existing templates, follow the steps in Modify Existing Templates, and delegate the Write permission.

2. Add the following access control entries (ACEs) on the Template container objects:

   • Grant Create All Child Objects and Delete All Child Objects permissions on the following container: CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=ForestRoot.

   • Grant Create All Child Objects and Delete All Child Objects permissions on the following container: CN=OID,CN=Public Key Services,CN=Services,CN=Configuration,DC= ForestRoot.

Allowing the Creation and Modification of any Certificate Template

Being able to administer all templates includes the ability to duplicate and create new templates.

To delegate administration of all templates

1. Open the ADSI Edit snap-in (Adsiedit.msc).

2. In the console tree, right-click ADSI Edit, and then click Connect to.

3. In the Connection dialog box, in the Connection Point section, click Naming Context, select Configuration Container, and then click OK.

4. In the console tree, double-click ADSI Edit.

5. In the console tree, double-click Configuration Container.

6. In the console tree, double-click **CN=Configuration,DC=**ForestRootDomain (where ForestRootDomain is the LDAP distinguished name of your forest root domain).

7. In the console tree, double-click CN=Services.

8. In the console tree, double-click CN=Public Key Services.

9. In the console tree, right-click CN=Certificate Templates, and then click Properties.

10. In the CN=Certificate Templates Properties dialog box, on the Security tab, click Add. Add a global or universal group that contains the users you want to delegate certificate creation and management permissions to, and then click OK.

11. On the Security tab, select the newly added security group, ensure that the security group is assigned Allow for the Full Control permission, and then click OK.

12. In the console tree, right-click CN=OID, and then click Properties.

13. In the CN=OID Properties dialog box, on the Security tab, click Add. Add a global or universal group that contains the users you want to delegate certificate creation and management permissions to, and then click OK.

14. On the Security tab, select the newly added security group, ensure that the security group is assigned Allow for the Full Control permission, and then click OK.

15. Close ADSI Edit.

16. Ensure that the security group assigned Full Control permissions to the CN=Certificate Templates and CN=OID containers is also assigned Full Control permissions for all certificate templates listed in the Certificate Templates snap-in (Certtmpl.msc).

Replace an Existing Certificate Template with a New Certificate Template

This process, also referred to as superseding an existing template, defines which existing templates a version 2 or 3 certificate is replacing.

To replace an existing certificate template with a new certificate template

1. Open the Certificate Templates snap-in.

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

3. Click the Superseded Templates tab, and then click Add.

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

Re-enroll Certificate Holders

If you make modifications to a certificate template that you want implemented immediately for all existing certificate holders, you can force re-enrollment.

To force re-enrollment

1. Open the Certificate Templates snap-in.

2. In the details pane, right-click the certificate template that you want to re-enroll for all certificate holders, and then click Reenroll all Certificate Holders.