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
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 regulationsto 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 downloaded via GitHub and can be used free of charge. Professional maintenance is also offered.
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:
Use signed policies to protect Windows Defender Application Control against tampering (Microsoft Corpotation)
[...]
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.
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.
Related links:
- Use of undefined Relative Distinguished Names (RDN) in issued certificates
- Description of the necessary configuration settings for the "Common PKI" certificate profile
- Umlauts in certification authority certificates
- Installation of a new certification authority certificate fails with error code "ERROR_INVALID_PARAMETER".
External sources
- CryptEncodeObjectEx function (wincrypt.h) (Microsoft Corporation)
- CERT_RDN_ATTR structure (wincrypt.h) (Microsoft Corporation)
- ITU T.61 (Wikipedia)
- Unicode (Wikipedia)
- Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile (Internet Engineering Task Force, IETF)
- What is the difference between UTF-8 and Unicode? (Discussion on Stack Overflow)
- Difference between CaPolicy.inf with ForceUTF8=1 versus certutil -setreg ca\forceteletex +0x20 (Discussion on Microsoft TechNet Forums)
4 thoughts on “Zeichenkodierung im Subject Distinguished Name von Zertifikatanforderungen und ausgestellten Zertifikaten”
Comments are closed.