Ai-je besoin d'un certificat SSL distinct pour une redirection DNS?
J'implémente une application multi-locataire où mon application héberge et sert la documentation technique pour le produit d'un locataire.
Maintenant, l'approche que j'envisageais était - J'héberge la documentation sur docs.<tenant>.mycompany.com et demander à mon locataire de configurer un enregistrement DNS CNAME pour pointer docs.tenantcompany.com à docs.<tenant>.mycompany.com.
Je souhaite que le site soit compatible SSL avec le certificat de mon locataire. Je voulais savoir si mon entreprise locataire avait un certificat SSL générique, est-ce que cela fonctionnerait avec cette configuration ou devrais-je acheter un nouveau certificat SSL pour docs.tenantcompany.com?
Le nom du certificat doit correspondre à ce que l'utilisateur a entré dans le navigateur, et non à l'enregistrement DNS "final". Si l'utilisateur entre docs.tenantcompany.com alors votre certificat SSL doit couvrir cela.
Si docs.tenantcompany.com est un CNAME pour foo.example.com, le certificat ne pas doit couvrir foo.example.com, juste docs.tenantcompany.com.
La réponse de Jason est correcte. Mais juste pour clarifier un peu les termes ici, "redirection DNS" est un peu inapproprié. DNS a des enregistrements CNAME (alias alias) qui est un nom pointant vers un autre nom. Mais ce n'est pas une redirection. La traduction de nom en nom en IP se fait en arrière-plan et votre navigateur ne se soucie que du nom initial.
La seule chose qui fait des redirections est les serveurs Web où le serveur dit explicitement à votre navigateur d'aller ailleurs. Si votre serveur Web était en train de faire une redirection vers l'autre nom, vous auriez réellement besoin de certificats pour les deux noms parce que votre navigateur se connecterait finalement aux deux séparément.
Je voulais savoir si mon entreprise locataire avait un certificat SSL générique, cela fonctionnerait-il avec cette configuration ou si un nouveau certificat SSL devait être acheté pour
docs.tenantcompany.com?
Réponse courte: Non. Si votre entreprise locataire a un caractère générique au nom *.tenantcompany.com, cela suffit à installer sur votre serveur pour couvrir les accès via ce nom. Que vous le vouliez ou non, c'est une autre histoire.
Un certificat au nom docs.<tenant>.mycompany.com (par exemple, un certificat direct ou un caractère générique *.<tenant>.mycompany.com) est inutile si l'accès se fait toujours via le docs.tenantcompany.com Nom.
Réponse plus longue
Supposons que vous accédez à https://docs.tenantcompany.com dans un navigateur raisonnable. Le navigateur exécute TLS sur le protocole HTTP. Il se soucie spécifiquement de deux choses; cette:
le sous-système DNS du navigateur et du système d'exploitation renvoie l'adresse IP d'un hôte approprié, qui exécute un serveur Web sur un port approprié ailleurs sur le réseau local ou Internet. Pour le trafic HTTPS (sécurisé), le port par défaut est
443sauf indication contraire dans l'URL.Lorsque la prise de contact TLS a lieu entre le navigateur et le serveur distant, le serveur présente un certificat de confiance qui lui permet de fournir un service TLS à l'adresse demandée (
docs.tenantcompany.com).
DNS
Le navigateur voit DNS comme une boîte noire. Il appelle une bibliothèque DNS appropriée pour demander un mappage d'un nom de domaine complet (FQDN) convivial vers une adresse IP appropriée (v4 ou v6). Peu importe comment il obtient cette adresse IP. S'il y a 20 CNAME alias dans le DNS entre l'enregistrement d'origine et un A ou AAAA, le résolveur DNS les suivra jusqu'à l'obtention d'une adresse IP.
TLS
Lorsque le navigateur effectue la prise de contact TLS , il doit vérifier que le serveur avec lequel il communique est autorisé à fournir un service de site Web sécurisé sur le nom de domaine complet demandé: docs.tenantcompany.com.
N'oubliez pas: le navigateur ne se soucie pas de docs.<tenant>.mycompany.com - le résolveur DNS a éliminé toute connaissance de l'indirection via un enregistrement CNAME.
Notre méthode pour autoriser le serveur à servir des sessions sécurisées sur docs.tenantcompany.com est au moyen d'un certificat SSL qui est signé par une autorité pour laquelle une approbation préalable a été établie dans le magasin de certificats racine du navigateur. Ce n'est pas toujours la forme la plus puissante d'authentification du serveur au client - beaucoup de choses peuvent mal se passer dans le modèle CA centralisé - mais c'est la meilleure que nous ayons pour le moment.
Il y a deux autres mises en garde ici:
Partage de clé
De nombreux fournisseurs de certificats SSL commerciaux ne signeront qu'une seule demande de signature, ce qui lie efficacement le certificat générique à une seule clé privée. La société locataire peut être mal à l'aise de partager cela en dehors de son organisation, car toute personne en possession de la clé privée peut évidemment compromettre la communication avec les autres systèmes sécurisés de la société locataire.
Certains fournisseurs signeront plusieurs demandes de signature de certificat sous le même certificat, ce qui permet d'installer un seul certificat générique sur plusieurs serveurs et systèmes sans partager la clé privée entre eux.
Mascarade
Si la société locataire vous fournit une copie de son certificat générique (soit en partageant la clé privée, soit en signant votre propre CSR), vous pouvez vous faire passer pour <anydomain>.tenantcompany.com, brisant une protection importante qui assure l'intégrité des serveurs identifiés dans le tenantcompany.com Espace de noms DNS. Cela pourrait être une mauvaise position pour vous et l'entreprise locataire à placer, du point de vue juridique/responsabilité.