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 je considérais était - je serai l' hôte de la documentation à docs.<tenant>.mycompany.comdemander à mon locataire de configurer un enregistrement CNAME DNS à un point 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, cela fonctionnera-t-il avec cette configuration ou devra-t-on acheter un nouveau certificat SSL 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.comalors votre certificat SSL doit couvrir cela.

Si docs.tenantcompany.comc'est un CNAME foo.example.com, le certificat n'a pas besoin de 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 indique explicitement à votre navigateur d'aller ailleurs. Si votre serveur web a été en train de faire une redirection vers l'autre nom, vous auriez réellement besoin certs pour les deux noms parce que votre navigateur serait finalement connecter à tous les deux séparément.

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.comnom.

Réponse plus longue

Supposons que vous naviguiez https://docs.tenantcompany.comdans 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 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 CNAMEalias dans le DNS entre l'enregistrement d'origine et un enregistrement Aor 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 CNAMEenregistrement.

Notre méthode pour autoriser le serveur à servir des sessions sécurisées docs.tenantcompany.comconsiste à 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.comespace de noms DNS. Cela pourrait être une mauvaise position pour vous et l'entreprise locataire à placer, du point de vue juridique / responsabilité.