Partager via

Creating Certificate Templates

  • Article

Applies To: Windows Server 2008

This topic includes design guidelines for creating certificate templates and the procedures for creating a new certificate template.

Design Guidelines

When you are creating a version 2 or 3 certificate template, consider the following design guidelines.

Defining the Subject Name

The holder of the private key associated with a certificate is known as the subject. This can be a user, a computer, a program, or virtually any object or service. Because the subject can vary greatly depending on who or what it is, you need some flexibility when providing the subject name in the certificate request. A Windows Server® 2008–based certification authority (CA) or a Windows Server 2003–based CA can either obtain the subject name automatically or request it from the subject. If the CA automatically provides the subject name, it obtains the information from Active Directory® Domain Services (AD DS). You can configure this process to include or exclude information that is useful in the environment. If it is configured to manually provide the subject name, the subject supplies that information in the certificate request by using the Web-based enrollment pages.

Defining the Certificate Lifetime

Certificate-based cryptography uses public key cryptography to protect and digitally sign data. Over time, it is theoretically possible to collect data protected with the public key and attempt to derive the private key from it. Given enough time and resources, this private key could be compromised, effectively rendering all protected data unprotected. Because certificates can be compromised over time, a finite certificate lifetime should be established.

Determining Certificate Usage

It is possible to issue many specific certificates that can only be used for a single purpose or to issue fewer certificates that have broad usage. This decision depends on the environment, the level of administration desired, and the possible effects on the subjects, as well as the effects of multiple certificates on applications that will use them.

One strategy of certificate administration is to create a number of specific templates—one for each function, such as file encryption or code signing. Subjects can then enroll for each certificate as needed for the appropriate function. This allows subjects to start with few certificates and obtain only new certificates that they need over time. The drawback to this strategy is that the subject may accumulate a large number of certificates and private keys that become more difficult to manage over time.

Alternatively, you could create a few broad certificate templates that encompass functions for the most common groups of subjects. For example, if most employees use their certificates for e-mail signing and encryption as well as file encryption, you can create one template that allows all these functions in the same certificate. This allows most subjects to obtain a single, all-purpose certificate. The drawback to this strategy is that there is no detailed control of the usage of the certificates. The administrator cannot decide that subgroups cannot encrypt e-mail without modifying the template or changing the strategy.

Determining Whether to Implement Cryptography Next Generation Algorithms

For Windows Server 2008–based version 3 certificate templates, the option exists to configure advanced cryptographic algorithms such as elliptic curve cryptography (ECC). Before configuring these settings, ensure that the operating systems and applications deployed in your environment can support these cryptographic algorithms.

Determining Which Cryptographic Service Provider to Implement

A version 2 certificate template allows you to define one or more cryptographic service providers (CSPs) as usable by a template. This allows the administrator to control the types of cryptography that subjects can use within an enterprise. This is useful when security is most important. Because subjects use the CSP for both portions of any cryptographic service—either encryption and decryption or signing and confirming signatures—it is necessary to ensure that all subjects can use the same CSP. The easiest way to do this is to configure each certificate template to identify one CSP. The administrator should determine the CSP to use for each template, depending on the level of security required, the intended purposes of the certificate, and the presence of security hardware, such as smart cards.

Determining Key Length

Each Cryptography Next Generation (CNG) algorithm provides choices for key length, and each CryptoAPI CSP provides one or more cryptographic algorithms for encryption or digital signature. You can define a minimum key size allowed for a certificate template. In general, larger keys provide more protection than shorter keys for the same algorithm, but larger keys take longer to generate and use. You should select a minimum key size that ensures the necessary amount of protection without affecting performance.

Determining Smart Card Usage

Each type of smart card has at least one associated CSP that must be implemented by the certificate template to allow the smart card to be used. If the correct smart card CSP is not associated with the template, the smart card will not be recognized and the template will fail. Ensure that you enable all smart card CSPs for the smart cards deployed in your environment within the certificate template.

Planning Deployment Methods

Certificates are deployed either manually or automatically. Manual enrollment can take place by using either the Web enrollment pages, the Certificates snap-in, or through CryptoAPI or CNG programming interfaces. Automatic enrollment requires the configuration described in the "Autoenrollment Considerations" section of Deploying Certificate Templates. In addition, there is a Network Device Enrollment Service component that can enroll certificates on behalf of devices such as routers by using the Simple Certificate Enrollment Protocol (SCEP). This component is included as a role service in Windows Server 2008.

Planning Key Archival

