Qu'est-ce qu'un nom alternatif de sujet (SAN) ?

Un nom alternatif du sujet (SAN) est une extension de certificat X.509 qui répertorie tous les noms d'hôte, adresses IP ou autres identités pour lesquelles un certificat est valide, au-delà du champ « nom commun » (Common Name). Les clients TLS et les navigateurs modernes vérifient l'identité d'un certificat par rapport à ses entrées SAN, et non par rapport au nom commun, ce qui rend le SAN de fait obligatoire.

Points clés à retenir

• SAN répertorie tous les noms d'hôte et toutes les adresses IP protégés par un certificat.
• Les clients TLS vérifient l'identité à l'aide des entrées SAN, et non du nom commun.
• La RFC 5280 définit le SAN comme une extension standard des certificats X.509v3.
• Un même certificat peut comporter plusieurs entrées SAN de types différents.
• Versa Les certificats VMS nécessitent une entrée SAN pour chaque nom de domaine complet (FQDN) ou adresse IP utilisé(e).

Sur cette page : Pourquoi est-ce important ? · Comment ça marche · Types · SAN et Versa · FAQ

Pourquoi le SAN est-il important ?

Pendant des décennies, les clients TLS ont vérifié l'identité d'un certificat en se basant sur un seul champ : le nom commun (CN). Cela fonctionnait lorsqu'un serveur utilisait un seul nom d'hôte, mais ce n'est plus le cas dans les infrastructures modernes : on observe désormais un équilibrage de charge entre plusieurs noms, un domaine et ses sous-domaines, ou encore un périphérique accessible via plusieurs adresses IP. Le SAN a résolu ce problème en permettant à un même certificat de déclarer toutes les identités pour lesquelles il est valide.

Cette évolution revêt également une importance pour la sécurité. Les navigateurs et les bibliothèques TLS ont cessé depuis des années de se fier au nom commun (Common Name) pour la vérification d’identité : Chrome l’a déprécié en 2017, et les exigences de base du CA/Browser Forum imposent désormais l’utilisation du SAN pour tout certificat faisant l’objet d’une confiance publique. Un certificat ne comportant pas d’entrée SAN correspondante échoue d’emblée à la validation, quel que soit son nom commun. Aujourd’hui, émettre ou dépanner des certificats TLS implique de raisonner en termes de SAN, et non plus de CN.

Qu'est-ce qu'un SAN ?

Le « Subject Alternative Name » (nom alternatif du sujet) est une extension de certificat définie dans la RFC 5280, la norme régissant les certificats à clé publique X.509v3. Il s'agit d'une liste associée au certificat, dont chaque entrée correspond à un type : un nom DNS (le plus courant), une adresse IP, une adresse e-mail ou un URI, entre autres éléments moins fréquemment utilisés. Un même certificat peut comporter plusieurs entrées : généralement un domaine principal, plusieurs sous-domaines et une ou plusieurs adresses IP.

Lorsqu'un client TLS se connecte, il compare le nom d'hôte ou l'adresse IP qu'il a saisie à chaque entrée de la liste SAN ; une correspondance avec n'importe quelle entrée suffit, et le nom commun (Common Name) est ignoré même s'il est présent. Les autorités de certification vérifient la propriété de chaque entrée avant la délivrance du certificat ; c'est pourquoi l'ajout d'un nom d'hôte à un certificat existant implique de le réémettre avec une liste mise à jour, et non de modifier un champ en place.

Types d'entrées SAN

La RFC 5280 définit plusieurs types d'entrées SAN, même si quelques-uns d'entre eux sont majoritairement utilisés dans la pratique. Nom DNS (dNSName) Les entrées les plus courantes identifient un certificat par son nom de domaine complet ; un caractère générique en début de chaîne (*.example.com) couvre tout un niveau de sous-domaines en une seule entrée. Adresse IP (iPAddress) Ces entrées identifient un certificat par son adresse IPv4 ou IPv6 littérale. Adresse e-mail et URI Ces entrées apparaissent dans S/MIME et d'autres utilisations hors Web, mais sont beaucoup moins courantes dans les déploiements TLS.

