Gateway-sertifikatet er i orden: kvifor IKEv2 PEAP-innlogging framleis feilar

Sertifikatet til VPN-gatewayen din er gyldig, kjeda blir validert, og IKEv2-klienten avviser framleis innlogginga med ei melding om eit sertifikats gyldigheitsintervall. Den første impulsen er å utsteda gateway-sertifikatet på nytt eller byta EAP-metode, og begge er vanlegvis feil. Innloggingsforsøket ber to separate serveridentitetar: gateway-sertifikatet som IKE brukar, og sertifikatet som blir presentert av det som avsluttar PEAP. Den eine er i orden, og den andre er grunnen til at klienten stoppa.

To identitetar, eitt innloggingsforsøk

Sertifikatet i VPN-profilen høyrer til IKE-utvekslinga: det bevisar at gatewayen er parten profilen namngir, under den konfigurerte IKE-policyen. Sertifikatet som feilar her, høyrer til ein annan samtale, TLS-økta som PEAP opnar med det som autentiserer brukaren, som ofte er ein RADIUS-server som NPS og ikkje gatewayen sjølv. Ein tredje kontroll, påloggingsinformasjonen til brukaren, skjer inne i den økta. Eit gyldig passord kan ikkje reparera eit utløpt server sertifikat, og eit gyldig gateway-sertifikat kan ikkje gå god for PEAP-endepunktet.

Denne lagdelinga forklarar kvifor ein sertifikatfeil dukkar opp på ein stad der det einaste sertifikatet nokon konfigurerte, var gatewayen sitt. Ho forklarar òg kvifor ny utsteding av det sertifikatet ikkje endrar noko.

Les logglinja mot stadiet

Finn meldinga som namngir årsaka og datoane. Ei klage på gyldigheitsintervallet ved sida av ein subjektfeil betyr at serveren avviste sertifikatet han fekk, ikkje at brukaren avviste innlogginga. Finn deretter stadiet: ein strongSwan charon-logg viser IKE_SA .* established før EAP-utvekslinga byrjar, så ein sertifikatfeil etter den linja høyrer til EAP-identiteten, medan ein feil før ho peikar på gatewayen. Stadieteksten i eit Windows-klients tilkoplingspanel seier det same.

Sjekk klokka til klienten før du rører noko sertifikat. Eining som går timar feil, gir same gyldigheitsfeil som eit verkeleg utløpt sertifikat. Å stilla klokka er ei retting på fem sekund, og å byta ut eit sertifikat som aldri var problemet, er eit avbrot.

Finn ut kva endepunkt som avsluttar PEAP

I eit design med gateway pluss RADIUS videresender gatewayen EAP og avsluttar det ikkje. eap-radius-pluginen til strongSwan gir utvekslinga til RADIUS-serveren, som eig PEAP TLS-økta og sertifikatet hennar. Korreler eitt mislukka forsøk på tvers av begge loggane og stadfest kva prosess som faktisk valde eit sertifikat for den økta.

For NPS må sertifikatet liggja i det lokale datamaskinlageret, ha føremålet serverautentisering, samsvara med namnet klientane ventar, og vera lesbart for tenestekontoen. Microsoft sine sertifikatkrav for NPS listar opp desse vilkåra. Andre EAP-serverar har eigne utvalsreglar, så ikkje kopier NPS-spesifikke ting til ein FreeRADIUS-installasjon eller omvendt. Regelen som held i begge tilfelle, er at endepunktet som avsluttar PEAP, eig sertifikatet du er i ferd med å endra.

Byt ut sertifikatet der EAP avsluttast

Forny eller byt ut sertifikatet på endepunktet som avsluttar PEAP, gjennom den støtta prosessen, og hald på føremålet serverautentisering og det venta namnet. Installer heile kjeda der tenesta leitar etter henne, og gi tenesta tilgang til den private nøkkelen. Start tenesta på nytt eller bind henne på nytt, fordi mange tenester held på det gamle sertifikatet i minnet og held fram med å presentera det. Ei fil som er kopiert til maskinen, bevisar ingenting om kva sertifikat tenesta faktisk presenterer.

Stadfest endringa ved å korrelera neste forsøk med tenesta sin eigen logg, eller ved å inspisera sertifikatet økta presentererte. Viss den loggen framleis viser det gamle fingeravtrykket, verka ikkje omstarten.

Ikkje gå ut frå at den nyaste fila i ei mappe er den som blir brukt. Ei kopi med rett namn og feil løyve endrar ingenting. Vurder endringa etter den presentererte identiteten, ikkje etter eit filstempel.

Kva du ikkje bør gjera

Ikkje slå av PEAP-validering og ikkje tving gjennom ein svakare indre metode for å koma forbi feilen. Det endrar policyen og fjernar serverautentiseringseigenskapen som fanga det utløpte sertifikatet i utgangspunktet. Du ville byta ein fungerande kontroll mot ei fungerande tilkopling, og det neste utløpte sertifikatet ville koma utan noko som varsla om det.

Ikkje sjå på ei vellukka tilkopling frå eit anna operativsystem som prov på at sertifikatet er akseptabelt. Den klienten brukar kanskje ein annan EAP-metode, eit anna tillitslager eller inga servervalidering i det heile, så suksessen seier ingenting om kontrollen som feila her. Hald på éin medviten negativ test, til dømes eit sertifikat med feil namn eller ei ubetrodd kjede, som feilar som venta. Viss den testen no går gjennom, har du fjerna ein kontroll i staden for å reparera eit sertifikat. Skriv ned kva identitet som feila, slik at neste person ikkje byrjar på nytt med gateway-sertifikatet.