De nos jours, cela relève davantage de la curiosité que de la pratique, mais il arrive parfois que l'on reçoive des demandes de certificats contenant plus d'un nom commun (Common Name) dans l'objet (Subject). Même si cela peut paraître étonnant, cela est tout à fait possible et conforme à la norme RFC.
Le sujet d'un certificat est constitué d'un X.500 Distinguished Name (DN) :
Lorsqu'il n'est pas vide, le champ sujet DOIT contenir un nom distingué X.500 (DN).
RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
X.500 Distinguished Names, quant à lui, autorise (ou n'interdit pas) l'enregistrement multiple des mêmes mots-clés.
Le modèle de certificat doit permettre la demande d'identité par le demandeur afin qu'un tel certificat soit délivré conformément à la demande. Dans le cas contraire, le sujet serait écrasé par l'autorité de certification avec l'identité du demandeur enregistrée dans l'Active Directory.
Considérations spécifiques à HTTPS
Connaissez-vous TameMyCerts? TameMyCerts est un add-on pour l'autorité de certification Microsoft (Active Directory Certificate Services). Il étend la fonction de l'autorité de certification et permet de Application de la réglementationIl s'agit d'un logiciel de gestion des certificats qui permet d'automatiser l'émission de certificats en toute sécurité. TameMyCerts est unique dans l'écosystème Microsoft, a déjà fait ses preuves dans d'innombrables entreprises du monde entier et est disponible sous une licence libre. Il peut téléchargé via GitHub et être utilisé gratuitement. Une maintenance professionnelle est également proposée.
Spécialement pour HTTP sur SSL (HTTPS), le RFC 2818 parle même explicitement d'identités multiples :
Sinon, le champ Nom commun (le plus spécifique) dans le champ Sujet du certificat DOIT être utilisé. [...] Si plus d'une identité d'un type donné est présente dans le certificat (par exemple, plus d'un nom de dNSName, une correspondance dans n'importe lequel de l'ensemble est considérée comme acceptable).
RFC 2818 - HTTP sur TLS
Les navigateurs qui acceptent encore les Subjects dans les certificats SSL peuvent même gérer plusieurs Common Names dans les certificats.
Il convient toutefois de noter que, conformément au même RFC, le nom commun ne doit généralement plus être utilisé et que l'extension Subject Alternative Name (SAN) doit être privilégiée à la place :
Bien que l'utilisation du nom commun soit une pratique existante, elle est dépréciée et les autorités de certification sont encouragées à utiliser le dNSName à la place.
RFC 2818 - HTTP sur TLS
Les navigateurs comme Google Chrome et le nouveau Microsoft Edge basé sur ce dernier refusent même les certificats s'ils ne contiennent pas d'extension Subject Alternative Name. Mais si une telle extension est présente, le Subject est ignoré conformément à la RFC 2818.
Considérations spécifiques à l'ADCS
En principe, l'autorité de certification peut gérer de telles demandes de certificat. Cependant, le nom commun est l'un des champs indexés de la base de données et part du principe qu'il n'y en a qu'un seul. Plusieurs noms communs sont séparés par un saut de ligne (Line Feed, LF, \n), ce qui peut notamment entraîner les difficultés suivantes :
- Les certificats concernés ne sont pas trouvés lors des recherches dans la base de données pour un nom commun donné.
- Les retours à la ligne faussent également les requêtes de base de données, car les lignes affichées contiennent également des retours à la ligne.
Conclusion
Il est techniquement possible et conforme aux RFC d'inscrire plusieurs noms communs dans un certificat. Dans la pratique, il est toutefois déjà arrivé que des gestionnaires de certificats utilisent des applications pour vérifier une demande de certificat qui ne peuvent pas s'en charger, de sorte que d'autres identités pourraient être demandées sans que l'on s'en aperçoive. Il faut donc toujours faire attention à ce point lors de la vérification d'une demande de certificat.
Il est toutefois préférable d'éviter ce type de certificats en raison des difficultés qu'ils pourraient entraîner avec l'autorité de certification. La demande de plusieurs noms communs, ainsi que d'autres noms communs, ne doit pas être considérée comme un obstacle. Noms distinctifs relatifs (RDN) il est possible d'agir efficacement avec le Module de politique TameMyCerts pour Microsoft Active Directory Certificate Services empêcher.
Pour HTTPS en particulier, le nom commun ne devrait plus être utilisé du tout.
Liens complémentaires :
Sources externes
- RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile (Internet Engineering Task Force)
- RFC 2818 - HTTP sur TLS (Internet Engineering Task Force)
Français 
Deutsch 
English