Le certificat est visible dans Windows, mais OpenVPN ne peut pas utiliser sa clé

Le certificat est visible dans l’observateur de certificats de Windows, et le client ne peut toujours pas l’utiliser. Voir un certificat prouve seulement qu’un objet public existe dans un magasin. Cela ne prouve pas que le processus de connexion trouve la clé privée correspondante ni qu’il est autorisé à l’utiliser.

Trois objets doivent s’aligner. Le certificat sélectionné, la clé privée derrière lui et le compte sous lequel le client s’exécute sont des choses distinctes, et chacune peut échouer de son côté.

Trois objets, trois réponses

La version communautaire d’OpenVPN sous Windows documente un sélecteur de magasin CryptoAPI, cryptoapicert, qui prend une empreinte. La valeur doit désigner le certificat que vous voulez réellement utiliser, pas un autre au nom similaire. D’autres applications basées sur OpenVPN peuvent avoir un modèle d’importation complètement différent, le sélecteur ne prouve donc que pour la compilation qui le documente. Confirmez que votre client implémente ce mécanisme avant de déboguer quoi que ce soit en aval.

Si la compilation ne prend pas en charge le sélecteur, la solution est un autre format de profil, pas un autre certificat.

Le sélecteur résout-il la bonne identité

Un certificat public peut être importé sans sa clé privée. L’observateur l’affiche dans les deux cas, et c’est pourquoi cette panne ressemble à un client qui ignore un certificat bien présent. Vérifiez l’association de la clé, pas seulement la présence de l’entrée.

Un certificat renouvelé ajoute un second piège. Les deux entrées peuvent rester dans le magasin alors que le profil nomme encore l’empreinte plus ancienne, et le client continue de sélectionner l’identité que vous vouliez retirer.

Vérifiez à quelle identité le sélecteur résout avant de regarder les autorisations. Une empreinte erronée échoue de la même façon qu’une clé absente.

Ce compte peut-il utiliser la clé

L’accès à la clé est par compte. Un service, une tâche planifiée et une session de bureau interactive peuvent avoir des vues différentes du magasin et des autorisations différentes pour utiliser une clé privée. Le fait que le certificat soit visible dans votre propre session ne dit rien du compte de service.

Une clé adossée à un matériel peut avoir besoin de son fournisseur et d’une étape de confirmation. Un service qui ne peut pas afficher d’invite ne sera pas sauvé par l’export de la clé vers un fichier simple.

Lisez l’erreur locale avant de changer quoi que ce soit. Un échec de sélection, un échec de signature et un rejet distant sont trois issues différentes. Seules les deux premières sont locales. La troisième signifie que la clé a fonctionné et que le serveur a décidé contre le certificat.

L’usage local n’est pas une acceptation distante

Un succès local n’est pas une autorisation. Une fois que le client a signé avec sa clé, le serveur évalue encore l’émetteur, la fenêtre de validité, le rôle et sa politique d’accès. Un autre certificat de la même AC ne porte pas automatiquement les mêmes droits VPN.

Le serveur a besoin de la chaîne de confiance, pas d’une copie de la clé privée du client. Envoyer la clé au serveur n’est jamais la réparation d’un problème de vérification.

Traitez la panne dans l’ordre

Conservez le texte exact de l’erreur. Une autorisation de clé manquante ne doit pas se transformer en changement d’AC, et un rejet distant ne doit pas se transformer en réparation du magasin. Chacun a ses propres preuves.

Travaillez dans l’ordre où la panne apparaît : sélecteur, clé, compte, puis politique du serveur. La référence communautaire du client documente le sélecteur de magasin de Windows pour la version que vous exécutez.