Gateway-certifikatet er i orden: hvorfor IKEv2 PEAP-indlogning stadig fejler

Dit VPN-gateways certifikat er gyldigt, kæden valideres, og IKEv2-klienten afviser stadig logon med en meddelelse om et certifikats gyldighedsinterval. Den første indskydelse er at genudstede gateway-certifikatet eller skifte EAP-metode, og begge dele er som regel forkert. Logonforsøget bærer to adskilte serveridentiteter: gateway-certifikatet, som IKE bruger, og det certifikat, som præsenteres af det, der afslutter PEAP. Den ene er i orden, og den anden er grunden til, at klienten stoppede.

To identiteter, ét logonforsøg

Certifikatet i VPN-profilen hører til IKE-udvekslingen: det beviser, at gatewayen er den peer, profilen angiver, under den konfigurerede IKE-politik. Det certifikat, der fejler her, hører til en anden samtale, den TLS-session som PEAP åbner med det, der godkender brugeren, hvilket ofte er en RADIUS-server som NPS og ikke gatewayen selv. En tredje kontrol, brugerens legitimationsoplysninger, finder sted inde i den session. En gyldig adgangskode kan ikke reparere et udløbet servercertifikat, og et gyldigt gateway-certifikat kan ikke borge for PEAP-endepunktet.

Denne lagdeling forklarer, hvorfor en certifikatfejl dukker op på et sted, hvor det eneste certifikat, nogen havde konfigureret, var gatewayens. Den forklarer også, hvorfor en genudstedelse af det certifikat ikke ændrer noget.

Læs loglinjen op mod stadiet

Find meddelelsen, der angiver årsagen og datoerne. En klage over gyldighedsinterval ved siden af en subjektfejl betyder, at serveren afviste det certifikat, den fik, ikke at brugeren afviste logon. Find derefter stadiet: en strongSwan charon-log viser IKE_SA .* established, før EAP-udvekslingen begynder, så en certifikatfejl efter den linje hører til EAP-identiteten, mens en fejl før den peger på gatewayen. Stadieteksten i en Windows-klients forbindelsespane siger det samme.

Kontrollér klientens ur, før du rører ved noget certifikat. En enhed, der går timer forkert, giver samme gyldighedsfejl som et virkeligt udløbet certifikat. At stille uret er en fem sekunders rettelse, og at udskifte et certifikat, der aldrig var problemet, er et nedbrud.

Find ud af, hvilket endepunkt der afslutter PEAP

I et design med gateway plus RADIUS videresender gatewayen EAP og afslutter det ikke. strongSwans eap-radius-plugin giver udvekslingen videre til RADIUS-serveren, som ejer PEAP TLS-sessionen og dens certifikat. Korrelér ét mislykket forsøg på tværs af begge logs, og bekræft hvilken proces der faktisk valgte et certifikat til den session.

For NPS skal certifikatet ligge i computerens lokale lager, have formålet servergodkendelse, matche det navn, klienterne forventer, og kunne læses af tjenestekontoen. Microsofts certifikatkrav til NPS oplister disse betingelser. Andre EAP-servere har deres egne udvælgelsesregler, så kopiér ikke NPS-særheder til en FreeRADIUS-installation eller omvendt. Reglen, der holder i begge opsætninger, er, at det endepunkt, der afslutter PEAP, ejer det certifikat, du er ved at ændre.

Udskift certifikatet der, hvor EAP afsluttes

Forny eller udskift certifikatet på det endepunkt, der afslutter PEAP, via den understøttede proces, og bevar formålet servergodkendelse og det forventede navn. Installér hele kæden der, hvor tjenesten leder efter den, og giv tjenesten adgang til den private nøgle. Genstart eller genbind tjenesten, fordi mange tjenester beholder det gamle certifikat i hukommelsen og fortsætter med at præsentere det. En fil, der er kopieret til maskinen, beviser intet om, hvilket certifikat tjenesten faktisk præsenterer.

Bekræft ændringen ved at korrelere det næste forsøg med tjenestens egen log eller ved at inspicere det certifikat, sessionen præsenterede. Hvis den log stadig viser det gamle fingeraftryk, lykkedes genstarten ikke.

Antag ikke, at den nyeste fil i en mappe er den, der bruges. En kopi med det rigtige navn og de forkerte tilladelser ændrer intet. Vurder ændringen på den præsenterede identitet, ikke på et filtidsstempel.

Hvad du ikke skal gøre

Deaktivér ikke PEAP-validering, og tving ikke en svagere indre metode igennem for at komme forbi fejlen. Det ændrer politikken og fjerner den servergodkendelsesegenskab, der fangede det udløbne certifikat i første omgang. Du ville bytte en fungerende kontrol for en fungerende forbindelse, og det næste udløbne certifikat ville ankomme uden noget, der varslede det.

Betragt ikke et andet styresystems vellykkede forbindelse som bevis for, at certifikatet er acceptabelt. Den klient bruger måske en anden EAP-metode, et andet tillidslager eller slet ingen servervalidering, så dens succes siger intet om den kontrol, der fejlede her. Behold én bevidst negativ test, for eksempel et certifikat med forkert navn eller en ubetroet kæde, som fejler som forventet. Hvis den test nu består, har du fjernet en kontrol i stedet for at rette et certifikat. Skriv ned, hvilken identitet der fejlede, så den næste person ikke begynder med gateway-certifikatet igen.