Quel URI PKCS#11 OpenConnect attend-il pour un jeton ?

Une carte à puce qui contient déjà la bonne clé doit tout de même savoir quel objet y utiliser. OpenConnect ne veut pas d’un fichier .key copié dans cette situation ; il veut un URI PKCS#11 qui nomme le certificat et, quand la recherche automatique ne peut pas terminer le travail, la clé privée à côté. Le point délicat, c’est qu’un URI syntaxiquement valide ne prouve rien. Il doit nommer l’enrôlement auquel la passerelle fait déjà confiance, pas simplement un objet que la carte accepte d’ouvrir.

Ce que le client veut au lieu d’une clé exportée

L’option -c prend normalement un chemin de fichier, mais lorsque la valeur s’analyse comme un URI PKCS#11, OpenConnect la traite comme une référence à un objet à l’intérieur du jeton plutôt qu’à un fichier sur le disque. L’option -k se comporte de la même façon pour la clé privée. Rien n’est exporté, et la clé ne quitte jamais la protection que la carte assure. Ce dont le client a besoin de vous, c’est d’un nom sur lequel le module du jeton, le magasin de certificats et l’enrôlement de la passerelle s’accordent.

C’est sur cette dernière contrainte que la plupart des tentatives calent. Un URI peut être parfaitement bien formé et tout de même sélectionner un certificat que la passerelle rejettera, car validité et pertinence sont deux questions distinctes. La vérification qui vaut la peine est une comparaison avec l’enregistrement d’enrôlement, pas une recherche du premier objet qui s’ouvre par hasard.

Deux URI, deux tâches différentes

L’URI du certificat répond à quelle identité vous prétendez. Il pointe vers un objet de certificat dont la clé publique et la ligne de sujet correspondent au profil de compte ou d’appareil émis par l’administrateur du VPN. Ce même certificat arrive généralement avec un objet de clé privée stocké à côté, et c’est cette paire dont la poignée de main TLS a réellement besoin.

L’URI de la clé répond à où se trouve le matériel privé correspondant quand OpenConnect ne peut pas le déduire. Avec seulement -c défini, le client construit une recherche de clé à partir des propriétés du certificat ; fournir -k remplace la conjecture par une référence explicite à un objet. Le PIN du jeton est une troisième entrée, sans rapport : il déverrouille la carte pour l’opération et n’identifie jamais un objet.

openconnect --protocol=anyconnect \
  -c 'pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=1a2b3c4d;id=%01' \
  vpn.example.net

Tout dans cette chaîne entre guillemets est une donnée. Les points-virgules séparent les attributs de l’URI et les échappements en pourcentage encodent des caractères qui casseraient autrement l’analyse, donc l’argument entier doit survivre intact au shell.

Trouver l’URI qui correspond à votre enrôlement

GnuTLS fournit p11tool, qui énumère ce que l’utilisateur courant peut réellement atteindre via p11-kit. Commencez par p11tool --list-tokens, puis énumérez les objets de certificat sur le jeton qui vous intéresse. Ajoutez --login quand les objets n’apparaissent qu’après un PIN, et comparez le sujet et l’émetteur à l’enregistrement d’enrôlement au lieu de choisir ce qui apparaît en premier.

Si le jeton n’apparaît pas du tout, le problème se situe sous OpenConnect : p11-kit n’a aucun module enregistré pour cet intergiciel, ou le module est enregistré pour un autre compte. L’enregistrement à l’échelle du système se trouve sous /etc/pkcs11/modules, et un répertoire par utilisateur peut contenir la même chose sans toucher à la copie système. Vérifiez que le chemin du fournisseur dans le fichier du module pointe vers une bibliothèque que le logiciel du lecteur a réellement installée.

Lorsque vous copiez l’URI depuis la liste, gardez les guillemets autour. Des points-virgules non protégés tronquent l’argument au premier attribut et le client signale alors un objet qu’il ne trouve pas.

Quand la recherche automatique de clé abandonne

OpenConnect peut déduire une recherche de clé à partir de l’URI du certificat, mais la correspondance exacte qu’il effectue dépend de la version, et le traitement du type d’objet et de l’étiquette a changé au fil du temps. Le conseil de raccourcir l’URI jusqu’à ce que ça marche décrit un ancien contournement, pas une exigence. Si la recherche déduite échoue, nommez la clé explicitement avec -k au lieu de transformer l’URI du certificat en quelque chose de plus vague.

Confirmez que la clé existe et est visible avec p11tool --list-keys avant d’accuser le client. Vérifiez ensuite que l’objet est marqué comme utilisable pour la signature ou le déchiffrement, car une clé générée avec de mauvais attributs ne peut pas terminer une poignée de main, quelle que soit l’exactitude de l’URI. Ne transplantez pas une valeur pkcs11-id sérialisée d’un profil OpenVPN dans une option OpenConnect ; les deux clients utilisent des formats d’identifiant différents même lorsqu’ils parlent à la même carte.

Si l’URI se résout et que le PIN est accepté mais que l’authentification échoue encore, arrêtez d’ajuster l’URI. Lisez l’erreur de la passerelle elle-même, car l’échec suivant se situe en amont du jeton.

Des échecs qui ne ressemblent qu’à des problèmes d’URI

Une passerelle qui parle un autre protocole échouera de la même manière, que votre URI soit correct ou non. OpenConnect a remplacé l’ancien client vpnc pour une raison, et la prise en charge des cartes ne rend pas compatible un protocole de passerelle incompatible. Confirmez le protocole attendu du serveur et la disposition d’authentification avant de passer une heure de plus sur les attributs de l’objet.

La validation de l’identité du serveur est aussi une couche distincte. Le client vérifie le certificat de la passerelle auprès de son magasin de confiance, et cette vérification s’exécute après que la carte a déjà fait sa part. Les permissions du lecteur et un service pcscd arrêté produisent le même symptôme extérieur, un jeton illisible, avec une correction bien plus simple.

Travaillez de l’objet vers l’extérieur : p11tool voit-il le jeton, voit-il le certificat et la clé, OpenConnect accepte-t-il l’URI, et seulement alors demandez si la passerelle accepte l’identité. Chaque étape a son propre message d’erreur, et chacune est moins coûteuse à tester que la suivante.