Qu’est-ce qu’un certificat (SAN) multi-domaine ?
Lors de la commande ou de l’émission d’un nouveau certificat TLS/SSL, un champ « Subject Alternative Name » vous permet de saisir d’autres noms d’hôte (sites, adresses IP, noms communs, etc.) que vous souhaitez protéger via un certificat TLS/SSL unique. Par exemple, un certificat (SAN) multi-domaine ou un certificat multi-domaine à validation étendue.
Si l’extension Subject Alternative Name faisait partie de la norme de certificat X509 avant 1999, elle doit son essor au lancement de Microsoft Exchange Server 2007. Cette modification a permis de simplifier les configurations des serveurs. Aujourd’hui, les Subject Alternative Names sont largement utilisés dans les environnements ou sur les plateformes qui nécessitent de sécuriser plusieurs noms de sites web dans différents domaines et sous-domaines.
À quoi servent les SAN (Subject Alternative Names) ?
Les SAN remplissent trois principales fonctions :
- Sécurisation des noms d’hôte sur différents domaines de base à partir d’un seul certificat TLS/SSL – pour pallier les limites d’un certificat Wildcardqui peut protéger tous les sous-domaines de premier niveau d’un domaine (ex. : *.exemple.fr), mais ne peut pas sécuriser à la fois « www.exemple.fr » et « www.exemple.net ».
- Hébergement virtuel de plusieurs sites TLS/SSL sur une seule adresse IP – l’hébergement de plusieurs sites compatibles TLS/SSL sur un seul serveur nécessite en général d’utiliser une adresse IP par site. Un certificat (SAN) multi-domaine peut résoudre ce problème. Les plateformes Microsoft IIS et Apache peuvent chacune héberger des sites HTTPS virtuels utilisant des certificats (SAN) multi-domaines.
- Simplification de la configuration TLS/SSL de votre serveur – l’utilisation d’un certificat (SAN) multi-domaine vous épargne la tâche pénible et chronophage de configurer plusieurs adresses IP sur votre serveur, d’associer chaque adresse IP à un certificat différent sans rien oublier.
Où peut-on voir des SAN en action ?
Pour voir un exemple de SAN, cliquez sur le cadenas dans la barre d’adresse de cette page afin d’afficher notre certificat TLS/SSL. Dans les détails du certificat, une extension Subject Alternative Name affiche à la fois et « digicert.com », ainsi que des SAN supplémentaires sécurisés par notre certificat. Comme le nom « digicert.com » est répertorié dans notre certificat, votre navigateur n’affichera pas de message d’avertissement si vous saisissez « https://digicert.com » (sans « www » dans le nom) pour vous rendre sur notre site.
Comment les navigateurs utilisent-ils le champ « Subject Alternative Name » dans votre certificat TLS/SSL ?
Lorsque les navigateurs se connectent à votre serveur via HTTPS, ils vérifient que votre certificat TLS/SSL correspond au nom d’hôte dans la barre d’adresse.
Les navigateurs utilisent trois méthodes pour établir une correspondance :
- Le nom d’hôte (dans la barre d’adresse) correspond exactement au nom commun dans l’objet du certificat.
- Le nom d’hôte correspond à un nom commun générique (Wildcard). En l’occurrence, « www.exemple.fr » correspond au nom commun « *.exemple.fr ».
- Le nom de l’hôte apparaît dans le champ « Subject Alternative Name ».
La forme la plus courante de correspondance de noms TLS/SSL consiste pour le client TLS/SSL à comparer le nom du serveur auquel il s’est connecté au nom commun dans le certificat du serveur. Il y a fort à parier que tous les clients TLS prendront en charge la correspondance exacte des noms communs.
Si un certificat TLS comporte un champ « Subject Alternative Name », les clients TLS sont censés ignorer la valeur du nom commun et rechercher une correspondance dans la liste SAN. C’est pourquoi ÃÛÌÒTV répète toujours le nom commun comme premier SAN dans nos certificats.
Quels sont les clients TLS/SSL compatibles avec les SAN ?
Si la plupart des appareils mobiles prennent en charge les SAN et les certificats Wildcard, tous, en revanche, prennent en charge la correspondance exacte du nom commun.
Internet Explorer, Firefox, Opera, Safari, et Netscape : tous ces navigateurs prennent en charge les SAN depuis 2003. Internet Explorer les prend en charge depuis Windows 98.
Microsoft Edge : le dernier navigateur Microsoft prend en charge les SAN.
Windows Phone : prend en charge la correspondance des SAN et Wildcard.
Appareils Palm Treo récents: ces appareils utilisent WM5, mais les plus anciens exécutent Palm OS et utilisent VersaMail pour ActiveSync. Les modèles Treo plus anciens ne prennent pas en charge la correspondance des SAN.
Smartphones récents exécutant Symbian OS : Symbian OS prend en charge les SAN depuis sa version 9.2.
Anciens smartphones exécutant Symbian OS : Symbian OS 9.1 et les versions antérieures ne prennent pas en charge la correspondance des SAN. Cela semble être résolu dans Symbian OS 9.2 (S60 3e édition, avec Pack 1).
Anciens appareils Palm Treo : ces appareils exécutent PalmOS et utilisent VersaMail pour ActiveSync. Ces anciens modèles Treo ne prennent pas en charge la correspondance des SAN.
Tous les appareils mobiles ne prenant pas en charge le champ « Subject Alternative Name », il est plus prudent de définir votre nom commun par rapport au nom que la plupart des appareils mobiles utiliseront.
