Noms alternatifs du sujet : comment un serveur VPN est identifié

Votre client rejette un certificat dont la chaîne se valide proprement, et l’erreur indique que le nom ne correspond pas. Ce message ne porte pas sur qui a signé le certificat. Il porte sur l’extension des noms alternatifs du sujet, qui contient les identités que le certificat est autorisé à représenter, et sur la présence, sous la bonne forme, de l’identité que vous avez configurée. La confiance répond de qui l’a signé, tandis que la vérification du nom répond à quel hôte il appartient.

Ce que le client compare réellement

Le client transforme votre configuration en identité de référence : un nom d’hôte, une adresse ou un identifiant propre au protocole. Il cherche ensuite cette identité dans le certificat, en appliquant les règles de correspondance du protocole utilisé. Seules les entrées du même type comptent, donc une entrée DNS ne peut pas satisfaire une adresse, et la comparaison a lieu que quelqu’un regarde le certificat ou non.

Quand l’identité de référence manque dans cette extension, la vérification échoue même si l’ancien nom commun correspond. Un certificat peut être légitimement délivré à une entreprise et rester le mauvais pour vpn.example.com si le nom n’a jamais été inclus. L’échec est une non-concordance de nom, même si le certificat est authentique.

Les noms DNS et les adresses IP sont des entrées distinctes

Un profil qui pointe vers 203.0.113.10 alors que le certificat ne liste que vpn.example.com est rejeté, car les paquets arrivent mais l’identité ne correspond pas. Les noms DNS et les adresses littérales sont stockés comme des types d’entrée différents, et l’un ne remplace jamais l’autre. C’est pourquoi un service peut être joignable par adresse et rester inutilisable via un profil qui utilise cette adresse.

Les jokers obéissent aussi à leurs propres règles : un joker couvre une seule étiquette, pas tous les noms sous un domaine. La comparaison DNS ne distingue pas la casse, alors que d’autres types d’identifiant le font, si bien qu’une valeur identique à l’écran peut échouer à une comparaison stricte. Vérifiez les règles de correspondance du type d’identité utilisé plutôt que de comparer des chaînes à l’œil. Ajouter un nom à l’extension est une décision d’émission, pas quelque chose qu’un réglage client peut fournir.

Inspectez le certificat que la connexion a réellement utilisé

Lisez le matériel présenté par le point de terminaison actif, pas un fichier copié depuis une page d’administration. Un répartiteur de charge ou une instance de remplacement peut présenter autre chose que le certificat téléversé il y a des mois, et cette différence est invisible dans une console.

openssl s_client -connect vpn.example.com:443 -showcerts </dev/null | openssl x509 -noout -text

Le bloc des noms alternatifs du sujet, la chaîne d’émetteur et la période de validité relèvent d’une même lecture, car une non-concordance de nom et une expiration produisent des erreurs différentes. Comparez chaque nom de ce bloc à l’identité configurée dans le profil, caractère par caractère, et notez de quel type il s’agit. Répéter la commande sur la forme d’adresse du point de terminaison montre si le certificat couvre les deux identités ou une seule. Un affichage convivial du sujet dans une console de gestion n’est pas un résultat de validation et ne dit rien des noms que contient l’extension.

Le nom commun n’est pas la source moderne de vérité

Les navigateurs et la plupart des bibliothèques TLS ignorent désormais le nom commun pour la correspondance des noms d’hôte et consultent l’extension. Certains clients VPN comparent encore d’abord le nom commun ou s’y rabattent quand l’extension est absente, et c’est ainsi qu’un même certificat peut passer dans un navigateur et échouer dans un client. La même vérification de nom peut réussir sur une plateforme et échouer sur une autre sans que le certificat change du tout.

Déterminez quel champ votre client lit avant de conclure que le certificat est incorrect. Deux clients sur le même point de terminaison peuvent être en désaccord, et ce désaccord renseigne sur le client plutôt que sur le certificat.

Réparez l’émission ou le profil, pas la vérification

Quand un profil a été construit autour d’un alias, soit repointez-le vers le nom d’hôte documenté, soit réémettez le certificat pour l’alias et déployez-le dans une fenêtre planifiée. Faire taire l’avertissement n’est pas une troisième option, car la vérification est la seule étape qui lie un certificat signé à cet hôte précis. La supprimer signifie que n’importe quel certificat de la même autorité peut se substituer au serveur que vous vouliez joindre.

Le renouvellement devrait préserver les noms et l’objectif prévus plutôt que de simplement avancer la date d’expiration. Un renouvellement qui perd un nom est une nouvelle panne programmée pour le prochain redémarrage, et elle survient généralement sans avertissement parce que l’ancien certificat était encore valide au moment du changement.

Consignez l’identité attendue, les noms présentés et la chaîne qui les a signés. Cette consignation transforme le prochain renouvellement en comparaison plutôt qu’en enquête. La définition de l’extension se trouve dans RFC 5280 si vous devez vérifier une émission précise.