Un mot de passe VPN correct ne remplace pas un certificat manquant

Les identifiants sont corrects, le profil s’importe proprement et la connexion échoue toujours avant la fin de l’authentification. Sous Windows, le message peut être l’erreur 798, à propos d’un certificat introuvable pour la méthode EAP. Sur OpenVPN, le journal du client montre une poignée de main TLS qui ne satisfait jamais le serveur. Les deux décrivent le même objet manquant : un certificat client que le client était censé présenter.

Un mot de passe prouve la connaissance d’un secret ; un certificat prouve la possession d’une clé, et l’un ne remplace pas l’autre.

Le mot de passe n’a jamais été le problème

L’erreur 798 est un échec de recherche de certificat. Le client a été invité à fournir un certificat correspondant à la méthode d’authentification configurée, a parcouru son magasin et n’a rien trouvé d’utilisable. Cela peut signifier que le certificat est absent, présent sans sa clé privée, expiré, ou stocké là où la recherche n’atteint pas. Réessayer le mot de passe ne peut changer aucune de ces conditions, c’est pourquoi l’erreur revient avec des identifiants corrects.

Lisez le message avant d’agir. Un rejet d’identifiants, un échec de recherche de certificat et un échec de poignée de main TLS sont trois constats différents, et un seul concerne le mot de passe.

Ce que le magasin du client doit contenir

Deux objets sont en jeu. Le certificat client doit être installé pour l’utilisateur qui exécute le client VPN, avec sa clé privée, et la racine émettrice doit être approuvée. Un fichier .cer ne contient que le certificat public, il ne peut donc rien authentifier à lui seul. Dans le gestionnaire de certificats de Windows, l’identité du client appartient au magasin personnel de l’utilisateur actuel, et la racine au magasin des racines approuvées.

Installer l’identité dans le magasin de la machine, ou seulement dans le magasin des racines, ne satisfait pas une recherche visant le magasin personnel de l’utilisateur. Vérifiez ensemble le magasin, l’indicateur de clé privée et les dates de validité, puis redémarrez le client pour qu’il relise le magasin.

Deux produits, la même accréditation manquante

Les serveurs OpenVPN exigent un certificat client par défaut. Ajouter auth-user-pass à un client envoie un nom d’utilisateur et un mot de passe, et la poignée de main TLS demande toujours un certificat, donc un mot de passe seul ne peut pas établir la connexion sous verify-client-cert require. Le serveur peut être configuré pour n’en exiger aucun, ce qui fait du mot de passe l’unique accréditation du client et constitue une réelle perte de robustesse. Un script shell derrière auth-user-pass-verify peut valider les identifiants, et il exige que l’exécution de scripts soit activée, ce qui en fait une conception plus risquée qu’un véritable backend d’authentification.

Un profil reposant uniquement sur un mot de passe dépend aussi d’options poussées, qui dépendent elles-mêmes de l’activation du mécanisme de récupération.

Ne corrigez pas un certificat manquant en désactivant les contrôles

La tentation est d’assouplir la vérification pour faire disparaître le message. Cela supprime le contrôle qui faisait son travail et laisse une connexion qui ne prouve plus ce qu’elle prétend. Si la passerelle a récemment changé sa racine, retéléchargez le paquet client au lieu de modifier le profil, car l’ancien paquet peut encore porter la racine précédente. Si l’option d’authentification par certificat manque dans l’éditeur de profils, la version de Windows installée n’expose peut-être pas cette méthode ; mettez le système à jour au lieu de modifier le XML à la main.

Notez quel magasin contenait le certificat, quel utilisateur a exécuté le client et si la clé privée était présente. Ces trois éléments expliquent presque tous les cas de cet échec.

Le mot de passe était bon. L’accréditation dont la méthode avait réellement besoin se trouvait ailleurs.