Internationalized Domain Names (IDNs) have been officially supported since Windows Server 2012 as part of the Certificate Authority and associated components.
However, if you want to use them in your certification authority certificates, there are some specifics to consider.
The use of umlauts and other special characters in certification authority certificates can lead to compatibility problems. For example Windows Defender Application Control (WDAC) only compatible to ASN.1 PrintableString. It is therefore highly recommended to avoid using any special characters in certification authority certificates.
Umlauts in the applicant name (subject) of the certification authority certificate
Umlauts in the subject name can technically be used without any problems. However, the encoding of the subject / issuer name in this case will be in UTF-8 instead of ASN.1 PrintableString, since the latter character set cannot represent the umlauts.
Installation via Server Manager
During the installation of the certificate authority, you will receive a warning message if you want to use a Common Name (CN) or Distinguished (DN) Name Suffix that contains an umlaut.
The CA information contains characters that require extended name encoding in the certificate. Certificates containing this name encoding conform to accepted standards, but may be incompatible with non-compliant applications. Do you want to use these fields?
As the warning message already states, when using umlauts there is always a risk that it will not be understood by all applications. The application name is not encoded in PrintableString but in UTF-8 when umlauts are used. Therefore, either a careful check of all applications that will use the PKI should be made for compatibility, or it is better not to use umlauts.
Installation via Windows PowerShell
If the certification authority is installed via Windows PowerShell, however, it must be noted that the same message is also triggered here and can lead to the role configuration being aborted.
For the Install-AdcsCertificationAuthority command, there is the -IgnoreUnicode switch, which is the equivalent of acknowledging the warning in the graphical interface.
Install-AdcsCertificationAuthority [...] -IgnoreUnicode
Installation via Windows Powershell script
If you install the certificate authority via script, you must also pay attention to how the script file is coded.
PowerShell files are usually (if created with the PowerShell ISE) encoded with UTF-8 with Byte Order Mark (BOM). Only in this encoding are orbits correctly applied in the requester name.
The above warning is not triggered if the file is encoded in UTF-8 without BOM, but the umlauts are also not transferred correctly to the certificate request.
Umlauts in certificate policies of the certification authority certificate
Certificate policies can also contain umlauts (example: "Certificate Authority Operation Statement").
Here, too, the applications that are to use the PKI must also understand the umlauts. If it is not clear whether all applications can handle them, the use of umlauts should be avoided.
In order for such policies to appear in the certificate authority's certificate request, they are entered into the capolicy.inf file in the PolicyStatementExtension section, which is applied during the installation of the certificate authority role.
The capolicy.inf can handle umlauts in the PolicyStatementExtension if the file is ANSI encoded. If it is encoded in UTF-8 without BOM, the umlauts are corrupted. If the file is encoded in UTF-8 with BOM, the capolicy.inf will no longer be understood by the installation routine and accordingly will not be applied.
The designation "ANSI" corresponds to the character code Windows-1252 (Latin-1, Western European) in the Windows ecosystem.
English 
Deutsch
3 thoughts on “Umlaute in Zertifizierungsstellen-Zertifikaten”
Comments are closed.