Quel certificat machine le VPN Windows propose-t-il ?

Les certificats sont installés, les clés privées sont présentes, et le tunnel échoue toujours à s’authentifier. Une machine qui détient plusieurs certificats peut fournir au VPN un candidat que personne n’avait prévu, et le client n’a aucun moyen de savoir lequel la passerelle accepterait. Supprimer les autres est une politique de sélection qui a des conséquences sur chaque service de la machine. Restreignez plutôt l’ensemble éligible, puis confirmez quel certificat a réellement été proposé.

Plusieurs certificats, un seul proposé

Les profils VPN natifs de Windows avec authentification par certificat machine exposent deux filtres qui restreignent les candidats : un filtre d’émetteur et un filtre d’usage étendu de la clé. Ils réduisent l’ensemble dans lequel le client peut choisir. Ils ne réparent pas un certificat inadapté et ne garantissent pas que le serveur accepte ce qui reste. Cette limite mérite d’être consignée dans le journal des changements, car le prochain lecteur supposera que le filtre a décidé plus qu’il n’a décidé.

La défaillance qu’ils traitent est étroite et précise. Un certificat valide d’une mauvaise autorité, ou émis pour un usage que la passerelle n’accepte pas, est choisi avant celui qui était prévu, ce qui produit un échec d’authentification à côté d’un magasin sain. Deux filtres en font un ensemble assez petit pour raisonner, et le reste de cette page les applique dans l’ordre.

Inspectez le magasin avant de modifier le profil

Listez les candidats et leurs propriétés dans le magasin que le profil utilise réellement. Rien ici n’exporte de clé privée, et aucun certificat n’a besoin de quitter la machine :

Get-VpnConnection -Name 'Office' | Select-Object Name, TunnelType, AuthenticationMethod
Get-ChildItem Cert:\LocalMachine\My | Select-Object Subject, Issuer, Thumbprint, NotAfter, HasPrivateKey, EnhancedKeyUsageList

Lisez la sortie pour les propriétés dont dépend la décision : une clé privée utilisable, une fenêtre de validité acceptable, l’émetteur prévu et les usages de l’extension. Un certificat peut être présent, correctement inscrit et inutile pour cette connexion en même temps. La colonne de l’empreinte est celle à laquelle vous comparerez plus tard, alors conservez la sortie.

Confirmez le profil et sa portée avant de modifier, car un certificat machine dans LocalMachine, un certificat EAP-TLS utilisateur et le magasin de clés privées propre à une application sont trois contextes différents. Utilisez la portée de tous les utilisateurs et un contexte administratif lorsque le profil géré s’y trouve. Créer un second profil au nom similaire masque quelle configuration la connexion utilise réellement.

Le filtre d’émetteur veut un objet

Le paramètre d’émetteur attend un objet certificat, pas un nom d’affichage ni une chaîne d’empreinte nue. Fournissez le certificat de l’autorité approuvée depuis un chemin que vous avez vérifié, dans le magasin auquel il appartient :

$issuerPath = Read-Host 'Certificate-provider path for the approved issuer CA'
$issuer = Get-Item -LiteralPath $issuerPath
Set-VpnConnection -Name 'Office' -MachineCertificateIssuerFilter $issuer

Ne remplacez pas le certificat feuille du client lui-même, une autre autorité au sujet similaire ni une racine fraîchement générée simplement parce que le type du paramètre l’accepte. Deux autorités peuvent partager une chaîne de sujet, et c’est pourquoi l’objet compte plus que le texte. La référence des cmdlets Microsoft documente les deux types d’entrée, et il vaut la peine de la lire avant la première modification plutôt qu’après la tentative échouée.

Le filtre d’usage veut une chaîne OID

Le paramètre d’usage étendu de la clé accepte des chaînes OID, et l’usage d’authentification du client est 1.3.6.1.5.5.7.3.2. L’appliquer restreint les candidats aux certificats portant cet usage, ce qui est exactement ce que veut un déploiement d’authentification client :

Set-VpnConnection -Name 'Office' -MachineCertificateEKUFilter '1.3.6.1.5.5.7.3.2'

La valeur est un tableau, donc un déploiement qui a besoin de plusieurs usages les passe sous forme de liste. Ce que le filtre ne peut pas faire, c’est ajouter un usage à un certificat : c’est une expression de sélection évaluée contre des extensions signées, et aucun filtre ne réécrit celles-ci, donc un certificat dépourvu de l’usage doit repasser par l’enregistrement.

Gardez la configuration EAP des certificats utilisateur séparée du filtrage des certificats machine, car elles vivent à des endroits différents et une modification de l’une explique rarement une défaillance de l’autre. Vérifiez aussi si le domaine ou la gestion des appareils possède le profil, car une modification locale peut être remplacée au prochain rafraîchissement de stratégie sans que personne touche la machine.

Prouvez quel certificat le client a proposé

Établissez une nouvelle connexion et lisez les preuves d’authentification du client et du serveur pour l’identité que vous visiez. Lorsque plus d’un certificat satisfait les filtres, le résultat est un vivier plus petit plutôt qu’une feuille épinglée, donc l’essai suivant peut choisir un autre membre. Notez l’empreinte qui apparaît dans ces preuves et comparez-la à celle que vous avez relevée dans le magasin.

Une commande réussie n’est pas une authentification réussie. Le résultat qui mérite d’être consigné, c’est le certificat prévu qui s’authentifie sous la stratégie gérée tandis que chaque certificat sans rapport reste disponible pour les services qui en dépendent. Si la défaillance survit aux deux filtres, ce sont les candidats restants qu’il faut examiner ensuite, et non le profil dans son ensemble.