Hvilket maskinsertifikat tilbyr Windows-VPN-en?

Sertifikatene er installert, de private nøklene er til stede, og tunnelen feiler fortsatt på autentiseringen. En maskin med flere sertifikater kan gi VPN-en en kandidat ingen hadde tenkt på, og klienten har ingen måte å vite hvilket gatewayen ville godta. Å slette de andre er en utvelgelsespolicy med konsekvenser for hver tjeneste på maskinen. Snevre heller inn det gyldige settet, og bekreft deretter hvilket sertifikat som faktisk ble tilbudt.

Flere sertifikater, ett tilbudt

Innebygde Windows VPN-profiler med maskinsertifikatautentisering eksponerer to filtre som begrenser kandidatene: et utstederfilter og et filter for utvidet nøkkelbruk. De reduserer settet klienten kan velge fra. De reparerer ikke et uegnet sertifikat, og de garanterer ikke at serveren godtar det som blir igjen. Den grensen er verdt å føre inn i endringsloggen, fordi neste leser vil anta at filteret avgjorde mer enn det gjorde.

Feilen de tar tak i, er smal og konkret. Et gyldig sertifikat fra feil myndighet, eller ett utstedt for et formål gatewayen ikke godtar, blir valgt foran det tiltenkte, noe som gir en autentiseringsfeil ved siden av et sunt lager. To filtre gjør det om til et sett som er lite nok til å resonnere om, og resten av denne siden bruker dem i rekkefølge.

Undersøk lageret før du redigerer profilen

List kandidatene og egenskapene deres i lageret profilen faktisk bruker. Ingenting her eksporterer en privat nøkkel, og ingen sertifikater trenger å forlate maskinen:

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

Les utdataene for egenskapene beslutningen avhenger av: en brukbar privat nøkkel, et akseptabelt gyldighetsvindu, den tiltenkte utstederen og formålene i utvidelsen. Et sertifikat kan være til stede, riktig registrert og ubrukelig for denne tilkoblingen samtidig. Fingeravtrykkolonnen er den du senere sammenligner med, så ta vare på utdataene.

Bekreft profilen og omfanget før du redigerer, fordi et maskinsertifikat i LocalMachine, et bruker-EAP-TLS-sertifikat og en applikasjons eget lager for private nøkler er tre forskjellige kontekster. Bruk omfanget for alle brukere og en administrativ kontekst når den administrerte profilen ligger der. Å opprette en annen profil med lignende navn skjuler hvilken konfigurasjon tilkoblingen faktisk bruker.

Utstederfilteret vil ha et objekt

Utstederparameteren forventer et sertifikatobjekt, ikke et visningsnavn og ikke en bar fingeravtrykkstreng. Oppgi sertifikatet til den godkjente myndigheten fra en sti du har gjennomgått, i lageret der det hører hjemme:

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

Ikke erstatt klientens eget bladsertifikat, en annen myndighet med lignende subjekt eller en nygenerert rot bare fordi parametertypen godtar det. To myndigheter kan dele en subjektstreng, og derfor betyr objektet mer enn teksten. Microsofts cmdlet-referanse dokumenterer begge inndatatyper, og det er verdt å lese den før den første redigeringen i stedet for etter det mislykkede forsøket.

Bruksfilteret vil ha en OID-streng

Parameteren for utvidet nøkkelbruk tar OID-strenger, og formålet med klientautentisering er 1.3.6.1.5.5.7.3.2. Anvendt begrenser det kandidatene til sertifikater som bærer dette formålet, som er nettopp det en utrulling med klientautentisering vil ha:

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

Verdien er en matrise, så en utrulling som trenger flere formål sender dem som en liste. Det filteret ikke kan, er å legge et formål til et sertifikat: det er et uttrykk for utvalg som evalueres mot signerte utvidelser, og ingen filter skriver dem om, så et sertifikat som mangler formålet, må gjennom registreringen igjen.

Hold EAP-konfigurasjonen for brukersertifikater atskilt fra filtreringen av maskinsertifikater, fordi de lever på forskjellige steder og en endring i det ene forklarer sjelden en feil i det andre. Sjekk også om domenet eller enhetsadministrasjonen eier profilen, fordi en lokal endring kan bli erstattet ved neste policyoppdatering uten at noen rører maskinen.

Bevis hvilket sertifikat klienten tilbød

Etabler en ny tilkobling og les klientens og serverens autentiseringsbevis for identiteten du mente. Når mer enn ett sertifikat oppfyller filtrene, er resultatet et mindre utvalg i stedet for et festet blad, så neste forsøk kan velge et annet medlem. Noter fingeravtrykket som vises i beviset, og sammenlign det med det du registrerte fra lageret.

En vellykket kommando er ikke en vellykket autentisering. Resultatet det er verdt å registrere, er at det tiltenkte sertifikatet autentiserer under den administrerte policyen, mens hvert uvedkommende sertifikat forblir tilgjengelig for tjenestene som er avhengige av det. Overlever feilen begge filtrene, er de gjenværende kandidatene neste sted å se, ikke hele profilen.