Je voulais savoir si mon entreprise locataire avait un certificat SSL générique, cela fonctionnera-t-il avec cette configuration ou si un nouveau certificat SSL doit être acheté docs.tenantcompany.com
?
Réponse courte: Non. Si votre entreprise locataire a un caractère générique dans le 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 naviguiez 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, 443
sauf indication contraire dans l'URL.
Lorsque la négociation 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 et convivial (FQDN) 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 enregistrement A
or AAAA
, le résolveur DNS les suivra jusqu'à l'obtention d'une adresse IP.
TLS
Lorsque le navigateur effectue la poignée de main TLS , il a besoin de 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 s'en fiche docs.<tenant>.mycompany.com
- le résolveur DNS a supprimé toute connaissance de l'indirection via un CNAME
enregistrement.
Notre méthode pour autoriser le serveur à servir des sessions sécurisées docs.tenantcompany.com
consiste à utiliser un certificat SSL 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 tourner 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
, rompant une protection importante qui garantit l'intégrité des serveurs identifiés dans l' 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é.