Freigeben über

Planning Considerations

  • Artikel

Applies To: Windows Server 2003 with SP1

This section looks at the topics that must be considered when planning all aspects of version 2 certificate templates. The section provides design guidelines for the creation of certificate templates and best practices to implement when working with certificate templates.

Design Guidelines

When creating a version 2 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 2003 CA can either build the subject name automatically or request it from the subject. If it 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.

  • 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 creates a number of specific 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.

    Alternatively, you could create 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, 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 detailed control of the usage of the certificates. The administrator cannot decide that subgroups cannot encrypt mail without modifying the template or changing the strategy.

  • Determining which CSP 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 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 serviceeither encryption and decryption or signing and confirming signatureit 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 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.

  • Determining key length Each 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 over 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 typically deployed manually or automatically. Manual enrollment can take place using either the Web enrollment pages, the Certificates MMC console, or through CryptoAPI or CAPICOM programming interfaces. Auto-enrollment requires the configuration described in the Auto-Enrollment Considerations section.

  • Planning Key Archival Windows Server 2003, Enterprise Edition and Windows Server 2003, Datacenter Edition CAs can provide key archival of private keys. When planning key archival settings for a certificate template, consider the following settings:

    • Enabling archival of the subject's private key This option is only available when the issuing CA is running 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 option is enabled, the subject can export the private key for backup purposes or move the private key and certificate to another computer. If key archival is centralized, you may not want to enable this option because it allows the key to be recovered in a decentralized manner.

Best Practices

When planning certificate template deployment, use the following best practices:

  • Do not delete the Certificate Publishers security group.

    The Certificate Publishers security group contains each certification authority's computer account and is used when publishing certificate templates to Active Directory. If this group is removed, the certification authority may not publish certificates to Active Directory correctly. To avoid this, the group should not be deleted and its membership should not be modified.

  • Add the CA machine accounts to every Cert Publishers group.

    The Cert Publishers group is a domain local group that exists in every domain in the forest. In each domain, all CA computer accounts should be added to the Cert Publishers group.

  • Do not exceed the certificate lifetime of the issuing certification authority.

    Certificate lifetimes work as a subset of the certification authority's (CA) certificate lifetime. All certificates, including the CA certificate, have an expiration date after which they are no longer valid. As a result, a certificate cannot be issued with a lifetime that exceeds the lifetime of the issuing CA. Issuing such a certificate would allow it to be valid for longer than the issuing CA certificate, which violates certificate chaining rules. A CA will therefore continue to issue certificates until the CA's certificate expires or until the requested template's renewal period is greater than the CA's certificate remaining lifetime. If a certificate template requires a lifetime greater than the lifetime of the CA certificate, the validity period of the issued certificate is truncated to the amount of time left in the lifetime of the CA certificate.

  • Plan certificate templates before deployment.

    Certificates can be issued to subjects in many ways, including manual enrollment, auto-enrollment, and Web enrollment. In addition, there are many certificate strategies including issuing one all-inclusive certificate to all subjects and issuing several application-specific certificates to subjects as needed. Because there are so many options, planning should be done well in advance of certificate deployment.

  • Upgrade the certificate templates in Active Directory before upgrading from Windows 2000.

    Windows Server 2003, Enterprise Edition and Windows Server 2003, Datacenter Edition certification authorities use newer versions of certificate templates than those used by Windows 2000 CAs. These templates must be upgraded before the certification authorities are upgraded to ensure proper operation.

  • Duplicate new templates from existing templates closest in function to the intended template.

    New certificate templates are duplicated from existing templates. Many settings are copied from the original template. Because of this, duplicating one template to another of a totally different type may carry over some unintended settings. When duplicating a template, examine the subject type of the original template and ensure that you duplicate one that has a similar function to that of the intended template. Although most settings for certificate templates can be edited once the template is duplicated, the subject type cannot be changed.

  • Determine publication points for certificate templates.

    Determine which CAs will issue specific certificate templates based on both the administration model implemented by the organization and the usage of the certificate template. For example, if the administration model is a project-based management model, it would be appropriate to only assign the certificate template to CAs associated with the project. On the other hand, if the certificate template is widely used throughout the organization, it may be appropriate to have all CAs issue the certificate template to provide fault tolerance if a CA is unavailable.

  • Minimize the number of issued certificates.

    Consider using multi-purpose certificates that can be used for more than one job task rather than issuing separate certificates for each job task that must be performed. This reduces the number of issued certificates and reduces the complexity when a user must select which certificate to present to an application.