Extracteur SAN

L'outil SAN Extractor extrait tous les Subject Alternative Names des certificats X.509, fournissant une liste propre de chaque nom d'hôte, adresse IP, adresse e-mail et URI pour lesquels le certificat est valide -- essentiel car les navigateurs modernes utilisent exclusivement les SAN pour la validation des noms d'hôtes, en ignorant le champ Common Name. Collez un ou plusieurs certificats PEM et obtenez un inventaire complet des identités couvertes.

Comprendre les Subject Alternative Names

Les Subject Alternative Names sont le moyen par lequel les certificats modernes déclarent quelles identités ils protègent. Chaque fois qu'un navigateur se connecte à un site HTTPS, il vérifie l'extension SAN du certificat pour voir si le domaine dans la barre d'adresse y figure. Si ce n'est pas le cas, la connexion échoue avec une erreur de non-correspondance de nom d'hôte -- même si le domaine apparaît dans le champ Common Name plus ancien. C'est le comportement dans Chrome depuis la version 58 (2017), et tous les autres navigateurs principaux suivent la même règle.

Pour les administrateurs système, l'impact pratique est significatif. Vous devez savoir exactement quels domaines un certificat couvre avant de le déployer, avant de le renouveler et lors du dépannage d'échecs de connexion. Un certificat pour www.example.com pourrait aussi couvrir example.com, api.example.com et cdn.example.com, ou il pourrait ne couvrir que le sous-domaine www seul. Vous ne pouvez pas le déterminer à partir du nom de fichier du certificat ou du Common Name seul. L'extension SAN est la source de vérité faisant autorité pour ce qu'un certificat protège.

Cet extracteur récupère chaque entrée SAN d'un ou plusieurs certificats et les présente sous forme de liste propre et organisée. Pour les entrées multi-certificats (comme une chaîne ou un bundle de certificats non liés), il indique quels SAN proviennent de quel certificat. Cela facilite l'audit de votre couverture de certificats sur l'ensemble d'une infrastructure -- collez tous vos certificats et vous voyez immédiatement chaque domaine, adresse IP et identité protégée.

Comment extraire les SAN d'un certificat

1. Collez un ou plusieurs certificats encodés en PEM (commençant par -----BEGIN CERTIFICATE-----)
2. L'outil extrait et liste tous les Subject Alternative Names, organisés par type
3. Vérifiez la liste des SAN pour sa complétude et son exactitude
4. Copiez la sortie sous forme de liste, d'expression régulière ou d'extrait de configuration

Exemple d'extraction de SAN

À partir d'un certificat multi-domaines :

Certificate: CN=www.example.com

Subject Alternative Names:
  DNS: www.example.com
  DNS: example.com
  DNS: api.example.com
  DNS: *.staging.example.com
  IP:  203.0.113.50

Types de SAN

Sortie multi-certificats

Lors du collage d'un bundle contenant plusieurs certificats, l'extracteur indique quels SAN proviennent de quel certificat :

Quand utiliser cet outil

• Audit de domaines avant renouvellement -- listez tous les domaines couverts par un certificat expirant pour vous assurer que la demande de renouvellement inclut chaque SAN
• Cartographie de la couverture des certificats -- documentez quels certificats protègent quels domaines à travers votre infrastructure
• Vérification de la couverture wildcard -- confirmez que les certificats wildcard (*.example.com) couvrent les sous-domaines attendus et identifiez ce qu'ils ne couvrent pas (ex. sub.sub.example.com)
• Planification de migration -- extrayez les SAN des certificats existants lors d'une migration vers une nouvelle autorité de certification ou d'une consolidation de certificats
• Revue de sécurité -- identifiez les domaines inattendus dans un certificat qui pourraient indiquer une mauvaise configuration ou une compromission
• Dépannage de non-correspondance de hostname -- vérifiez que le domaine causant une erreur TLS est effectivement listé dans les SAN du certificat

Fonctionnement des Subject Alternative Names

L'extension SAN (OID 2.5.29.17) a été introduite pour pallier les limitations du champ Common Name. Alors que le CN ne pouvait contenir qu'un seul nom d'hôte, l'extension SAN supporte plusieurs noms et différents types de noms.

CN vs. SAN : comportement actuel des navigateurs

Depuis 2017, les principaux navigateurs ont déprécié le Common Name pour la correspondance des noms d'hôtes :

• Chrome 58+ -- ignore complètement le CN ; vérifie uniquement les SAN
• Firefox 48+ -- ignore le CN si des SAN sont présents
• Safari -- suit le même principe

Cela signifie qu'un certificat avec CN=example.com mais sans entrée SAN DNS:example.com produira une erreur de non-correspondance de nom d'hôte dans les navigateurs modernes. Assurez-vous toujours que chaque domaine apparaît dans l'extension SAN.

Portée des certificats wildcard

Les SAN wildcard suivent des règles de correspondance spécifiques :

Règles clés :

