Het gateway-certificaat is in orde: waarom IKEv2 PEAP-aanmelding toch mislukt

Het certificaat van uw VPN-gateway is geldig, de keten wordt gevalideerd, en de IKEv2-client weigert de aanmelding toch met een melding over een geldigheidsinterval van een certificaat. De eerste reflex is het gateway-certificaat opnieuw uitgeven of de EAP-methode wijzigen, en beide zijn meestal verkeerd. De aanmeldpoging draagt twee afzonderlijke serveridentiteiten: het gateway-certificaat dat IKE gebruikt, en het certificaat dat wordt gepresenteerd door wat PEAP beëindigt. Een van beide is in orde, en de andere is de reden dat de client stopte.

Twee identiteiten, één aanmeldpoging

Het certificaat in het VPN-profiel hoort bij de IKE-uitwisseling: het bewijst dat de gateway de peer is die het profiel noemt, onder het geconfigureerde IKE-beleid. Het certificaat dat hier faalt, hoort bij een ander gesprek, de TLS-sessie die PEAP opent met wat de gebruiker authenticeert, vaak een RADIUS-server zoals NPS en niet de gateway zelf. Een derde controle, de inloggegevens van de gebruiker, vindt binnen die sessie plaats. Een geldig wachtwoord kan een verlopen servercertificaat niet repareren, en een geldig gateway-certificaat kan niet voor het PEAP-eindpunt instaan.

Deze gelaagdheid verklaart waarom een certificaatfout opduikt op een plek waar het enige geconfigureerde certificaat dat van de gateway was. Ze verklaart ook waarom het opnieuw uitgeven van dat certificaat niets verandert.

Lees de logregel tegen de fase

Zoek het bericht dat de reden en de datums noemt. Een klacht over het geldigheidsinterval naast een subjectfout betekent dat de server het certificaat heeft geweigerd dat hij kreeg, niet dat de gebruiker de aanmelding weigerde. Zoek daarna de fase: een strongSwan charon-log toont IKE_SA .* established voordat de EAP-uitwisseling begint, dus een certificaatfout na die regel hoort bij de EAP-identiteit, terwijl een fout ervoor op de gateway wijst. De fasentekst in het verbindingsvenster van een Windows-client zegt hetzelfde.

Controleer de klok van de client voordat u welk certificaat dan ook aanraakt. Een apparaat dat uren verkeerd staat, geeft dezelfde geldigheidsfout als een echt verlopen certificaat. De klok gelijkzetten is een correctie van vijf seconden, en een certificaat vervangen dat nooit het probleem was, is een storing.

Zoek uit welk eindpunt PEAP beëindigt

In een ontwerp met gateway plus RADIUS stuurt de gateway EAP door en beëindigt het niet. De eap-radius-plugin van strongSwan geeft de uitwisseling aan de RADIUS-server, die de PEAP TLS-sessie en het bijbehorende certificaat bezit. Correleer één mislukte poging over beide logboeken en bevestig welk proces werkelijk een certificaat voor die sessie heeft gekozen.

Voor NPS moet het certificaat in het archief van de lokale computer staan, het doel serververificatie dragen, overeenkomen met de naam die clients verwachten, en leesbaar zijn voor het serviceaccount. De Microsoft-certificaatvereisten voor NPS sommen die voorwaarden op. Andere EAP-servers hebben hun eigen selectieregels, dus kopieer NPS-bijzonderheden niet naar een FreeRADIUS-implementatie of omgekeerd. De regel die in beide gevallen geldt, is dat het eindpunt dat PEAP beëindigt het certificaat bezit dat u gaat wijzigen.

Vervang het certificaat waar EAP eindigt

Vernieuw of vervang het certificaat op het eindpunt dat PEAP beëindigt, via het ondersteunde proces, met behoud van het doel serververificatie en de verwachte naam. Installeer de volledige keten waar de service die zoekt en geef de service toegang tot de persoonlijke sleutel. Herstart of herverbind de service, want veel services houden het oude certificaat in het geheugen en blijven het presenteren. Een bestand dat naar de machine is gekopieerd, bewijst niets over welk certificaat de service werkelijk presenteert.

Bevestig de wijziging door de volgende poging te correleren met het eigen logboek van de service, of door het certificaat te inspecteren dat de sessie presenteerde. Als dat logboek nog de oude vingerafdruk toont, heeft de herstart niet gewerkt.

Ga er niet van uit dat het nieuwste bestand in een map het bestand is dat wordt gebruikt. Een kopie met de juiste naam en de verkeerde machtigingen verandert niets. Beoordeel de wijziging aan de gepresenteerde identiteit, niet aan een bestandstijdstempel.

Wat u niet moet doen

Schakel de PEAP-validatie niet uit en forceer geen zwakkere inwendige methode om de fout te omzeilen. Dat wijzigt het beleid en verwijdert de eigenschap serververificatie die het verlopen certificaat juist heeft opgevangen. U ruilt een werkende controle in voor een werkende verbinding, en het volgende verlopen certificaat zou komen zonder iets dat het aankondigt.

Beschouw een geslaagde verbinding van een ander besturingssysteem niet als bewijs dat het certificaat aanvaardbaar is. Die client gebruikt misschien een andere EAP-methode, een andere vertrouwensopslag of helemaal geen servervalidatie, dus zijn succes zegt niets over de controle die hier faalde. Houd één bewuste negatieve test aan, bijvoorbeeld een certificaat met de verkeerde naam of een niet-vertrouwde keten, die zoals verwacht faalt. Als die test nu slaagt, hebt u een controle verwijderd in plaats van een certificaat gerepareerd. Noteer welke identiteit faalde, zodat de volgende persoon niet weer met het gateway-certificaat begint.