Pourquoi OpenVPN demande encore un fichier de clé privée alors qu’un jeton est présent

Vous branchez le jeton, l’outil du fournisseur lui-même le voit, et le client VPN demande toujours un fichier de clé privée. Cette invite ne prouve pas que le jeton n’est pas pris en charge. Elle signifie généralement que le profil n’a jamais dit au client d’utiliser le jeton, si bien qu’il est revenu aux entrées de certificat et de clé qu’il attend par défaut.

Deux valeurs distinctes doivent être correctes avant que ce repli cesse : le fournisseur qui expose le jeton et l’identité du certificat qu’il contient. Elles sont fournies par des options différentes et sont faciles à confondre.

Le client demande un fichier parce que le profil le lui dit

Un profil par défaut attend un fichier de certificat et un fichier de clé privée, ou un seul lot PKCS#12. Quand ces entrées manquent, le client n’a rien à charger et se comporte presque comme si le fichier manquait, ce qui fait lire le symptôme comme un chemin cassé plutôt que comme un mécanisme absent. Le chemin PKCS#11 remplace ces entrées au lieu de les compléter, si bien qu’un profil qui nomme encore un fichier de clé continuera d’utiliser ce fichier. Supprimez délibérément les entrées de fichier et laissez le jeton fournir les deux moitiés.

L’option de fournisseur nomme une bibliothèque d’intergiciel, pas un appareil ni un certificat. Qu’un client empaqueté puisse charger cette bibliothèque dépend de la façon dont il a été compilé, y compris la prise en charge facultative de p11-kit que certaines compilations activent et d’autres omettent. Un tutoriel générique ne peut pas vous dire quelle disposition a votre paquet.

L’identité sérialisée est une autre valeur

L’identité du certificat est une longue chaîne sérialisée produite par le processus de découverte, et ce n’est ni le chemin de la bibliothèque, ni le PIN du jeton, ni le nom du compte VPN. Elle contient souvent des caractères à mettre entre guillemets, et une valeur non citée peut être tronquée ou mal lue sans erreur claire. Utilisez l’option découverte d’identité du client lui-même pour lister ce que le jeton expose, puis copiez exactement l’entrée voulue. Choisir le premier objet de la liste est la manière dont un appareil finit par présenter le mauvais certificat.

La sortie de la découverte répond aussi à une question préalable : si le jeton est visible ou non à travers ce fournisseur. Si elle ne liste rien, le problème se situe en amont du client VPN et relève de l’intergiciel.

Le processus qui se connecte doit atteindre le jeton

Une opération sur le jeton qui fonctionne dans votre session de bureau ne prouve rien pour un service système. Le service peut s’exécuter sous un autre utilisateur, dans un autre espace de noms de montage, avec un chemin de modules qui omet la bibliothèque du fournisseur, ou sans la permission d’ouvrir le nœud de l’appareil. Identifiez le processus qui détient réellement la connexion et testez depuis ce contexte.

Le traitement du PIN mérite sa propre décision. L’implémentation de référence propose un cache de PIN et un chemin d’authentification protégé, et les deux existent pour qu’un opérateur choisisse un flux de travail au lieu d’en inventer un. Ne transformez pas une exigence sans surveillance en PIN en clair dans un profil partagé, car cela échange la protection du jeton contre du confort. Là où le jeton interdit l’exportation de la clé, la signature a lieu sur l’appareil et le PIN est le seul secret local. Traitez-le avec le soin que cela implique.

Ce que le jeton ne remplace pas

Le jeton authentifie le client selon la politique déployée, et il ne remplace pas les contrôles du client sur le serveur. Un certificat sélectionné avec succès n’est pas l’autorisation d’accepter un certificat de passerelle inattendu, et les deux vérifications protègent des directions opposées.

L’enrôlement doit toujours avoir lieu chez l’émetteur, et la passerelle doit toujours autoriser l’identité.

Pour l’acceptation, séparez les étapes : le fournisseur se charge, le certificat visé est trouvé, la clé privée est utilisée avec une autorisation locale, le VPN s’authentifie et l’opération sur la ressource réussit. Arrêtez-vous à la première étape qui échoue au lieu de parcourir des mots de passe et de réinstaller la pile cryptographique.

Consignez les versions, la propriété des modules, l’identifiant public retenu et les erreurs nettoyées, et laissez les PIN et les lots d’identifiants hors de ce journal.