• Les wildcards ne correspondent qu'à un seul niveau de sous-domaine
• Les wildcards doivent être le label le plus à gauche (*.example.com, pas www.*.com)
• Le domaine nu (example.com) n'est pas couvert par *.example.com -- il doit être listé comme un SAN distinct

Gestion des SAN en pratique

L'erreur la plus courante liée aux SAN est d'oublier le domaine nu. Si vos utilisateurs accèdent à la fois à www.example.com et example.com, les deux doivent apparaître comme entrées SAN séparées. Un wildcard *.example.com couvre www.example.com mais pas example.com lui-même. Cela surprend de nombreuses équipes lorsqu'elles passent d'un certificat wildcard seul à un certificat qu'elles pensent couvrir le domaine apex. Incluez toujours à la fois example.com et *.example.com (ou www.example.com) comme entrées séparées.

Pour les organisations avec de nombreux sous-domaines, le choix entre un certificat wildcard et un certificat multi-SAN est une décision architecturale importante. Les certificats wildcard (*.example.com) sont pratiques car vous n'avez pas besoin de lister chaque sous-domaine, mais ils ne peuvent pas couvrir les sous-domaines plus profonds comme api.v2.example.com ni le domaine nu. Les certificats multi-SAN listent chaque domaine explicitement, ce qui vous donne un contrôle complet mais nécessite de mettre à jour le certificat à chaque ajout de sous-domaine. De nombreuses organisations utilisent un wildcard pour les sous-domaines créés dynamiquement et un certificat multi-SAN séparé pour leurs domaines principaux.

Lors de l'audit de la couverture des certificats avant les renouvellements, extrayez les SAN de votre certificat expirant et comparez-les à vos enregistrements DNS. Il est étonnamment courant de découvrir qu'un certificat a été émis il y a deux ans avec des SAN qui ne correspondent plus à votre infrastructure actuelle. De nouveaux sous-domaines ont été ajoutés, d'anciens ont été retirés, et le certificat n'a jamais été mis à jour. Cette étape d'audit évite la situation frustrante de déployer un certificat renouvelé pour découvrir qu'il ne couvre pas un sous-domaine ajouté après l'émission du certificat original.

Questions fréquentes

Pourquoi mon certificat affiche-t-il des domaines que je n'ai pas demandés ? Certaines autorités de certification ajoutent automatiquement le domaine nu et la variante www. Par exemple, demander un certificat pour example.com peut résulter en des SAN pour example.com et www.example.com. De plus, les certificats multi-domaines (UCC/SAN) peuvent inclure des domaines de commandes précédentes s'ils ont été renouvelés plutôt que réémis.

Combien de SAN un seul certificat peut-il contenir ? Il n'y a pas de limite absolue dans le standard X.509, mais des limites pratiques existent. Let's Encrypt autorise jusqu'à 100 SAN par certificat. Les autorités de certification commerciales supportent généralement entre 25 et 250 SAN selon le produit. Des listes de SAN très longues augmentent la taille du certificat et le temps du handshake TLS.

Un certificat wildcard doit-il avoir le domaine nu comme SAN distinct ? Oui. Un SAN wildcard *.example.com ne correspond pas au domaine nu example.com. Si vous avez besoin que *.example.com et example.com fonctionnent tous les deux, les deux doivent apparaître comme des entrées SAN distinctes dans le certificat.

Un certificat peut-il avoir à la fois des SAN DNS et IP ? Oui. Un même certificat peut inclure à la fois des noms DNS et des adresses IP comme SAN. C'est utile pour les services accessibles à la fois par nom d'hôte et par adresse IP. Cependant, la plupart des CA exigent une validation supplémentaire pour les SAN d'adresses IP, et Let's Encrypt ne délivre actuellement pas de certificats avec des SAN IP.

Pourquoi mon certificat affiche-t-il "hostname mismatch" alors que le CN correspond ? Les navigateurs modernes (Chrome 58+, Firefox 48+) ignorent le Common Name pour la validation des noms d'hôtes et ne vérifient que les Subject Alternative Names. Si votre domaine apparaît dans le CN mais pas comme entrée SAN DNS, les navigateurs rejetteront le certificat. Assurez-vous que chaque domaine est listé comme entrée SAN, pas seulement dans le CN.

Comment fonctionnent les SAN avec les sous-domaines multi-niveaux ? Un wildcard *.example.com ne correspond qu'à un seul niveau de sous-domaine. Il couvre www.example.com et api.example.com mais ne couvre pas api.v2.example.com. Pour les sous-domaines multi-niveaux, vous avez besoin soit d'une entrée SAN explicite pour chacun, soit d'un wildcard séparé comme *.v2.example.com.

Outils associés

• X.509 Certificate Viewer - Voir tous les champs d'un certificat, pas seulement les SAN
• Certificate Expiry Checker - Vérifier la date d'expiration des certificats couvrant vos domaines
• CSR Viewer - Vérifier les SAN demandés dans une CSR avant soumission à une CA
• PEM Bundle Splitter - Séparer une chaîne pour extraire le certificat feuille contenant les SAN
• Public Key Extractor - Extraire la clé publique des certificats couvrant vos domaines