Character encoding in the Subject Distinguished Name of certificate requests and issued certificates

Usually, the encoding of characters and strings in certificates is not a topic of great interest to the users of a PKI. However, there are cases where the default settings of the certification authority do not provide the desired results.

For the Relative Distinguished Names (RDNs) within the Subject Distiguished Name (Subject DN), which is mapped as type "DirectoryString", the relevant RFC 5280 provides the following variants for mapping strings.

DirectoryString ::= CHOICE {
         teletexString TeletexString (SIZE (1..MAX)),
         printableString PrintableString (SIZE (1..MAX)),
         universalString UniversalString (SIZE (1..MAX)),
         utf8String UTF8String (SIZE (1..MAX)),
         bmpString BMPString (SIZE (1..MAX)) }

However, a closer look shows that predominantly only two of the five possible data types are relevant:

CAs conforming to this profile MUST use either the PrintableString or UTF8String encoding of DirectoryString [...].
RFC 5280

Coding relevant in the context

For us as users of a Microsoft PKI, the following codes or terms are usually of interest:

Type	Figure	Description
ASN.1 PrintableString	printableString	Subset of the ASCII character set (only "printable" characters). Only a few special characters can be mapped, e.g. no Umlauts.
Unicode	bmpString	International standard for encoding strings. Flexible encoding of the included characters, can use UTF-8 or UTF-16 among others. Windows interprets Unicode as UTF-16, Linux as UTF-8, which can lead to different behavior.
UTF-8	utf8String	One of several ways to map characters into Unicode strings.

The countryName RDN should only contain the two-character country codes specified in ISO3166, which are always composed of ASCII characters, and is therefore always encoded as ASN.1 PrintableString, since there is no need for extended encoding.

Inspect certificates and certificate requests

For both certificates and certificate requests, it is relatively easy to check which encodings the respective RDNs use.

certutil -asn {filename}

A more convenient option is offered by the ASN.1 Editor from PKI Solutions.

Example printableString

Example bmpString (Unicode)

Example utf8String

The settings

The Microsoft Certification Authority offers the possibility to influence the encoding of characters and character encodings within the scope of certificate issuance. The corresponding settings can be found in the following registration key on the certification authority:

HKLM:\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\{common-name-of-the-certification-authority}\ForceTeletex

The settings in ForceTeletex are indicated by the flag CRLF_REBUILD_MODIFIED_SUBJECT_ONLY (under CA\CRLFlags), which causes the requested Subject DN to be transferred 1:1 to the issued certificate, is overridden.

The set flags can be read out with the following command line command:

certutil -v -getreg CA\ForceTeletex

Individual flags can be enabled with the following command line commands:

 certutil -setreg CA\ForceTeletex +{FLAG}

Flags can also be deactivated.

certutil -setreg CA\ForceTeletex -{FLAG}

The Certification Authority service must then be restarted for the changes to be applied.

The following flags can be set. You then decide which flags will be passed to the function CryptEncodeObjectEx be passed on.

Flag	Value	Enabled by default (Windows 2012 until 2022)
ENUM_TELETEX_OFF	0	no
ENUM_TELETEX_ON	1	no
ENUM_TELETEX_AUTO	2	yes
ENUM_TELETEX_MASK	0xF	no
ENUM_TELETEX_UTF8	0x10	yes
ENUM_TELETEX_FORCEUTF8	0x20	no

ENUM_TELETEX_UTF8 (0x10)

If this flag is activated, at CryptEncodeObjectEx the flag CRYPT_UNICODE_NAME_ENCODE_ENABLE_UTF8_UNICODE_FLAG is passed.

This flag is applicable when encoding an X509_UNICODE_NAME. When set, CERT_RDN_UTF8_STRING is selected instead of CERT_RDN_UNICODE_STRING.

Thus, for a submitted certificate request where an RDN is Unicode encoded (...and thus the character encoding interpretation is not unique), this setting causes the UTF-8 character encoding to be used in the issued certificate if the flag for the RDN is enabled.

If, on the other hand, an RDN is encoded in printableString, this encoding is retained in the issued certificate.

ENUM_TELETEX_FORCEUTF8 (0x20)

If this flag is activated, at CryptEncodeObjectEx the flag CRYPT_UNICODE_NAME_ENCODE_FORCE_UTF8_UNICODE_FLAG is passed.

This flag is applicable when encoding an X509_UNICODE_NAME. When set, CERT_RDN_UTF8_STRING is selected instead of CERT_RDN_PRINTABLE_STRING for directory string types. Also, this flag enables CRYPT_UNICODE_NAME_ENCODE_ENABLE_UTF8_UNICODE_FLAG.

If the flag is set, it thus also automatically activates the effect of ENUM_TELETEX_UTF8.

Thus, this setting causes the UTF-8 character encoding to always be used in the issued certificate for a submitted certificate request.

