Un certificat SSL générique doit-il sécuriser à la fois le domaine racine et les sous-domaines?
Je pose cette question, car Comodo me dit qu'un certificat générique pour * .example.com sécurisera également le domaine racine example.com. Ainsi, avec un seul certificat, my.example.com et example.com sont sécurisés sans avertissement à partir d'un navigateur.
Cependant, ce n'est pas le cas avec le certificat qui m'a été fourni. Mes sous-domaines sont bien sécurisés et ne donnent pas d'erreur, mais le domaine racine génère une erreur dans le navigateur, disant que l'identification ne peut pas être vérifiée.
Lorsque je compare ce certificat à d'autres scénarios similaires, je constate que dans les scénarios qui fonctionnent sans erreur, le nom alternatif du sujet (SAN) répertorie à la fois * .example.com et example.com, tandis que le certificat récent de Comodo ne répertorie que *. exemple.com comme nom commun et NON exemple.com comme autre nom de sujet.
Quelqu'un peut-il confirmer/préciser que le domaine racine doit être répertorié dans les détails SAN s'il doit également être sécurisé correctement?
Quand je lis ceci: http://www.digicert.com/subject-alternative-name.htm Il semble que le SAN doit lister les deux pour fonctionner comme j'en ai besoin. Quelle est votre expérience?
Merci beaucoup.
Il existe une certaine incohérence entre les implémentations SSL sur la façon dont elles correspondent aux caractères génériques, mais vous aurez besoin de la racine comme autre nom pour que cela fonctionne avec la plupart des clients.
Pour un *.example.com cert,
a.example.comdevrait passerwww.example.comdevrait passerexample.comne devrait pas passera.b.example.compeut passer selon l'implémentation (mais probablement pas).
Essentiellement, les normes indiquent que le * doit correspondre à un ou plusieurs caractères non point, mais certaines implémentations autorisent un point.
La réponse canonique doit être dans RFC 2818 (HTTP sur TLS) :
La correspondance est effectuée en utilisant les règles de correspondance spécifiées par [RFC2459]. Si plus d'une identité d'un type donné est présente dans le certificat (par exemple, plus d'un nom dNSName, une correspondance dans l'un quelconque de l'ensemble est considérée comme acceptable.) Les noms peuvent contenir le caractère générique * qui est considéré comme correspondant à n'importe quel seul composant de nom de domaine ou fragment de composant. Par exemple.,
*.a.comcorrespond à foo.a.com mais pas à bar.foo.a.com.f*.comcorrespond à foo.com mais pas à bar.com.
RFC 2459 dit:
- Un caractère générique "*" PEUT être utilisé comme composant de nom le plus à gauche dans le certificat. Par exemple,
*.example.comcorrespondrait à a.example.com, foo.example.com, etc. mais ne correspondrait pas à example.com.
Si vous avez besoin d'un certificat pour fonctionner pour example.com, www.example.com et foo.example.com, vous avez besoin d'un certificat avec subjectAltNames afin d'avoir "example.com" et "* .example.com" (ou exemple .com et tous les autres noms dont vous pourriez avoir besoin pour correspondre).
Vous avez raison, le domaine racine doit être un autre nom pour qu'il puisse être validé.
Chaque fournisseur SSL que j'ai déjà utilisé ajoutera automatiquement le domaine racine en tant que nom alternatif de sujet à un certificat SSL générique, donc DOMAIN.COM fonctionnera automatiquement pour un certificat générique * .DOMAIN.COM.