Description of certificate template generations

Below is a description of the different generations of certificate templates (schema versions) and the innovations introduced with them.

Backgrounds

Up to Windows Server 2008 R2, when copying a certificate template, you were asked whether it was a Windows 2003 Enterprise certificate template or a Windows 2008 Enterprise certificate template.

Likewise, this distinction has been made accordingly in the certificate template management console (certtmpl.msc) via a "Minumim Supported CAs" column.

Starting with Windows Server 2012, the "Minimum Supported CAs" column has been replaced by a "Schema Version" column. Correctly, the generations of certificate templates are therefore also referred to as the schema version.

At the same time, the "Compatibility" tab was introduced in the details of the certificate templates. This can now be used to select a combination of the minimum operating system version to be supported for the certification authority, as well as for the requesting clients.

Based on the selection, functions supported in this operating system version are then unlocked.

Version 1 Certificate Template Details

Version 1 certificate templates were introduced with Windows 2000 Server.

These certificate templates are mainly characterized by their limitations:

  • They cannot be changed. Only the permissions can be edited.
  • They do not support automatic application (autoenrollment).
  • They are also restricted to the cryptographic functions available in Windows 2000 and Windows Server 2003. Thus, for example, the use of Key Storage Providers (KSP) is not possible.

Version 2 Certificate Template Details

Version 2 certificate templates were introduced with Windows Server 2003.

They are characterized by the following innovations:

  • This type of certificate templates could be edited for the first time and adapted accordingly. Thus, all self-created certificate templates correspond to version 2 by default.
  • In addition, this template type supports automatic application (autoenrollment).

Just like the version 1 certificate templates, they are restricted to the cryptographic functions available in Windows 2000 and Windows Server 2003. Thus, the use of Key Storage Providers (KSPs) is not possible here either.

Version 3 Certificate Template Details

Version 3 certificate templates were introduced with Windows Server 2008.

They are characterized by the following innovations:

  • Cryptography Next Generation (CNG) is supported for the first time. This enables the use of Key Storage Providers (KSP).
  • For Network Access Protection (NAP) support, the option was added that the certification authority does not write issued certificates to the certification authority database, since this feature would issue many short-lived certificates, and this was expected to cause a large growth of the certification authority database.
  • For online responder support (OCSP), the option that the certificate authority should not write certificate revocation information to issued certificates has been added (id-pkix-ocsp-nocheck). This is useful for OCSP signing certificates, the revocation status of an OCSP signing certificate would in turn point to the OCSP - creating an endless chain.

We recommend that you enable the id-pkix-ocsp-nocheck (1.3.6.1.5.5.7.48.1.5) extension in the OCSP signing certificate so that no revocation checking is performed on the OCSP signing certificate. This ensures that a CRL is not downloaded to validate the OCSP signing certificate.

How Certificate Revocation Works (Microsoft)

Version 4 Certificate Template Details

Version 4 certificate templates were introduced with Windows Server 2012.

They are characterized by the following innovations:

  • The Trusted Platform (TPM) Key Attestation makes it possible to ensure that a private key was actually protected with a TPM. Even with version 3 certificate templates, keys could be protected by a TPM by selecting the "Microsoft Platform Key Storage Provider", but the certification authority had no way of cryptographically verifying this.
  • Support for Key-based Renewal.
  • Renewal with the same key.
  • Exhibit guidelines may be provided by the applicant.

Related links:

External sources

en_USEnglish