Share via

Certificate templates design considerations

  • Article

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Certificate template design considerations

Before deploying certificates, you must plan in order to ensure that appropriate certificates are issued to subjects. The certificates must provide the capability to perform the tasks expected by the subject but must not allow the subject to use the certificate for unintended or malicious tasks. Some questions that must be considered at this stage are:

  • Who or what needs certificates?

  • What should I allow the subjects to do with the certificates?

  • How long will the certificates be valid for?

  • How many certificates could each subject possibly have?

  • How will the subjects obtain the certificates?

Each of these questions is further discussed in the following sections.

Name considerations

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 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. Windows can either build the subject name automatically or request it from the subject. If Windows automatically provides the subject name, it obtains the information from Active Directory. 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 using the Web-based enrollment pages.

Certificate lifetime

Certificate-based cryptography uses public key cryptography to protect and sign data. Over time, evildoers can obtain data that is 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. Also, over time, the names guaranteed by a certificate may need to be changed. Because a certificate is a binding between a name and a public key, when either of these change, the certificate should be renewed.

Number of certificates per subject

Because subjects may have many uses for their certificates, an administrative decision must be made: whether to issue many specific certificates or a few broad certificates. This decision depends on the environment and the level of administration that you want 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 creates a number of granular templates, one for each job 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 only obtain new certificates that they need over time. The drawback to this strategy is that the subject may end up with a large number of certificates and private keys that become harder to manage over time.

A different strategy creates a few broad certificate templates that encompass job functions for most common groups of subjects. For example, if most employees use their certificates for mail signing and encryption as well as file encryption and IP Security, create one template that allows all those 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 granular control of the usage of the certificates. The administrator cannot decide that subgroups cannot encrypt mail or use IP Security without modifying the template or changing the strategy.

Cryptographic service providers and key size

One or more cryptographic service providers (CSPs) are identified as usable by a template. This allows the administrator to control what types of cryptography subjects can use within an enterprise. This is very useful when security is of paramount importance. Because subjects use the CSP for both portions of any cryptographic service--either encryption and decryption or signing and confirming signature--it is necessary to ensure that all subjects can use the same CSP. Otherwise, subjects may not be able to communicate with each other or perform the necessary job tasks if the key types between their CSPs are not compatible.

The easiest way to do this is to configure each certificate template to identify exactly one CSP. Which CSP should be identified is up to the administrator and depends on the level of security required, the intended purposes of the certificate, and the presence of security hardware, such as smart cards. In addition, new CSPs can easily be installed and used after the certificate template is deployed.

Each CSP provides one or more cryptographic algorithms for encryption or digital signature. Because each algorithm is different and its strength relies directly on the length of the key it uses, the minimum key size is specified in the certificate template. As a general rule, larger keys provide more protection over shorter keys for the same algorithm. However, larger keys take longer to generate and use. Care should be given to select a minimum key size that ensures the necessary amount of protection without impacting performance.

When selecting the CSP to associate with a certificate template, the use of smart cards is also a consideration. Each type of smart card has an associated CSP that must be selected for 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.

Obtaining certificates

There are many ways that subjects can obtain certificates. The two general categories of these ways are manual and automatic. The subject can either manually obtain a certificate using a Web page or Microsoft Management Console (MMC) snap-in, or they can obtain it via autoenrollment that has been configured by the administrator. While autoenrollment requires a bit more initial configuration, it is effective for deploying required certificates to users and computers without the subject performing additional steps. For more information on autoenrollment, see Planning for autoenrollment deployment.