Gateway-sertifikatet er i orden: hvorfor IKEv2 PEAP-innlogging fortsatt feiler

Sertifikatet til VPN-gatewayen din er gyldig, kjeden valideres, og IKEv2-klienten avviser fortsatt innloggingen med en melding om et sertifikats gyldighetsintervall. Den første impulsen er å utstede gateway-sertifikatet på nytt eller bytte EAP-metode, og begge er vanligvis feil. Innloggingsforsøket bærer to separate serveridentiteter: gateway-sertifikatet som IKE bruker, og sertifikatet som presenteres av det som avslutter PEAP. Den ene er i orden, og den andre er grunnen til at klienten stoppet.

To identiteter, ett innloggingsforsøk

Sertifikatet i VPN-profilen hører til IKE-utvekslingen: det beviser at gatewayen er parten profilen navngir, under den konfigurerte IKE-policyen. Sertifikatet som feiler her, hører til en annen samtale, TLS-økten som PEAP åpner med det som autentiserer brukeren, som ofte er en RADIUS-server som NPS og ikke gatewayen selv. En tredje kontroll, brukerens påloggingsinformasjon, skjer inne i den økten. Et gyldig passord kan ikke reparere et utløpt server sertifikat, og et gyldig gateway-sertifikat kan ikke gå god for PEAP-endepunktet.

Denne lagdelingen forklarer hvorfor en sertifikatfeil dukker opp på et sted der det eneste sertifikatet noen konfigurerte, var gatewayens. Den forklarer også hvorfor ny utstedelse av det sertifikatet ikke endrer noe.

Les logglinjen mot stadiet

Finn meldingen som navngir årsaken og datoene. En klage på gyldighetsintervallet ved siden av en subjektfeil betyr at serveren avviste sertifikatet den fikk, ikke at brukeren avviste innloggingen. Finn deretter stadiet: en strongSwan charon-logg viser IKE_SA .* established før EAP-utvekslingen begynner, så en sertifikatfeil etter den linjen hører til EAP-identiteten, mens en feil før den peker på gatewayen. Stadieteksten i et Windows-klients tilkoblingspanel sier det samme.

Sjekk klokken til klienten før du berører noe sertifikat. En enhet som går timer feil, gir samme gyldighetsfeil som et virkelig utløpt sertifikat. Å stille klokken er en rettelse på fem sekunder, og å bytte ut et sertifikat som aldri var problemet, er et avbrudd.

Finn ut hvilket endepunkt som avslutter PEAP

I et design med gateway pluss RADIUS videresender gatewayen EAP og avslutter det ikke. strongSwans eap-radius-plugin gir utvekslingen til RADIUS-serveren, som eier PEAP TLS-økten og sertifikatet dens. Korreler ett mislykket forsøk på tvers av begge loggene og bekreft hvilken prosess som faktisk valgte et sertifikat for den økten.

For NPS må sertifikatet ligge i det lokale datamaskinlageret, ha formålet serverautentisering, samsvare med navnet klientene forventer, og være lesbart for tjenestekontoen. Microsofts sertifikatkrav for NPS lister opp disse betingelsene. Andre EAP-servere har egne utvalgsregler, så ikke kopier NPS-spesifikke ting til en FreeRADIUS-installasjon eller omvendt. Regelen som holder i begge tilfeller, er at endepunktet som avslutter PEAP, eier sertifikatet du er i ferd med å endre.

Bytt ut sertifikatet der EAP avsluttes

Forny eller bytt ut sertifikatet på endepunktet som avslutter PEAP, gjennom den støttede prosessen, og behold formålet serverautentisering og det forventede navnet. Installer hele kjeden der tjenesten leter etter den, og gi tjenesten tilgang til den private nøkkelen. Start tjenesten på nytt eller bind den på nytt, fordi mange tjenester beholder det gamle sertifikatet i minnet og fortsetter å presentere det. En fil som er kopiert til maskinen, beviser ingenting om hvilket sertifikat tjenesten faktisk presenterer.

Bekreft endringen ved å korrelere neste forsøk med tjenestens egen logg, eller ved å inspisere sertifikatet økten presenterte. Hvis den loggen fortsatt viser det gamle fingeravtrykket, virket ikke omstarten.

Ikke anta at den nyeste filen i en mappe er den som brukes. En kopi med riktig navn og feil tillatelser endrer ingenting. Vurder endringen etter den presenterte identiteten, ikke etter et filstempel.

Hva du ikke bør gjøre

Ikke slå av PEAP-validering og ikke tving gjennom en svakere indre metode for å komme forbi feilen. Det endrer policyen og fjerner serverautentiseringsegenskapen som fanget det utløpte sertifikatet i utgangspunktet. Du ville bytte en fungerende kontroll mot en fungerende tilkobling, og det neste utløpte sertifikatet ville komme uten noe som varslet om det.

Ikke betrakt en vellykket tilkobling fra et annet operativsystem som bevis for at sertifikatet er akseptabelt. Den klienten bruker kanskje en annen EAP-metode, et annet tillitslager eller ingen servervalidering i det hele tatt, så suksessen sier ingenting om kontrollen som feilet her. Behold én bevisst negativ test, for eksempel et sertifikat med feil navn eller en ubetrodd kjede, som feiler som forventet. Hvis den testen nå består, har du fjernet en kontroll i stedet for å reparere et sertifikat. Skriv ned hvilken identitet som feilet, slik at neste person ikke begynner på nytt med gateway-sertifikatet.