Contrary to the original documentation from Microsoft, it is also possible for the Conformity to ISIS-MTT or Common PKI not necessary to activate the ENUM_TELETEX_FORCEUTF8 flag.

Testing the behavior

Suitable for testing is the PSCertificateEnrollment PowerShell Module very well. It uses ASN.1 PrintableString by default or Unicode if the RDN contains corresponding characters. A switch to use UTF-8 is also available.

# Result: printableString (PRINTABLE_STRING)
New-CertificateRequest -Subject "CN=Max Meier"

# Result: bmpString (UNICODE_STRING)
New-CertificateRequest -Subject "CN=Max Müller"

# Result: utf8String (UTF8_STRING)
New-CertificateRequest -Subject "CN=Max Meier" -SubjectEncoding utf8

# Result: utf8String (UTF8_STRING)
New-CertificateRequest -Subject "CN=Max Müller" -SubjectEncoding utf8

The tests led to the following result:

Coding in the certificate request	Contains special characters	...UTF8 flag enabled	...FORCEUTF8 flag enabled	Coding in the issued certificate
printableString	no	no	no	printableString
printableString	no	yes	no	printableString
printableString	no	no	yes	utf8String
printableString	no	yes	yes	utf8String
bmpString (Unicode)	yes	no	no	bmpString (Unicode)
bmpString (Unicode)	yes	yes	no	utf8String
bmpString (Unicode)	yes	no	yes	utf8String
bmpString (Unicode)	yes	yes	yes	utf8String
utf8String	no	no	no	bmpString (Unicode)
utf8String	yes	no	no	utf8String
utf8String	no	yes	no	utf8String
utf8String	no	no	yes	utf8String
utf8String	no	yes	yes	utf8String

The tests thus confirm the documented and correspondingly expected behavior.

Thus, how the incoming certificate request is encoded is also important. For example, encode certreq.exe and the Microsoft Management Console (MMC) automatically encode all RDNs (except the countryName) in UTF-8. Accordingly, the RDN in the issued certificate will also be encoded in UTF-8 in most cases.

Change behavior for certreq.exe

If a certificate request is created with certreq.exe, using the X500NameFlags directive to force a fallback to printableString or Unicode.

For this purpose, the following line is entered in the corresponding .inf file:

[NewRequest]
X500NameFlags = 0x100000 # CERT_NAME_STR_DISABLE_UTF8_DIR_STR_FLAG

Compatibility issues

Some applications do not understand UTF-8

The original recommendations from Microsoft from the year 2003 for conformity to the ISIS-MTT or Common PKI Standard force the use of UTF8 even if the respective Subject Relative Distinguished Name (RDN) does not require it.

The Common PKI Standard explicitly points out possible compatibility problems with UTF-8 and as it shows there are with Windows Defender Application Control (WDAC) at least one Microsoft product, which is also incompatible with this.

Boot failure (blue screen) may occur if your signing certificate does not follow these rules:
[...]
Don't use UTF-8 encoding for certificate fields, like 'subject common name' and 'issuer common name'. These strings must be encoded as PRINTABLE_STRING, IA5STRING or BMPSTRING.
Use signed policies to protect Windows Defender Application Control against tampering (Microsoft Corpotation)

Thus, it is important here that for the WDAC signing certificate the certificate request is already created in the correct encoding, only with ASCII characters in the RDN and not with a tool that uses UTF-8 for the encoding of the RDNs in the default setting.

The certification authority must not have set the ENUM_TELETEX_FORCEUTF8 flag when issuing the certificate. Likewise, the RDNs for Subject DN and Issuer DN must not be set. of the certification authority certificates in the certificate chain must not be encoded in UTF-8.

For Subject DN and Issuer DN of all certificates in the certificate chain, it also applies that no characters may be contained that cannot be mapped with ASN.1 PrintableString. This includes, for example, the use of special characters such as Umlauts off.

Formation of the certificate chain (would) no longer be possible

For certification authorities issuing other certification authority certificates (if one intends to renew the certification authority certificates of a certification authority with the same key instead of providing a new certification authority as a replacement), one should refrain from making changes to the behavior for the character encoding for issued certificates, as the certification authorities may not accept the certificates issued.

Conclusion

In summary, the default settings of the Microsoft Certification Authority automatically ensure that the certificates issued are compatible with both RFC 5280 and ISIS-MTT or Common PKI. Changing the settings is recommended from time to time, but is usually not necessary.

Functionality summarized in the default setting

The default settings can be roughly summarized as follows:

If an RDN is encoded in printableString in the submitted certificate request, it is also so in the issued certificate.
If an RDN is encoded in UTF-8 in the submitted certificate request, it is also so in the issued certificate.
If an RDN is encoded in Unicode in the submitted certificate request, it will be encoded as UTF-8 in the issued certificate.