Wildcard SSL nom commun - peut-il être appelé quelque chose?

34

Je me demandais simplement si un certificat SSL générique avait nécessairement besoin d'un nom commun contenant le nom de domaine des sites sur lesquels le certificat SSL était appliqué.

Par exemple, pour ce qui suit:

Nom de domaine: testdomain.com

Sous-sites:

www.testdomain.com
mobile.testdomain.com
mytestenvironment.testdomain.com

Ai-je nécessairement besoin de mon certificat générique pour avoir un nom commun *.testdomain.com?

ssl-certificate

— calembour
source

serverfault.com pourrait être un meilleur endroit pour cette question.

38

Oui, votre nom commun doit être * .votredomaine.com pour un certificat générique.

Fondamentalement, le nom commun est ce qui indique le domaine pour lequel votre certificat est bon. Il doit donc spécifier le domaine réel.

Précision: il ne devrait pas "contenir" le nom de domaine des sites, ce devrait être le domaine des sites. Je suppose qu'il n'y a aucune différence dans votre question, je voulais juste préciser, au cas où il y aurait une idée fausse de ce que le domaine devrait être, ou à quoi le certificat sera utilisé.

— Daniel Magliola
source

4

En fait, vous devez utiliser les dnsNameentrées de la subjectAltNamesection du certificat pour spécifier les noms de domaine complets, et non la partie CN du fichier subject. L'utilisation de subjectà cette fin est déconseillée depuis la publication de la RFC 2818 en 2000. Citant la section 3.1 :

Si une extension subjectAltName de type dNSName est présente, elle DOIT être utilisée comme identité. Sinon, le champ Nom commun (le plus spécifique) dans le champ Objet du certificat DOIT être utilisé. Bien que l'utilisation du nom commun soit une pratique existante, elle est déconseillée et les autorités de certification sont encouragées à utiliser plutôt le nom de fichier.

Le seul cas dans lequel le contenu de subjectest pertinent dans le contexte de la validation de certificat de serveur est l'absence d' dnsNameinclusion dans le subjectAltName, un cas qui est obsolète depuis 17 ans au moment de la rédaction.

L'utilisation de certificats génériques est déconseillée, comme indiqué dans la section 7.2 de la RFC 6125 :

Ce document indique que le caractère générique '*' NE DEVRAIT PAS être inclus dans les identificateurs présentés mais PEUT être vérifié par les clients de l'application (principalement pour des raisons de compatibilité ascendante avec l'infrastructure déployée).

L'utilisation de la même clé privée pour plusieurs services est généralement considérée comme une mauvaise pratique. Si l'un des services est compromis, les communications d'autres services seront compromises et vous devrez remplacer la clé (et le certificat) de tous les services.

Je suggère la RFC 6125 comme une bonne source d’information sur ce sujet.

— Erwan Legrand
source

"Et ainsi sont les certificats de wildcard": pourriez-vous s'il vous plaît élaborer? dnsNamepeut contenir un domaine générique. Aussi, que devrait être subjectdans ce cas?

— WoJ

Consultez les sections 1.5 et 7.2 de la RFC 6125 . Tant que le subjectAltNamecontient au moins un dnsName, le contenu de le subjectn'est pas pertinent dans le contexte de la vérification d'un certificat.

— Erwan Legrand

@WoJ J'ai modifié ma réponse. J'espère que tout est plus clair maintenant.

— Erwan Legrand

3

Oui, le certificat SSL Wildcard est la meilleure solution selon vos besoins. Avec le certificat Wildcard, vous pourrez protéger les informations de vos visiteurs. Peu importe la page de votre site Web qui est soumise. Le certificat générique sécurise un nombre illimité de sous-domaines partageant le même nom de domaine.

L'installation du même certificat générique sur tous les sous-domaines et serveurs transmet le risque intégré: si un serveur ou un sous-domaine est compromis, tous les sous-domaines peuvent l'être également. Assurez-vous que votre site Web est protégé avec plusieurs niveaux de protection contre toutes les pressions externes et internes.

— Jay Dan
source