Nowadays rather a curiosity than really relevant in practice, but it does happen from time to time that you receive certificate requests that contain more than one common name in the subject. Even though it may seem surprising, this is quite possible and also RFC compliant.
The subject of a certificate is formed from an X.500 Distinguished Name (DN):
Where it is non-empty, the subject field MUST contain an X.500 distinguished name (DN).
RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
X.500 Distinguished Names, on the other hand, allow (or do not prohibit) multiple entries of the same keywords.
The certificate template must allow the identity to be requested by the requester so that such a certificate is issued in accordance with the requirement. Otherwise, the subject would be overwritten by the certification authority with the applicant's identity stored in the Active Directory.
Considerations specifically regarding HTTPS
Specifically for HTTP over SSL (HTTPS), RFC 2818 even explicitly talks about multiple identities:
Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. [...] If more than one identity of a given type is present in the certificate (e.g., more than one dNSName name, a match in any one of the set is considered acceptable).
RFC 2818 - HTTP over TLS
Browsers that still accept subjects in SSL certificates can even handle multiple common names in certificates accordingly.
It should be noted, however, that the Common Name should generally be discontinued according to the same RFC, and the Subject Alternative Name (SAN) extension should be preferred instead:
Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead.
RFC 2818 - HTTP over TLS
Browsers such as Google Chrome and the new Microsoft Edge, which is based on it, now even reject certificates if they do not contain a Subject Alternative Name extension. However, if such an extension is present, the subject is ignored according to RFC 2818.
Considerations specifically concerning ADCS
In principle, the certification authority can handle such certificate requests. However, the Common Name is one of the indexed database fields and assumes that there is only one. Multiple Common Names are separated by a line feed (LF, \n), which can lead to the following difficulties, among others:
- The certificates in question are not found in database searches for a specific common name.
- The line breaks also distort database queries, since the output lines also contain line breaks.
Conclusion
It is technically possible and also RFC-compliant to enter multiple common names within a certificate. In practice, however, it has happened that certificate managers use applications to check a certificate request that cannot handle this, so that additional identities could be requested unnoticed. Attention should therefore always be paid to this circumstance when checking a certificate request.
However, in view of the expected difficulties with the certification authority, such certificates should be avoided. The application for multiple common names and also for other Relative Distinguished Names (RDNs) you can effectively use the TameMyCerts Policy Module for Microsoft Certification Authority prevent.
Especially for HTTPS, the common name should not be used at all.
Related links:
External sources
- RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile (Internet Engineering Task Force)
- RFC 2818 - HTTP Over TLS (Internet Engineering Task Force)
English 
Deutsch