SAN : Subject Alternative Name
Sécurité
Le SAN, ou Subject Alternative Name, est le champ d’un certificat qui liste les noms associés à un serveur. Lors d’une connexion sécurisée, le client compare le nom demandé à cette liste pour vérifier l’identité du serveur.
Noms couverts : Un SAN peut contenir un nom de domaine, plusieurs sous-domaines ou une adresse IP. Pour les certificats de serveurs, ce champ fait foi pour la vérification du nom, davantage que l’ancien champ CN.
Contrôle côté client : Le client compare exactement le nom utilisé pour la connexion avec les entrées du SAN, en tenant compte des règles applicables aux jokers. Une correspondance absente déclenche normalement une erreur, même si le certificat est signé par une autorité reconnue.
Migration TLS : Passer de LDAP non chiffré à LDAP sur TLS ne suffit pas : il faut aussi contrôler le SAN, la chaîne de confiance et les dates de validité. Sinon, le canal est protégé, mais l’interlocuteur peut rester un imposteur bien habillé.
Ce qui arrive si on s'en passe
Le SAN constitue la garde à l'entrée de la couche TLS : il définit exhaustivement les noms qu'un certificat autorise, et tout nom absent doit provoquer un refus de connexion, jamais un avertissement contournable. Le contrôle d'accès exige donc que les clients vérifient le nom demandé contre la liste SAN et ignorent le champ CN, déprécié. La détection collective repose sur la journalisation des échecs de validation et sur la surveillance des journaux de transparence des certificats, qui révèlent l'émission de certificats couvrant des noms non prévus. La réponse consiste à révoquer sans délai tout certificat dont le SAN est trop large ou incorrect, à réémettre avec la liste minimale de noms réellement servis, et à proscrire les jokers là où une énumération explicite reste possible.
Comment le mettre en place
Pour observer la rupture, générer deux certificats avec une autorité de test locale : le premier ne portant qu'un CN, sans extension subjectAltName ; le second listant explicitement le nom de service dans son SAN. Les servir tour à tour sur un port TLS local, puis interroger avec `curl --cacert` et `openssl s_client -verify_hostname`. Le certificat sans SAN devrait être rejeté par tout client récent, même si le CN correspond exactement au nom demandé. Ajouter ensuite une entrée SAN pour un nom voisin et se connecter sous ce nom : la validation passe. Cela démontre que la correspondance d'identité repose sur la liste SAN, pas sur le CN, et que tout nom oublié dans cette liste devient inaccessible en TLS strict.
Explication de la marmotte
Un nom alternatif est une liste de noms écrite dans le document d’identité d’un serveur. Quand un ordinateur se connecte, il compare le nom demandé avec cette liste. Si le nom n’y figure pas, la connexion doit être refusée, même si le document vient d’une source reconnue. C’est comme vérifier qu’un badge porte bien le nom du bâtiment avant d’ouvrir la porte. La conversation peut être protégée, mais cette vérification s’assure surtout qu’elle a lieu avec le bon interlocuteur, pas avec un imposteur.
Où ce terme est utilisé
- Diagnostiquer les erreurs de validation TLS en production (5 occurrences)
- Relier une clé à une identité: certificats et PKI (5 occurrences)
- Construire une autorité de certification privée interne (3 occurrences)
- Extensions X.509 v3 Key Usage EKU et Basic Constraints (3 occurrences)
- Quels risques pour un certificat wildcard TLS (3 occurrences)
- Grand-père Castor raconte : bind LDAP en clair, corrigé (2 occurrences)
- Ethernet, trames et commutation locale (1 occurrence)
- Principes de sécurité, identité et cryptographie utile au réseau (1 occurrence)