Deux modèles de déploiement s'appuient sur ces types de certificats. Un certificat multi-domaines (SAN/UCC) regroupe plusieurs domaines sans rapport entre eux au sein d'un même certificat ; cela s'avère utile lorsqu'une organisation exploite de nombreux services mais souhaite les gérer à l'aide d'un seul certificat. Un certificat « wildcard-plus-SAN » combine une entrée générique avec des entrées explicites pour les hôtes ne correspondant pas à ce modèle.

SAN & Versa

Versa Les certificats du service de messagerie (VMS) constituent l'endroit le plus évident où les SAN apparaissent dans un déploiement d'Versa . Lors de l’installation et de la configuration du VMS, chaque certificat (qu’il s’agisse du certificat de serveur utilisé par les agents et les périphériques VOS ou du certificat de la base de données interne) doit comporter une entrée SAN pour chaque nom de domaine complet (FQDN) ou adresse IP sur lequel le cluster répond : l’interface de gestion, l’interface élastique pour le trafic des agents et l’interface southbound. Cette exigence est respectée aussi bien par le script auto-signé que par le workflow CSR, qui demande de saisir entre cinq et sept entrées SAN.

Les clusters à haute disponibilité renforcent encore ces exigences : un déploiement VMS basé sur la haute disponibilité nécessite des entrées SAN pour le nom de domaine complet (FQDN) de chaque nœud, ainsi que pour le FQDN élastique partagé, afin que le certificat reste valide quel que soit le nœud qui répond. Une entrée SAN manquante – souvent le FQDN élastique, ajouté a posteriori – provoque fréquemment des échecs de connectivité, car la négociation échoue même si le chemin réseau est correct.

Questions fréquentes

Quelle est la différence entre un SAN et un nom commun ?

Le nom commun (CN) est un champ d'identité unique hérité du passé, présent dans le champ « Subject » d'un certificat ; le SAN est une liste regroupant plusieurs identités : noms DNS, adresses IP, etc. Les clients TLS modernes effectuent la validation uniquement par rapport au SAN ; le CN est ignoré lors de la vérification d'identité, même s'il est renseigné.

Un certificat peut-il comporter un SAN sans nom commun ?

Oui. Les exigences de base du CA/Browser Forum autorisent les certificats dont le nom commun (Common Name) est vide ou absent, à condition que le SAN soit présent, et certaines autorités de certification omettent désormais le CN par défaut. Le SAN suffit à lui seul pour la validation de l'identité ; le CN n'a plus aucune incidence.

Pourquoi les navigateurs ont-ils cessé de faire confiance au « Common Name » ?

Le recours au nom commun (Common Name) entraînait des ambiguïtés et des analyses syntaxiques incohérentes entre les différentes bibliothèques TLS, ce dont les attaquants ont tiré parti pour obtenir des certificats trompeurs. Chrome a déprécié la correspondance par nom commun (CN) en 2017, et le CA/Browser Forum a par la suite imposé l'utilisation du SAN pour tous les certificats de confiance publique à l'échelle du secteur.

Que se passe-t-il si un certificat ne comporte pas d'entrée SAN correspondant à l'hôte auquel on tente d'accéder ?

La validation de la négociation TLS échoue : les clients et les navigateurs rejettent la connexion en raison d'une erreur de non-correspondance de nom, même si le nom commun (Common Name) correspond ou si le certificat est par ailleurs valide. Pour résoudre ce problème, il suffit de réémettre le certificat en ajoutant l'hôte manquant à sa liste SAN.

La liste SAN d'un certificat peut-elle inclure à la fois des noms DNS et des adresses IP ?

Oui. Une même liste SAN peut regrouper différents types d’entrées (noms DNS, adresses IP, adresses e-mail et URI), à condition que chaque entrée soit validée par l’autorité de certification émettrice. Il est courant de mélanger des entrées DNS et IP pour les infrastructures accessibles dans les deux sens.

En savoir plus sur le SAN

Si vous souhaitez en savoir plus, voici des sources auxquelles nous faisons confiance.

Termes associés

Si vous vous intéressez au SAN, voici quelques liens qui pourraient vous intéresser.