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 préavis par un navigateur.

Cependant, ce n'est pas le cas avec le certificat qui m'a été fourni. Mes sous-domaines sont correctement sécurisés et ne génèrent pas d'erreur, mais le domaine racine génère une erreur dans le navigateur, indiquant que l'identité 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 de substitution d'objet (SAN) répertorie * .example.com et example.com, tandis que le certificat récent de Comodo répertorie uniquement *. example.com en tant que nom commun et NOT exemple.com en tant que nom alternatif de sujet.

Quelqu'un peut-il confirmer / préciser que le domaine racine doit être répertorié dans les détails du réseau de stockage si celui-ci doit également être sécurisé correctement?

Quand je lis ceci: http://www.digicert.com/subject-alternative-name.htm Il semble que le SAN doit indiquer à la fois afin de travailler comme je l' ai besoin pour. Quelle est votre expérience?

Merci beaucoup.

Il existe certaines incohérences entre les implémentations SSL sur la manière dont elles correspondent aux caractères génériques, mais vous aurez besoin de la racine comme nom alternatif pour que cela fonctionne avec la plupart des clients.

Pour un *.example.comcert,

• a.example.com devrait passer
• www.example.com devrait passer
• example.com ne devrait pas passer
• a.b.example.com peut passer en fonction de la mise en œuvre (mais probablement pas).

Pour l’essentiel, les normes indiquent que le *doit correspondre à un ou plusieurs caractères autres que des points, 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 plusieurs certificats d’un type donné sont présents dans le certificat (par exemple, plusieurs noms dNSName, une correspondance dans l’un des ensembles est considérée comme acceptable.) Les noms peuvent contenir le caractère générique * considéré comme correspondant à n’importe quel nom. 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.

Le RFC 2459 dit:

• Un caractère générique "*" PEUT être utilisé comme composant de nom le plus à gauche du certificat. Par exemple, *.example.comcorrespondrait à a.example.com, foo.example.com, etc., mais ne correspondrait pas à exemple.com.

Si vous avez besoin d’un certificat pour travailler par exemple.com, www.example.com et foo.example.com, vous devez disposer d’un certificat avec subjectAltNames pour que vous ayez "exemple.com" et "* .example.com" (ou exemple). .com et tous les autres noms que vous pourriez avoir besoin de faire correspondre).

Vous avez raison, le domaine racine doit être un autre nom pour pouvoir être validé.

Tous les fournisseurs SSL que j'ai utilisés ajouteront automatiquement le domaine racine en tant que nom alternatif de sujet à un certificat SSL générique. DOMAIN.COM fonctionnera automatiquement pour un certificat générique * .DOMAIN.COM.

Les certificats génériques sont idéalement générés pour * .example.com. Pour sécuriser vos sous-domaines et domaines avec ce certificat, il vous suffit d'installer le même certificat sur des serveurs pointant vers ces domaines.

Par exemple, vous avez un certificat générique pour * .example.com one.example.com - server 1 example.com - server 2

vous devez installer ce certificat sur le serveur 1 et le serveur 2.