Administering Version 2 Certificate Templates

Applies To: Windows Server 2003 with SP1

Version 2 certificate templates allow you to define specific attributes for certificates that meet your organization's business needs. For example, certificate templates allow you to

• Define whether the private key associated with a certificate can be exported.

• Define whether the certificate request must be approved by a certificate manager, and define how many managers must approve a request before the certificate is issued.

• Define what cryptographic service providers (CSPs) are supported by a certificate template.

• Define issuance and application policy for issued certificates.

The following sections detail the specific information that can be configured for a version 2 certificate template using the Certificate Templates MMC console (certtmpl.msc). To create a new certificate template, you start by duplicating an existing certificate template that is similar in functionality to the required certificate template. Selecting the correct initial template is important so that the current certificate template settings will serve as a starting point for your certificate template configuration.

Note

Since certificate templates exist only once within a forest, all changes made apply on a forest-wide level. If several CAs exist within one forest, templates can be assigned to CAs via the publishing mechanism. Nevertheless, all CAs within a forest use one set of templates.

The General Tab

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

Figure 1: The General Tab

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

• Template display name The display name shown in the Certificate Templates console, Certificates console, and in the Certification Authority console.

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

  Note

  The template display name and template name attributes cannot be changed once the certificate template is created.

• Validity period Defines the validity period for an issued certificate. The validity period must not be defined to be greater than the validity period of the CA's certificate. The minimum renewal period is 80% of the certificate lifetime or 6 weeks, whichever is greater.

• Renewal period The 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 based on the certificate template. The certificates are published as an attribute of the security principal contained in the subject of the issued certificate.

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

Note

Re-enrollment settings mainly affect auto-enrollment design in a Windows Server 2003 network. See the Windows 2000 Certificate Autoenrollment in Windows XP white paper at https://www.microsoft.com/technet/prodtechnol/winxppro/maintain/certenrl.mspx

The Request Handling Tab

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

Figure 2: The Request Handling Tab

Certificate Purposes

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

• Encryption A certificate with this purpose will contain cryptographic keys for encryption and decryption.

• Signature A certificate with this purpose will contain cryptographic keys for signing data only.

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

Note

The certificate purpose setting will determine whether key archival can be enabled for a certificate template. Key archival is only possible if the certificate purpose is set to Encryption or Signature and encryption. The recovery of a private key for digitally signing information may result in identity theft and is not supported. Key archival is not supported by most smart card CSPs.

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, Windows Server 2003, Enterprise Edition and Windows Server 2003, Datacenter Edition have the ability to 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 in the Request Handling tab:

• Archive subject's encryption private key If the issuing Windows Server 2003, Enterprise Edition or Windows Server 2003, Datacenter Edition certification authority 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 subjects private key can be exported for backup or transportation.

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

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

To enable key archival and recovery, the following configuration settings in the certificate template and at the Windows Server 2003, Enterprise Edition or Windows Server 2003, Datacenter Edition 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 certification authority and key recovery agent certificates must be issued to those agents.

• Key archival must be configured on the certification authority.

User Input Settings

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 auto-enrollment without any user interaction and is the default setting for both machine and user certificates. This option must not be enabled for machine certificates.

• Prompt the user during enrollment Although useful when testing initial auto-enrollment 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 users 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 machine certificates or smart card user certificates.

Note

To enable smart card auto-enrollment, the Prompt the user during enrollment option must be enabled so that the user is prompted to insert the smart card in the smart card reader when required.

Important

Strong private key protection with auto-enrollment is not supported or enabled for machine certificates and is only available on Windows XP Service Pack 1 client computers.

In addition, with Windows 2000 Service Pack 4 and Windows XP Service Pack 1, it is possible to force strong private key protection for all CSPs through the registry. Three new keys can be added to "HKLM\Software\Policies\Microsoft\Cryptography" in the registry:

ForceKeyProtection This key will force DPAPI to grey-out the option that would allow the user the choice of using a password when UI was selected. When set, the user MUST enter a password.

<"0"> = do not force UI on key protection
<"1"> = default to UI, but let user change selection
<"2"> = force UI on key protection, grey-out option for user

CachePrivateKeys Contains a 1, if (and only if) the following 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.

Warning

Requiring the use of strong private key protection and user prompting on all new and imported keys will disable some applications, such as EFS and wireless (802.1x authentication) which cannot display UI. For more information, refer to the following Knowledge Base Article: https://support.microsoft.com/default.aspx?scid=kb;en-us;320828

Other Request Handling Settings

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.

• 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. If you do not select a specific CSP, the certificate enrollment will work with any installed CSP, but will use the first CSP from the enumeration list. The CSP must be installed on the client workstation for the CSP to be used during enrollment. If a specific CSP is chosen and not available on a client computer, enrollment will fail.

  

