En supposant que la propriété du Nom Alternatif du Sujet (SAN) d'un certificat SSL contient deux noms DNS
domain.examplehost.domain.examplemais le Nom Commun (CN) est défini pour un seul des deux : CN=domain.example.
host.domain.example, est demandé?Plus précisément, comment OpenSSL 0.9.8b+ gère-t-il ce scénario?
Cela dépend de l'implémentation, mais la règle générale est que le domaine est vérifié par rapport à tous les SAN et au nom commun. Si le domaine est trouvé là-bas, alors le certificat est OK pour la connexion.
RFC 5280, section 4.1.2.6 dit "Le nom du sujet PEUT être transporté dans le champ subject et/ou l'extension subjectAltName". Cela signifie que le nom de domaine doit être vérifié à la fois par rapport à l'extension SubjectAltName et la propriété Subject (notamment son paramètre de nom commun) du certificat. Ces deux endroits se complètent mutuellement, ne se dupliquent pas. Et SubjectAltName est un endroit approprié pour ajouter des noms supplémentaires, tels que www.domain.example ou www2.domain.example
Mise à jour : selon RFC 6125, publié en 2011, le validateur doit d'abord vérifier SAN, et si SAN existe, alors CN ne doit pas être vérifié. Notez que le RFC 6125 est relativement récent et qu'il existe encore des certificats et des AC qui délivrent des certificats incluant le nom de domaine "principal" dans CN et des noms de domaine alternatifs dans SAN. En d'autres termes, en excluant CN de la validation si SAN est présent, vous pouvez refuser un certificat par ailleurs valide.
Pour être absolument correct, vous devriez mettre tous les noms dans le champ SAN.
Le champ CN devrait contenir un Nom du Sujet et non un nom de domaine, mais lorsque Netscape a découvert cette chose SSL, ils ont omis de définir son marché le plus important. En réalité, il n'y avait pas de champ de certificat défini pour l'URL du serveur.
Cela a été résolu en mettant le domaine dans le champ CN, et de nos jours, l'utilisation du champ CN est obsolète, mais encore largement utilisée. Le CN ne peut contenir qu'un seul nom de domaine.
Les règles générales pour cela : CN - mettez ici votre URL principal (pour la compatibilité) SAN - mettez tous vos domaines ici, répétez le CN car il n'est pas à sa bonne place, mais il est utilisé pour cela...
Si vous trouvez une implémentation correcte, les réponses à vos questions seront les suivantes:
Ce paramétrage a-t-il une signification spéciale ou des avantages / inconvénients par rapport à la définition des deux CNs ? Vous ne pouvez pas définir les deux CN, car le CN ne peut contenir qu'un seul nom. Vous pouvez créer deux certificats CN simples au lieu d'un certificat CN+SAN, mais vous aurez besoin de 2 adresses IP pour cela.
Que se passe-t-il côté serveur si l'autre, hôte.domaine.tld, est demandé ? Peu importe ce qui se passe côté serveur.
En résumé: Lorsqu'un navigateur client se connecte à ce serveur, le navigateur envoie des paquets chiffrés, qui sont chiffrés avec la clé publique du serveur. Le serveur déchiffre le paquet, et s'il peut le déchiffrer, alors il était chiffré pour le serveur.
Le serveur ne sait rien du client avant le déchiffrement, car seule l'adresse IP n'est pas chiffrée à travers la connexion. C'est pourquoi vous avez besoin de 2 adresses IP pour 2 certificats. (Oubliez SNI, il y a encore beaucoup de XP là-bas maintenant.)
Côté client, le navigateur reçoit le CN, puis le SAN jusqu'à ce que tous soient vérifiés. Si l'un des noms correspond au site, alors la vérification de l'URL est effectuée par le navigateur. (ici je parle de la vérification du certificat, bien sûr, beaucoup de demandes et de réponses OCSP, CRL, AIA circulent sur le réseau à chaque fois.)
Je vois que personne n'a encore mentionné la section des Exigences de base. Je trouve qu'elles sont importantes.
Q: SSL - Comment les noms communs (CN) et les noms alternatifs du sujet (SAN) fonctionnent-ils ensemble?
R: Pas du tout. S'il existe des SAN, le CN peut être ignoré. -- Du moins si le logiciel qui effectue la vérification adhère très strictement aux Exigences de base du CABForum.
(Cela signifie que je ne peux pas répondre à l'"Édition" de votre question. Seulement à la question initiale.)
Exigences de base du CABForum, v. 1.2.5 (en date du 2 avril 2015), page 9-10:
9.2.2 Champs du nom distinctif du sujet
a. Champ du nom commun du sujet
Champ du certificat : sujet : nomCommun (OID 2,5,4,3)
Requis/Facultatif: Obsolète (déconseillé, mais non interdit)
Contenu: Si présent, ce champ DOIT contenir une seule adresse IP ou un nom de domaine pleinement qualifié qui est l'une des valeurs contenues dans l'extension subjectAltName du certificat (voir la section 9.2.1).
RFC 2818: HTTP Over TLS, 2000, Section 3.1: Identité du serveur:
Si une extension subjectAltName de type dNSName est présente, elle DOIT être utilisée comme identité. Sinon, le champ (le plus spécifique) Nom commun dans le champ Sujet du certificat DOIT être utilisé. Bien que l'utilisation du Nom commun soit une pratique existante, elle est obsolète et les Autorités de certification sont encouragées à utiliser le dNSName à la place.
RFC 6125: Représentation et vérification de l'identité de service d'application basée sur domaine dans l'infrastructure de clés publiques Internet en utilisant des certificats X.509 (PKIX) dans le contexte de la sécurité de la couche de transport (TLS), 2011, Section 6.4.4: Vérification des noms communs:
[...] si et seulement si les identifiants présentés n'incluent pas un DNS-ID, SRV-ID, URI-ID, ou tout type d'identifiant spécifique à une application soutenu par le client, alors le client PEUT en dernier recours vérifier pour une chaîne dont la forme correspond à celle d'un nom de domaine DNS pleinement qualifié dans un champ Nom commun du champ sujet (c'est-à-dire un CN-ID).
Mise à jour ajoutée le 27 avril 2023.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
