Inadéquation de nom ou expiration du certificat : les distinguer

Deux pannes VPN se ressemblent vues du siège de l’utilisateur et appellent des corrections opposées. Une inadéquation de nom indique que le certificat est valide mais émis pour autre chose. Une erreur d’expiration indique que le certificat n’est pas valide à cet instant. Ni l’une ni l’autre n’est un problème de mot de passe, et réinitialiser les identifiants est l’heure la plus gaspillée dans les deux cas. Lisez l’étape qui échoue avant de toucher à quoi que ce soit.

Le texte d’erreur est le diagnostic

Le client vous indique quelle vérification a échoué, même quand le message est laconique. Une inadéquation nomme le nom d’hôte attendu et celui trouvé. Une erreur d’expiration mentionne des dates de validité ou une heure. Ces deux phrases désignent des parties différentes du certificat.

Lisez-les à l’étape où elles apparaissent. Un échec pendant la poignée de main est un problème de certificat ; un échec après l’établissement du tunnel est un problème de routage ou d’identifiants. Retenir l’étape est ce qui empêche l’enquête de dériver vers des réglages sans rapport.

Si l’échec varie d’une tentative à l’autre, vous avez une troisième possibilité : plusieurs nœuds derrière le même nom.

Contrôles de nom : ce que le client compare

Le client compare l’identité qu’il est configuré à attendre aux noms du certificat, qui se trouvent dans l’extension subjectAltName. Une adresse IP brute dans le profil, un alias que le certificat n’énumère pas, ou un nom qui se résout simplement vers le même serveur échouent tous à ce contrôle. Atteindre la bonne machine n’est pas la même chose que présenter la bonne identité.

Inspectez le certificat que le serveur présente réellement plutôt qu’un fichier d’une tentative précédente. La commande ci-dessous demande le nom que vous avez configuré, de sorte que la réponse contient le certificat qu’un vrai client verrait.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -dates -ext subjectAltName

Un certificat émis par une autorité de confiance peut toujours concerner un autre service. Gardez les contrôles de nom du client activés, car faire confiance à une AC n’autorise pas tous les noms que cette AC a un jour signés. Désactiver le contrôle transforme une erreur de configuration en exposition.

Expiration : l’horloge de qui est lue

La validité est une paire d’horodatages, et le vérificateur les compare à sa propre horloge. Un appareil dont l’horloge est fausse signale un certificat valide comme expiré ou comme pas encore valide, et la correction porte sur l’horloge, pas sur le certificat. Une différence d’affichage de fuseau horaire n’est pas la même chose qu’une heure sous-jacente erronée.

Comparez les dates du certificat avec UTC sur le client avant de conclure quoi que ce soit :

openssl x509 -in cert.pem -noout -dates
date -u

Si les dates sont réellement dépassées, renouvelez auprès de l’émetteur. Si un remplacement existe mais n’est pas encore valide, suivez la bascule prise en charge plutôt que d’avancer l’horloge pour l’accommoder. Antidater un appareil pour satisfaire un certificat est une décision aux conséquences bien au-delà du tunnel.

Pourquoi corriger l’un expose l’autre

La validation exécute une séquence de contrôles, et le premier échec arrête le rapport. Corrigez le nom et le client peut alors vous dire que la chaîne est incomplète ou que le certificat a expiré. Cela ne signifie pas que le premier contrôle était inutile. Cela signifie que la chaîne avait plus d’un problème : attendez-vous donc au second message d’erreur au lieu d’y voir la preuve que la première correction était fausse.

Plusieurs nœuds aggravent la chose. Un service réparti peut présenter des certificats différents selon le membre, si bien qu’un test qui passe deux fois et échoue une fois vous parle de la flotte, pas de votre client. Conservez l’adresse du pair et l’heure de la tentative dans le diagnostic.

C’est ce détail qui transforme un ticket intermittent en ticket reproductible.

Prouvez-le avec une nouvelle connexion

Après la réparation, ouvrez une nouvelle connexion plutôt que de reprendre une ancienne, et confirmez que l’étape qui échouait passe désormais. Confirmez ensuite que le tunnel transporte réellement du trafic, car une poignée de main réussie n’est pas une route qui fonctionne.

Conservez l’étape exacte de l’erreur et les détails du certificat avec le ticket.

Cette trace est ce qui empêche la personne suivante de réinitialiser des mots de passe de compte pour un problème de certificat. Identité et validité sont des questions distinctes, et la RFC 5280 est la référence pour la façon dont la seconde est évaluée.