Heutzutage eher eine Kuriosität als wirklich praxisrelevant, aber es kommt hin und wieder vor, dass man Zertifikatanforderungen erhält, welche mehr als einen gemeinsamen Namen (Common Name) im Betreff (Subject) beinhalten. Auch wenn es erstaunlich wirken mag, dies ist durchaus möglich und auch RFC-konform.
Das Subject eines Zertifikats wird aus einem X.500 Distinguished Name (DN) gebildet:
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 wiederum erlauben (bzw. untersagen nicht) die mehrfache Eintragung der gleichen Schlüsselwörter.
Die Zertifikatvorlage muss die Beantragung der Identität durch den Antragsteller erlauben, damit ein solches Zertifikat entsprechend der Anforderung ausgestellt wird. Andernfalls würde das Subject durch die Zertifizierungsstelle mit der im Active Directory hinterlegten Identität des Antragstellers überschrieben werden.
Betrachtungen speziell betreffend HTTPS
Speziell für HTTP über SSL (HTTPS) spricht das RFC 2818 sogar explizit von mehreren Identitäten:
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
Browser, die Subjects in SSL-Zertifikaten noch akzeptieren, können entsprechend sogar mit mehreren Common Names in Zertifikaten umgehen.
Es sollte jedoch beachtet werden, dass der Common Name gemäß des gleichen RFC generell nicht mehr verwendet werden, und stattdessen die Subject Alternative Name (SAN) Erweiterung bevorzugt werden sollte:
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
Browser wie Google Chrome und der darauf basierende neue Microsoft Edge lehnen Zertifikate sogar mittlerweile ab, wenn diese keine Subject Alternative Name Erweiterung beinhaltet. Ist jedoch eine solche vorhanden, wird gemäß RFC 2818 das Subject ignoriert.
Betrachtungen speziell betreffend ADCS
Grundsätzlich kann die Zertifizierungsstelle mit solchen Zertifikatanforderungen umgehen. Der Common Name ist jedoch eines der indexierten Datenbankfelder und geht davon aus, dass es nur einen solchen gibt. Mehrere Common Names werden durch einen Zeilenumbruch (Line Feed, LF, \n) getrennt, was unter Anderem zu folgenden Schwierigkeiten führen kann:
- Die betreffenden Zertifikate werden bei Datenbank-Suchen nach einem bestimmten Common Name nicht gefunden.
- Die Zeilenumbrüche verfälschen auch Datenbankabfragen, da die ausgegebenen Zeilen ebenfalls Zeilenumbrüche enthalten.
Fazit
Es ist technisch möglich und auch RFC-konform, mehrere Common Names innerhalb eines Zertifikats einzutragen. In der Praxis ist es jedoch schon vorgekommen, dass Zertifikatmanager Anwendungen zur Prüfung einer Zertifikatanforderung einsetzen, welche hiermit nicht umgehen können, sodass hier unbemerkt weitere Identitäten beantragt werden könnten. Es sollte bei der Prüfung einer Zertifikatanforderung also immer auf diesen Umstand geachtet werden.
In Hinsicht auf zu erwartende Schwiergkeiten mit der Zertifizierungsstelle sollten solche Zertifikate jedoch vermieden werden. Die Beantragung von mehreren Common Names und auch anderer Relative Distinguished Names (RDNs) kann man wirksam mit dem TameMyCerts Policy Modul für Microsoft Active Directory Certificate Services unterbinden.
Speziell für HTTPS gilt, dass der Common Name überhaupt nicht mehr zum Einsatz kommen sollte.
Weiterführende Links:
Externe Quellen
- 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)
Deutsch 
English