Certificat SSTP non concordant : le nom que votre serveur doit présenter

SSTP client SSTP n’accepte le serveur qu’après la réussite de la validation TLS, et ce contrôle compare un nom, une chaîne et un usage. Le nom vient du profil de connexion, pas de l’adresse que vous pouvez pinguer par hasard. Quand l’un des trois ne concorde pas, le client signale un problème de certificat et n’atteint jamais l’invite de connexion.

Le nom du profil décide de ce qui est vérifié

SSTP fait tourner TLS sur TCP 443, donc le client se comporte comme tout autre client TLS : il prend le nom d’hôte dans le profil, demande ce nom et compare le certificat à celui-ci. Saisissez une adresse IP dans le profil et la comparaison devient une comparaison d’adresses IP, à laquelle la plupart des certificats de serveur ne satisfont pas.

Un test dans le navigateur peut donc réussir alors que le VPN échoue, parce que le navigateur a utilisé un nom différent de celui du profil. La même division apparaît lorsque le DNS split-horizon résout le nom d’hôte du VPN vers une adresse interne alors que le navigateur en a atteint une publique. Alignez d’abord le profil sur le nom d’hôte documenté, puis comparez les certificats. Tout le reste que vous modifiez avant cela relève de la supposition.

Ce que le certificat du serveur doit porter

Les clients modernes comparent avec l’extension des noms alternatifs du sujet, donc le nom d’hôte doit y figurer comme entrée DNS. Un nom commun seul ne suffit pas aux piles de validation actuelles, et un joker couvre une étiquette et non n’importe quel sous-domaine que vous inventez. Trois certificats illustrent la limite : le bon nom avec le mauvais usage valide l’identité puis échoue au contrôle d’usage, le bon nom et le bon usage avec un intermédiaire manquant échouent sur la chaîne, et un nom qui n’apparaît que dans le nom commun échoue avant que l’un ou l’autre des deux précédents ne compte.

Le certificat a aussi besoin de l’usage authentification du serveur, la valeur d’utilisation étendue de la clé nommée dans la spécification SSTP de Microsoft, soit serverAuth avec l’identificateur d’objet 1.3.6.1.5.5.7.3.1. L’utilisation de la clé et une chaîne valide complètent l’ensemble. Un certificat présent sur le serveur, délivré pour le bon nom mais uniquement pour l’authentification du client, échoue quand même.

Vérifiez la chaîne et l’horloge avant les identifiants

Les défaillances de temps et de confiance produisent le même résultat visible qu’une discordance de nom, et les deux se diagnostiquent moins cher qu’un problème de mot de passe. Vérifiez l’horloge du serveur et celle du client, puis lisez la chaîne comme le client la voit :

# from the client, or any host that runs openssl
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts </dev/null 2>/dev/null | openssl x509 -noout -subject -dates -ext subjectAltName
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -verify_return_error </dev/null
# on the Windows server that holds the SSTP listener
w32tm /query /status

La première commande affiche le nom, la fenêtre de validité et les noms alternatifs auxquels le client comparera. La seconde signale les erreurs de vérification avec la chaîne telle que présentée, et c’est là qu’apparaît un intermédiaire manquant. Sous Windows, l’interrogation du service de temps vous dit si l’horloge est corrigée ou si elle a simplement dérivé.

Une CA interne ajoute une condition : le client doit faire confiance à cette CA. Installez la racine de l’organisation via son canal de distribution approuvé, pas depuis une page proposant un certificat de remplacement, car cette décision est tout le modèle de confiance en miniature.

La validation du serveur et l’authentification de l’utilisateur sont des étapes successives aux échecs différents. Une erreur de certificat signifie que le client n’a jamais fait confiance au serveur, tandis qu’un mot de passe rejeté signifie qu’il lui a fait confiance et que les identifiants étaient faux. Désactiver la validation du certificat pour atteindre l’invite de mot de passe supprime la garantie au lieu de la réparer. Pour prouver que le reste du chemin fonctionne, testez le même nom d’hôte et le même port depuis un client qui fait déjà confiance à la chaîne, et laissez le profil déployé tranquille.

Corrigez le nom ou le certificat, puis retestez

Trois conditions décident de la réparation. Si le nom du profil est faux, corrigez le profil ou ajoutez le nom manquant au certificat. Si la chaîne est incomplète, installez l’intermédiaire sur le serveur. Si l’usage est faux, réémettez au lieu de rafistoler autour.

Après le changement, reconnectez-vous avec le client pris en charge et confirmez que l’invite de connexion apparaît, puis que le tunnel monte. Notez dans le ticket le nom d’hôte utilisé, l’émetteur et la date d’expiration. C’est cet enregistrement qui fait du prochain renouvellement une tâche planifiée plutôt qu’une nouvelle panne, et il montre aussi à la personne suivante laquelle des trois conditions était réellement rompue.