CAs installed on computers running Windows Server 2008 Enterprise, Windows Server 2008 Datacenter, Windows Server 2003 Enterprise Edition, or Windows Server 2003 Datacenter Edition can provide key archival of private keys. When planning key archival settings for a certificate template, consider the following settings:

  • Enable archival of the subject's private key

    This setting is only available when the issuing CA is installed on a computer running Windows Server 2008 Enterprise, Windows Server 2008 Datacenter, Windows Server 2003 Enterprise Edition, or Windows Server 2003 Datacenter Edition, and the CA is configured for key archival.

  • Define whether the private key can be exported

    If this setting is enabled, the subject can export the private key for backup or move the private key and certificate to another computer. If key archival is centralized, you may not want to enable this setting because it allows the key to be recovered in a decentralized manner.

Creating 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 CAs support different certificate templates. For example, some certificate templates can be issued and managed only by enterprise CAs on servers running Windows Server 2003, and some may require that the CA server be running Windows Server 2008. Review the list of default certificate templates in Certificate Templates Overview, 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.

Note

To perform any of the tasks associated with creating a certificate template, you must be logged on as a member of the Enterprise Admins group, a member of the forest root domain's Domain Admins group, or as a user who has been granted permission to perform the task.

Note

For detailed explanations of the entries on each tab in the template, see Administering Certificate Templates.

To create a new version 2 or 3 certificate template

  1. Open the Certificate Templates snap-in.

  2. In the details pane, right-click an existing certificate that will serve as the starting point for the new certificate, and then click Duplicate Template.

  3. Choose whether to duplicate the template as a Windows Server 2003–based template or a Windows Server 2008–based template.

  4. On the General tab, enter the Template display name and the Template name, and then click OK.

  5. Define any additional attributes for the newly created certificate template.

Defining Application and Issuance Policies

When you create a new certificate template, you can define which application and issuance policies are included in the issued certificates. Defining application and issuance policies requires the completion of three tasks:

  • Acquire object identifiers for the application and issuance policies.

  • Establish the application and issuance policies.

  • Map issuance policies between public key infrastructure (PKI) hierarchies.

Acquiring Object Identifiers

If you define a custom application policy or issuance policy, you must obtain an object identifier for the policy.

To acquire an object identifier

  1. Open the Certificate Templates snap-in.

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

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

  4. In the Edit Application Policies Extension dialog box, click Add.

  5. In Add Application Policy, ensure that the application you are creating does not exist, and then click New.

  6. In the New Application Policy dialog box, provide the name for the new application policy, note the generated object identifier, and then click OK.

Note

You can also add new object identifiers by editing certificate policies rather than application policies.

Establishing Application Policies

Once you have defined any custom application policies, you can then associate the application policy with the certificate template.

To associate the application policy with the 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. 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 desired application policy, and then click OK.

Establishing Issuance Policies

Once you have defined any custom issuance policies, you can then associate the issuance policy with the certificate template.

To associate the issuance policy with the 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. On the Extensions tab, click Certificate Policies, and then click Edit.

  4. In Edit Issuance Policies Extension, click Add.

  5. In the Add Issuance Policy dialog box, click New.

  6. Provide the requested information.

Mapping Issuance Policies Between PKI Hierarchies

When performing qualified subordination, it may be necessary to associate issuance policies in your organization with issuance policies defined in another organization. The policy mappings are defined in the Policy.inf file used to generate the cross-certified CA certificate.

In the Policy.inf file, you must include the policy mapping extension that maps the policies listed in the Policy.inf file with policies defined in the other PKI hierarchy. The following code example shows a section of a Policy.inf file that maps issuance policies for high, medium, and low assurance between two organizations.

[PolicyStatementExtension]

Policies = HighAssurancePolicy, MediumAssurancePolicy, LowAssurancePolicy

CRITICAL = FALSE

[HighAssurancePolicy]

OID = 1.3.6.1.4.1.311.21.8.256.257.258.259.1.402

[MediumAssurancePolicy]

OID = 1.3.6.1.4.1.311.21.8.256.257.258.259.1.401

[LowAssurancePolicy]

OID = 1.3.6.1.4.1.311.21.8.256.257.258.259.1.400

[PolicyMappingsExtension]

1.3.6.1.4.1.311.21.8.256.257.258.259.1.400 =

1.3.6.1.4.1.311.21.8.354.232.582.111.1.400

1.3.6.1.4.1.311.21.8.256.257.258.259.1.401 =

1.3.6.1.4.1.311.21.8.354.232.582.111.1.401

1.3.6.1.4.1.311.21.8.256.257.258.259.1.402 =

1.3.6.1.4.1.311.21.8.354.232.582.111.1.402

CRITICAL = YES

This example maps the object identifiers for the high-assurance policies, medium-assurance policies, and low-assurance policies to object identifiers that exist in the other organization's PKI. The other organization must define a Policy.inf file that maps the object identifiers in the opposite direction so that the object identifiers are recognized by both organizations.