Quels certificats sont nécessaires pour les sous-domaines multi-niveaux?
Je travaille sur un site Web avec plusieurs niveaux de sous-domaines. Je dois tous les sécuriser avec SSL et j'essaie de déterminer la bonne stratégie de certificat.
Voici ce que je dois sécuriser:
- foo.com
- www.foo.com
- Toute combinaison de city.state.foo.com. (Ce sont des États américains.)
Ma compréhension est qu'un certificat générique ne peut couvrir qu'un "niveau" de sous-domaine. selon RFC 2818 :
Les noms peuvent contenir le caractère générique * qui est considéré comme correspondant à tout composant de nom de domaine ou fragment de composant unique. Par exemple, * .a.com correspond à foo.a.com mais pas à bar.foo.a.com. f * .com correspond à foo.com mais pas à bar.com.
Ce que je pense J'ai besoin des certificats suivants:
*.foo.com, qui correspondra, par exemple,foo.com,www.foo.com. (Bien que je ne sache pas si*.a.comallumettesa.compar lui-même.)*.ny.foo.comcorrespondrenew-york.ny.foo.com,buffalo.ny.foo.com, etc. J'aurai éventuellement besoin de 50 certificats de ce type pour correspondre à tous les États, une fois que notre site s'agrandira pour tous les servir.
Mes questions sont:
- Ce schéma est-il correct? Dans le scénario ci-dessus, si un utilisateur visite
ca.foo.com, obtiendront-ils le certificat pour*.foo.comou pour*.ca.foo.com? - Comment puis-je m'assurer que les utilisateurs voient tous ces sous-domaines comme appartenant légitimement à nous? Par exemple, si un utilisateur visite
foo.com, puismountain-view.ca.foo.com, et ce sont des certificats différents, recevront-ils un avertissement? Existe-t-il un moyen de garantir à leur navigateur que ces certificats partagent le même propriétaire?
Théoriquement:
- une
*correspond exactement à un niveau (d'où*.foo.comne correspond pasfoo.com) - mais vous pouvez avoir plusieurs
*dans un nom
Par conséquent, si toutes les implémentations SSL suivent fidèlement RFC 2818 , vous n'avez besoin que de trois certificats, avec des noms:
foo.com*.foo.com*.*.foo.com
et, si les implémentations sont vraiment bonnes pour coller avec RFC 2818 et les subtilités de X.509, vous pouvez même utiliser un certificat unique qui répertorie les trois chaînes ci-dessus dans son extension Subject Alt Name.
Maintenant, la théorie et la pratique correspondent parfaitement ... en théorie. Vous pourriez être surpris de ce que les navigateurs font réellement. Je vous suggère de l'essayer; certains exemples de certificats peuvent être créés avec l'outil de ligne de commande OpenSSL (voir par exemple cette page pour quelques directives).
La RFC 6125 est assez récente et n'est pas implémentée par tout le monde, mais elle essaie de clarifier certains de ces problèmes. Il rassemble les spécifications d'identité dans la RFC 2818 et les RFC d'autres protocoles. Je suggère d'adhérer à la RFC 6125 si vous le pouvez. Les sections pertinentes pour les certificats génériques sont 6.4. et 7.2 (ce qui décourage l'utilisation de certificats génériques, en fait).
Votre question ne précise pas si vous souhaitez exécuter un seul serveur Web (ou au moins être capable de tout exécuter derrière une seule adresse IP), ou si vous êtes en mesure d'avoir un certificat par site (et donc une adresse IP par site, puisque SNI n'est pas très bien supporté en général).
Vous pouvez avoir un seul certificat avec plusieurs noms alternatifs de sujet (SAN). Le problème vient du cas avec deux libellés génériques, qui peuvent ne pas être clairement spécifiés (*.*.foo.com).
Si le double caractère générique fonctionne, un certificat avec ces 3 SAN DNS devrait fonctionner:
foo.com*.foo.com*.*.foo.com
Cependant, comme cela peut ne pas fonctionner (selon les implémentations du client, qui ne sont probablement pas sous votre contrôle), et puisque vous pouvez répertorier les 50 états, vous pouvez avoir 52 SAN DNS:
foo.com*.foo.com*.ny.foo.com- ... (un pour chaque état)
Comment puis-je m'assurer que les utilisateurs voient tous ces sous-domaines comme appartenant légitimement à nous? Par exemple, si un utilisateur visite foo.com, puis mountain-view.ca.foo.com, et qu'il s'agit de certificats différents, recevra-t-il un avertissement? Existe-t-il un moyen de garantir à leur navigateur que ces certificats partagent le même propriétaire?
Il s'agit d'une question délicate, car elle dépend de la familiarité des utilisateurs avec le processus de vérification des certificats. Vous pourriez obtenir un certificat de validation étendue (même si je pense que le certificat EV générique n'est probablement pas autorisé), ce qui donnerait une barre verte. Cela donnerait une certaine étiquette de "propriété" dans la plupart des navigateurs. Après cela, les interfaces du navigateur elles-mêmes peuvent être déroutantes (par exemple, Firefox qui est géré par (inconnu) dans la barre bleue, ce qui n'aide pas vraiment). En fin de compte, les utilisateurs pourraient aller vérifier dans votre certificat pour voir vers quels SAN le certificat a été émis. Cependant, je doute que beaucoup le fassent et comprennent ce que cela signifie.
http://www.digicert.com/welcome/wildcard-plus.htm dit
De plus, les certificats SSL DigiCert WildCard sont uniques car ils vous permettent de sécuriser TOUT sous-domaine de votre domaine, y compris plusieurs niveaux de sous-domaines avec un certificat. Par exemple, votre WildCard pour * .digicert.com com peut inclure server1.sub.mail.digicert.com comme autre nom du sujet.
Vous pouvez soit utiliser un certificat générique, soit utiliser un certificat avec d'autres noms de domaine. Personnellement, j'utilise un certificat de StartSSL qui me permet d'avoir tous mes domaines répertoriés sur un seul certificat. J'ai quelque chose comme 10 domaines génériques et 15 autres ADN tous sur le même certificat afin que je puisse utiliser SSL sur les sites que j'ai hébergés sur mon serveur.