Note

You can add third-party CSPs by installing the manufacturers CSP-related files. The newly installed CSP will appear in the list of available CSPs when the certificate templates snap-in is opened after CSP installation.

The 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 using the authentication name of the subject, or explicitly defined by the subject and included in the certificate request (Figure 3).

Figure 3: The Subject Name Tab

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

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

• Common name The certification authority creates the subject name from the common name (CN) of the requestor obtained from Active Directory. These should be unique within a domain, but may not be unique within an enterprise.

• Fully distinguished name The certification authority creates the subject name from the fully distinguished name obtained from Active Directory. This guarantees 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 what name formats are included 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.

  Note

  The e-mail name is required for user certificates. If the e-mail name is not populated for a user in Active Directory, the certificate request by that user will fail.

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

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

• Service principal name (SPN) The service principal name 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 using any subject name. This would allow subjects to impersonate other subjects easily. 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.

Note

No user interface exists on the client to supply a subject name in the certificate request. If you require the ability to provide the subject name, you must perform the certificate request programmatically using the XEnroll.dll ActiveX control.

The Issuance Requirements Tab

The Issuance Requirements tab (Figure 4) allows higher assurance level certificates to be placed in a pending state until the certificate is reviewed before issuance. This allows for multiple signers of a CMC request to exist. For more information about CMC, see RFC 2797 Certificate Management Messages over CMS.

Figure 4: The Issuance Requirements Tab

When CA certificate manager approval is enabled, 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.

  Note

  Defining the number of authorized signatures enables several other configuration parameters.

• 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 certification authority 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-Certification Authority certificates. This certificate template requires that the signing certificate includes the Qualified Subordination Application Policy object identifier as shown in Figure 5.

Figure 5: Issuance Requirements for a Cross-Certification Authority Certificate

As you can see, the Cross-Certification Authority certificate request must be signed by a certificate containing the Qualified Subordination object identifier.

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.

Note

For information about including application and issuance policy object identifiers in an issued certificate, see The Extensions Tab section.

The Superseded Templates Tab

The Superseded Templates tab (Figure 6) allows you to supersede existing certificate templates with a modified version 2 certificate template.

Figure 6: The Superseded Templates Tab

The Superseded Templates tab allows you to redeploy version 2 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

• A version 1 certificate template with a version 2 certificate template

• A version 2 certificate template with a version 2 certificate template

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

Note

You can force the application of the updated certificate template by forcing all certificate holders to re-enroll the updated certificate template. For more information, see the Re-Enroll Certificate Holders section.

The Extensions Tab

The Extensions tab (Figure 7) allows you to define specific application policies, issuance policies, certificate subject types, and key usage attributes for a certificate template. The following sections detail the specifics on each form of extension defined in a certificate template.

Figure 7: The Extensions Tab

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.

Note

Application policies are similar to the extended key usage attribute in version 1 certificate templates. Because some implementations of PKI applications may not understand application policies, both application policies and enhanced key usage sections appear in certificates issued by a Microsoft CA.

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

Application Policy	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

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 certification authority may issue some certificates with no proof of identification and require subjects of another type to submit some proof. This provides different levels of assurance for different certificates. These levels of assurance are represented in certificates as issuance policies.

Note

Certificate policies refer to the certificate policies extension identifier described in RFC 2459.

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 certification authority. 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 certification authorities.

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 by Windows Server 2003 CAs:

• Key recovery agent

• Directory e-mail replication

• Cross-certified certification authority

• Certification authority (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 clone from 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 clone 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

The Security Tab

The Security tab (Figure 8) allows you to define the DACL for a specific certificate template. The permissions that you assign to the certificate template define which security principals can read, modify, enroll, or auto-enroll for a specific certificate template.

Figure 8: The Security Tab

The permissions that you can assign to a certificate template include

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

• Read This permission allows a security principal to see the certificate template when enrolling for certificates. It is required for a security principal to enroll or auto-enroll a certificate; it is required by the certificate server to find the certificate templates in Active Directory.

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

• Enroll This permission 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 permissions for the certificate template.

• Autoenroll This permission allows a security principal to receive a certificate through the auto-enrollment process. Auto-enrollment permissions require that the user has both Read and Enroll permissions in addition to the Auto-enroll permission.

Note

It is recommended that certificate template permissions be assigned only to global groups or universal groups. Because the certificate template objects are stored in the Configuration naming context, you cannot assign permissions using domain local groups. To simplify administration, it is never recommended to assign certificate template permissions to individual user or computer accounts.

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

Note

A version 2 certificate template can be distributed to Windows Millennium Edition and Windows 2000 with Service Pack 2 clients through the Web enrollment pages.