La connexion PIV échoue sous Windows avec EAP-TLS ? Vérifiez le chemin de signature

Affichez le certificat d’une carte PIV dans chaque boîte de dialogue Windows et la connexion VPN peut malgré tout échouer, car visibilité et utilisabilité sont deux propriétés différentes. Le certificat est un objet public ; la connexion exige une opération de clé privée exécutée par la carte selon ses propres règles d’accès. Entre ces deux faits se trouvent quatre étapes qui échouent de quatre manières différentes : sélection du profil, sélection du certificat, signature locale et validation côté serveur. Les parcourir dans l’ordre transforme une erreur de poignée de main générique en une question précise pour celui qui détient la pièce suivante.

Commencez par le profil et la méthode EAP

Ouvrez les propriétés de la connexion et lisez quelle méthode EAP le profil utilise réellement, puis lisez quel certificat la méthode est configurée pour sélectionner. Beaucoup de déploiements ont à la fois une méthode externe fondée sur certificat et une méthode interne, et un certificat configuré au niveau de la connexion n’est pas automatiquement celui présenté dans EAP-TLS. Si le profil choisit un certificat par émetteur ou par filtre de sujet, ce filtre choisit parmi ce que Windows peut voir dans le magasin concerné, et non parmi ce que la carte contient. Un filtre qui ne correspond à rien revient à une invite ou à un échec silencieux selon la configuration du profil, c’est pourquoi il vaut la peine de noter l’empreinte sélectionnée avant tout changement.

Déterminez aussi si la connexion s’exécute en tant qu’utilisateur connecté ou en tant que machine. Ce seul fait décide quels magasins de certificats entrent dans le périmètre et quel contexte de sécurité effectue la signature.

Confirmez quel certificat a été sélectionné

Comparez l’empreinte choisie par Windows à l’exigence : usage pour l’authentification du client, une chaîne qui se termine à une racine approuvée, une identité que la stratégie du serveur d’authentification met en correspondance, et une période de validité qui couvre le moment réel de la tentative. Ce sont des contrôles distincts et le dernier attrape plus de surprises qu’on ne l’attend, surtout avec des certificats délivrés en continu et des profils en cache qui pointent encore vers la sélection de la veille.

Le contexte utilisateur et le contexte machine constituent l’autre moitié du contrôle. Un certificat du magasin personnel de l’utilisateur est invisible pour un service qui s’exécute en tant que machine, et un certificat de machine n’est pas présenté par un échange EAP en mode utilisateur sauf si le profil le prévoit. Réimporter un certificat dans le mauvais magasin produit un certificat visible et un justificatif de connexion invisible. Lisez le chemin du magasin dans le profil, pas celui de la boîte de dialogue qui s’est ouverte par hasard.

Testez l’opération de clé sans deviner le code PIN

Une fois la sélection réglée, la question est de savoir si la carte effectuera la signature. Windows a besoin d’un fournisseur de carte pris en charge ou d’un minidriver pour atteindre la clé privée, et le périphérique applique ses propres règles de code PIN et de présence à l’opération. Une carte configurée pour exiger un toucher à chaque signature se comporte différemment d’une carte qui met en cache une vérification pour une session, et les deux sont des configurations légitimes qui changent le moment où une invite apparaît. Cette différence explique une connexion qui réussit à l’insertion et échoue après une reprise, sans qu’aucun certificat ne soit erroné.

certutil.exe -scinfo
certutil.exe -store -user My
Get-WinEvent -LogName Application -MaxEvents 40 | Where-Object ProviderName -like '*Ras*'

La première commande inventorie la carte et signale l’état du lecteur et du fournisseur, ce qui est documenté dans le guide Microsoft de débogage des cartes à puce. La seconde énumère ce que le contexte utilisateur peut réellement voir. Ni l’une ni l’autre ne prouve une authentification réussie ; toutes deux resserrent l’endroit où cela s’est arrêté.

Ne devinez pas le code PIN. Les cartes appliquent des limites de tentatives, et quelques essais optimistes transforment un problème de droits en un justificatif bloqué qui exige une récupération administrative. Si une signature locale échoue, relevez l’état du fournisseur et l’état de la carte au lieu d’essayer des variantes. Répétez la tentative une fois avec le même profil, le même certificat et un chemin de lecteur connu comme bon, puis comparez les deux relevés ; changer plusieurs variables à la fois produit un récit et non un résultat.

Lisez les deux côtés de la poignée de main

Une signature terminée n’est pas encore une admission. Le serveur d’authentification doit accepter la chaîne, vérifier la révocation, mettre l’identité en correspondance selon ses règles actuelles et autoriser la demande ; le client doit quant à lui valider le certificat du serveur comme le profil l’exige. Une alerte TLS générée par le serveur apparaît dans le journal du client comme une alerte générée localement, c’est pourquoi le côté qui l’émet compte plus que le texte de l’alerte.

Rassemblez les événements Windows et les événements côté serveur avec des horodatages alignés, puis identifiez quel côté a produit le premier échec. RFC 5216 décrit l’étape de preuve de possession dans EAP-TLS, et une alerte de poignée de main générique ne nomme pas à elle seule une cause locale liée à la clé. C’est la comparaison des horodatages qui transforme deux journaux en une séquence.

Gardez les frontières nettes dans le rapport

Rédigez le rapport comme quatre étapes avec un verdict chacune : quel profil et quel contexte ont été exécutés, quel certificat Windows a sélectionné, si la carte a signé et ce que le serveur a décidé. Cette structure rend l’étape suivante évidente et évite la réparation courante consistant à désactiver la validation pour franchir une étape que personne n’a identifiée.

Un certificat logiciel comme comparaison temporaire est un test d’administrateur légitime, mais il change le modèle de justificatif et de garantie, il relève donc d’un changement approuvé et non d’un contournement discret en production. La même discipline s’applique aux tentatives de code PIN et à la réémission de justificatifs avant que l’étape défaillante soit connue. Une carte de remplacement qui échoue à l’identique est une preuve coûteuse que le problème n’a jamais été sur la carte.