Vilket maskincertifikat erbjuder Windows-VPN:en?

Certifikaten är installerade, de privata nycklarna finns och tunneln misslyckas fortfarande med autentiseringen. En maskin med flera certifikat kan ge VPN:en en kandidat som ingen avsåg, och klienten har inget sätt att veta vilket gatewayen skulle acceptera. Att radera de andra är en urvalspolicy med konsekvenser för varje tjänst på maskinen. Begränsa i stället den tillåtna mängden och bekräfta sedan vilket certifikat som faktiskt erbjöds.

Flera certifikat, ett erbjudet

Inbyggda Windows VPN-profiler med maskincertifikatautentisering exponerar två filter som begränsar kandidaterna: ett utfärdarfilter och ett filter för utökad nyckelanvändning. De minskar mängden som klienten kan välja från. De reparerar inte ett olämpligt certifikat och garanterar inte att servern accepterar det som blir kvar. Den gränsen är värd att skriva in i ändringsloggen, eftersom nästa läsare kommer att anta att filtret avgjorde mer än det gjorde.

Felet de åtgärdar är snävt och konkret. Ett giltigt certifikat från fel myndighet, eller ett som utfärdats för ett ändamål som gatewayen inte accepterar, väljs före det avsedda, vilket ger ett autentiseringsfel bredvid ett friskt lager. Två filter gör det till en mängd som är liten nog att resonera om, och resten av den här sidan tillämpar dem i ordning.

Granska lagret innan du redigerar profilen

Lista kandidaterna och deras egenskaper i det lager som profilen faktiskt använder. Inget här exporterar en privat nyckel, och inget certifikat behöver lämna maskinen:

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

Läs utdata för de egenskaper som beslutet beror på: en användbar privat nyckel, ett acceptabelt giltighetsfönster, den avsedda utfärdaren och ändamålen i tillägget. Ett certifikat kan vara närvarande, korrekt registrerat och oanvändbart för den här anslutningen samtidigt. Fingeravtryckskolumnen är den du senare jämför med, så spara utdata.

Bekräfta profilen och dess omfång innan du redigerar, eftersom ett maskincertifikat i LocalMachine, ett användar-EAP-TLS-certifikat och en applikations eget lager för privata nycklar är tre olika sammanhang. Använd omfånget för alla användare och ett administrativt sammanhang när den hanterade profilen ligger där. Att skapa en andra profil med liknande namn döljer vilken konfiguration anslutningen faktiskt använder.

Utfärdarfiltret vill ha ett objekt

Utfärdarparametern förväntar sig ett certifikatobjekt, inte ett visningsnamn och inte en bar fingeravtryckssträng. Ange den godkända myndighetens certifikat från en sökväg du har granskat, i det lager där det hör hemma:

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

Ersätt inte klientens eget lövcertifikat, en annan myndighet med liknande subjekt eller en nygenererad rot bara för att parametertypen accepterar det. Två myndigheter kan dela en subjektsträng, och därför väger objektet tyngre än texten. Microsofts cmdlet-referens dokumenterar båda indatatyperna, och den är värd att läsa före den första redigeringen i stället för efter det misslyckade försöket.

Användningsfiltret vill ha en OID-sträng

Parametern för utökad nyckelanvändning tar OID-strängar, och ändamålet för klientautentisering är 1.3.6.1.5.5.7.3.2. Tillämpat begränsar det kandidaterna till certifikat som bär det ändamålet, vilket är precis vad en driftsättning med klientautentisering vill ha:

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

Värdet är en matris, så en driftsättning som behöver flera ändamål skickar dem som en lista. Det filtret inte kan är att lägga till ett ändamål på ett certifikat: det är ett urvalsuttryck som utvärderas mot signerade tillägg, och inget filter skriver om dem, så ett certifikat som saknar ändamålet måste gå igenom registreringen igen.

Håll EAP-konfigurationen för användarcertifikat åtskild från filtreringen av maskincertifikat, eftersom de lever på olika ställen och en ändring i det ena sällan förklarar ett fel i det andra. Kontrollera också om domänen eller enhetshanteringen äger profilen, eftersom en lokal ändring kan ersättas vid nästa principuppdatering utan att någon rör maskinen.

Bevisa vilket certifikat klienten erbjöd

Upprätta en ny anslutning och läs klientens och serverns autentiseringsbevis för den identitet du avsåg. När mer än ett certifikat uppfyller filtren blir resultatet en mindre urvalsgrupp i stället för ett fäst löv, så nästa försök kan välja en annan medlem. Notera fingeravtrycket som visas i beviset och jämför det med det du registrerade från lagret.

Ett lyckat kommando är inte en lyckad autentisering. Resultatet som är värt att registrera är att det avsedda certifikatet autentiserar under den hanterade principen medan varje orelaterat certifikat förblir tillgängligt för de tjänster som är beroende av det. Om felet överlever båda filtren är de återstående kandidaterna nästa ställe att titta på, inte hela profilen.