Description of the necessary configuration settings for the "Common PKI" certificate profile

Author Uwe Gradenegger Posted on Updated on Categories Certification Authority installation, Certificate usage Tags RFC 5280, Common PKI, UTF-8, capolicy.inf, Key usage, Windows Defender Application Control, Subject distinguished name, ISIS-MTT, PrintableString, Issuer distinguished name

Below is a description of the configuration settings required to ensure that a certificate hierarchy based on Active Directory Certificate Services complies with the Common PKI (formerly known as ISIS-MTT) standard.

The "Common PKI" standard is described as follows.

The Common PKI specification is a profile of internationally used and recognized standards for electronic signatures, encryption and public key infrastructures. The Common PKI takes into account all business-relevant electronic signatures up to the qualified electronic signature according to the German Signature Act (SigG), which can be used to comply with the formal requirements in private and administrative law. The specification also includes security functionalities for secure e-mail with different security levels and compatibility with internationally accepted standards. This enables the rapid availability of interoperable security products both at the certification service provider level and at the user level (client side).

— https://de.wikipedia.org/wiki/Common_PKI

Overview

Do you know TameMyCerts? TameMyCerts is an add-on for the Microsoft certification authority (Active Directory Certificate Services). It extends the function of the certification authority and enables the application of rule sets to realize the secure automation of certificate issuance. TameMyCerts is unique in the Microsoft ecosystem, has already proven itself in countless companies around the world and is available under a free license. It can be downloaded via GitHub and used free of charge. Professional maintenance is also offered.

The following configuration requirements for Microsoft certification authorities are derived from the Common PKI:

  • The "Key Usage" extension of the certification authority certificates must not include the "DigitalSignature" key usage (see also RFC 5280 ).
  • The "Key Usage" extension of each certificate in the hierarchy must be marked as critical.
  • The Subject Distinguished Name of each certificate in the hierarchy should be encoded in UTF-8 instead of Unicode to allow the use of special characters such as umlauts . This is the default setting of the Microsoft certification authority since at least Windows Server 2012 R2.

Strings MAY be encoded as PrintableString in order to ensure a better interoperability with legacy applications. If a string cannot be represented in the PrintableString character set, UTF8String encoding MUST be used.

— Common PKI Part 1 - Page 12

This extension MUST always be included in CA and end entity certificates and MUST be marked critical.
CA certificates: the keyCertSign bit MUST be set. Additionally, the crlSign bit MAY be set too, if the CA uses the corresponding key to sign CRLs too. Other bits MUST NOT be set.

— Common PKI Part 1 - Page 22

If the subject public key is only to be used for verifying signatures on certificates and/or CRLs, then the digitalSignature and nonRepudiation bits SHOULD NOT be set.

— RFC 5280, 4.2.1.3

The Common PKI standard further specifies that Relative Distinguished Names (RDNs) must be no longer than 64 characters, which is the default behavior of the Microsoft certification authority, but could be changed .

Implementation

The implementation differs depending on the certification authority role:

  • Special settings for root certification authorities (root CA).
  • Special settings for offline certification authorities (whether root, intermediate or subordinate certification authority).
  • Settings for all types of certification authorities.

Special settings for root certification authorities

This step must take place before the root certification authority is installed, or before the root certification authority certificate is renewed. However, a renewal of the root certification authority certificate requires that this must be communicated to all subscribers, since it technically involves the establishment of a new certification authority hierarchy.

Root certification authorities not only issue certificates for other certification authorities, but also issue their own.

To ensure that the "Key Usage" extension of the own certification authority certificate is marked as critical and does not include the "DigitalSignature" key usage, the capolicy.inf file of the root certification authority must be extended by the following section.

[Extensions] 
2.5.29.15 = AwIBBg== 
Critical = 2.5.29.15

Contrary to other instructions, it is not necessary to explicitly configure the encoding of the Subject Distinguished Name and Issuer Distinguished Name of root certification authorities to UTF-8. This can lead to compatibility issues when verifying the certificate chain.

In general, only characters that can be encoded with ASN.1 PrintableString (effectively all displayable ASCII characters) should be used for the Subject Distinguished Name of a certification authority.

Special settings for offline certification authorities

Offline certification authorities do not know certificate templates, so they have to fall back on default values.

To ensure that the "Key Usage" extension is marked as critical in certificates issued by the certification authority and that it does not include the "DigitalSignature" key usage, the following command line command must be executed on each offline certification authority.

certutil -setreg policy\EditFlags -EDITF_ADDOLDKEYUSAGE

Command prompt: certutil -setreg policy\EditFlags -EDITF_ADDOLDKEYUSAGE removes EDITF_ADDOLDKEYUSAGE from the EditFlags

After the change, the certification authority service must be restarted for the changes to be applied.

Command prompt: net stop certsvc & net start certsvc restarts the Active Directory Certificate Services service

Settings for all types of certification authorities

Contrary to the official guide from Microsoft , it is not necessary and in some cases even harmful to force all Relative Distinguished Names (RDNs) in issued certificates to be encoded with UTF-8 by setting the ENUM_TELETEX_FORCEUTF8 flag . Instead, the flag ENUM_TELETEX_UTF8 (without "FORCE") should be set, which is already the case in the default setting.

This means that Relative Distinguished Names (RDNs) that only contain ASCII characters are automatically encoded in ASN.1 PrintableString (provided they were already encoded in this way in the submitted certificate request), which is compliant with Common PKI. If an RDN also contains other special characters, it is automatically mapped to UTF-8 in the issued certificate.

External sources