Pourquoi cryptoapicert échoue dans OpenVPN 3 et Connect sous Windows

Vous copiez un profil OpenVPN 2 qui fonctionne dans un client Windows plus récent, et le certificat que l’ancien client trouvait de lui-même n’est plus proposé. La ligne qui le permettait est un sélecteur propre à Windows qui appartient au client Community 2, et l’application plus récente est un autre programme avec un autre chemin d’identifiants. Le profil est inchangé à part cette seule ligne, et c’est précisément ce qui rend la différence difficile à voir.

Trois couches sont confondues dans ce rapport : le client Community, la bibliothèque centrale et l’interface que quelqu’un a installée. Une seule d’entre elles a jamais compris la directive.

Ce que l’option signifie là où elle existe

Dans le client Community OpenVPN 2 sous Windows, cryptoapicert désigne un certificat que le client doit trouver dans le magasin de certificats de Windows plutôt que dans un fichier. C’est une commodité propre à Windows, et elle fonctionne parce que ce client sait énumérer le magasin et remettre la clé obtenue à sa propre pile TLS. La directive fait donc partie du langage de configuration de ce client, et non d’une propriété du protocole OpenVPN. Rien dans le format de transmission ne la transporte.

Copiez la même ligne dans une autre application et vous avez copié un mot que le nouveau programme peut analyser, ignorer ou rejeter. Une directive n’est pas une caractéristique du protocole, et celle-ci n’est même pas une caractéristique de tous les clients qui parlent OpenVPN.

Ce que la bibliothèque centrale expose à la place

OpenVPN 3 Core est une bibliothèque que d’autres applications intègrent, et elle traite les identifiants externes par une API plutôt que par une recherche dans le magasin. L’application hôte fournit une chaîne de certificats puis demande à la bibliothèque de signer avec une clé externe, et la bibliothèque rappelle l’application pour ce faire. C’est une conception plus générale, et cela signifie que l’interface décide quels fournisseurs existent. Dans la gestion des options de la bibliothèque elle-même, cryptoapicert figure parmi les directives qui ne sont pas implémentées, ce qui est cohérent avec ce partage des responsabilités.

L’existence de ces rappels ne signifie pas qu’une application empaquetée donnée énumère le magasin personnel de l’utilisateur courant, prend en charge un fournisseur de clés particulier ou peut mener à bien une invite de carte à puce. Ce sont des propriétés de l’interface, et chacune doit être documentée par l’interface.

Ce que fait à la place l’interface Windows

OpenVPN Connect suit une autre voie : l’opérateur importe un fichier PKCS#12 contenant le certificat et sa clé privée dans un OpenVPN Certificate Store créé à cette fin, puis affecte le certificat externe au profil. C’est une étape d’importation délibérée, et non une découverte automatique de ce qui se trouve dans le magasin personnel. La distinction compte lorsque quelqu’un suppose qu’un certificat installé pour un autre usage apparaîtra simplement dans la liste du client.

L’importation a aussi une conséquence pour la politique de clés, car exporter une clé dans un fichier P12 est exactement ce qu’une clé non exportable est conçue pour empêcher. C’est une question de politique et non de configuration, et elle mérite une réponse avant que quiconque tente l’importation.

Choisissez une voie qui correspond à la politique de la clé

Si l’identifiant est exportable et que la politique autorise l’importation documentée, utilisez le processus d’enrôlement protégé de l’organisation et gardez le P12 temporaire et son mot de passe hors des journaux et des scripts. Si la clé ne doit jamais quitter une carte à puce ou un fournisseur protégé, choisissez une combinaison de client et de fournisseur qui prend explicitement en charge cette exigence, ou obtenez la confirmation du fournisseur pour la version que vous avez installée. Aucune des deux branches n’est une solution de rechange pour l’autre.

Rajouter la directive au profil ne peut pas fournir une intégration que l’application n’a pas. Une version plus récente du client ne l’ajoute pas nécessairement non plus, car la capacité relève de la conception propre de l’interface.

Une fois la clé locale opérationnelle, le serveur vérifie encore l’identité du certificat, la chaîne et l’autorisation. Une clé locale utilisable et une identité VPN acceptée sont des résultats distincts, et les garder distincts est ce qui empêche une limitation de l’interface de se transformer en politique de certificats affaiblie.