Das Gateway-Zertifikat ist in Ordnung: Warum die IKEv2-PEAP-Anmeldung trotzdem scheitert

Das Zertifikat Ihres VPN-Gateways ist gültig, die Kette wird validiert, und der IKEv2-Client verweigert die Anmeldung trotzdem mit einer Meldung über ein Gültigkeitsintervall eines Zertifikats. Der erste Impuls ist, das Gateway-Zertifikat neu auszustellen oder die EAP-Methode zu wechseln, und beides ist meist falsch. Der Anmeldeversuch trägt zwei getrennte Serveridentitäten: das Gateway-Zertifikat, das IKE verwendet, und das Zertifikat, das von dem präsentiert wird, was PEAP beendet. Eine davon ist in Ordnung, und die andere ist der Grund, warum der Client aufgehört hat.

Zwei Identitäten, ein Anmeldeversuch

Das Zertifikat im VPN-Profil gehört zum IKE-Austausch: Es beweist, dass das Gateway der in dem Profil genannte Peer ist, unter der konfigurierten IKE-Richtlinie. Das Zertifikat, das hier scheitert, gehört zu einem anderen Gespräch, der TLS-Sitzung, die PEAP mit demjenigen öffnet, der den Benutzer authentifiziert; das ist oft ein RADIUS-Server wie NPS und nicht das Gateway selbst. Eine dritte Prüfung, die Benutzeranmeldeinformation, findet innerhalb dieser Sitzung statt. Ein gültiges Kennwort kann ein abgelaufenes Serverzertifikat nicht reparieren, und ein gültiges Gateway-Zertifikat kann nicht für den PEAP-Endpunkt bürgen.

Diese Schichtung erklärt, warum ein Zertifikatfehler an einer Stelle auftaucht, an der das einzige konfigurierte Zertifikat das des Gateways war. Sie erklärt auch, warum eine Neuausstellung dieses Zertifikats nichts ändert.

Lesen Sie die Logzeile gegen die Phase

Suchen Sie die Meldung, die den Grund und die Daten nennt. Eine Beschwerde über das Gültigkeitsintervall neben einem Subjektfehler bedeutet, dass der Server das ihm vorgelegte Zertifikat abgelehnt hat, nicht dass der Benutzer die Anmeldung abgelehnt hat. Dann bestimmen Sie die Phase: Ein strongSwan-Charon-Log zeigt IKE_SA .* established, bevor der EAP-Austausch beginnt, also gehört ein Zertifikatfehler nach dieser Zeile zur EAP-Identität, während ein Fehler davor auf das Gateway weist. Der Phasentext im Verbindungsfenster eines Windows-Clients sagt dasselbe.

Prüfen Sie die Uhr des Clients, bevor Sie irgendein Zertifikat anfassen. Ein Gerät, das Stunden danebenliegt, erzeugt denselben Gültigkeitsfehler wie ein wirklich abgelaufenes Zertifikat. Das Uhrstellen ist eine Fünf-Sekunden-Korrektur, und ein Zertifikat zu ersetzen, das nie das Problem war, ist ein Ausfall.

Finden Sie heraus, welcher Endpunkt PEAP beendet

In einem Aufbau mit Gateway und RADIUS leitet das Gateway EAP weiter und beendet es nicht. Das eap-radius-Plugin von strongSwan übergibt den Austausch an den RADIUS-Server, der die PEAP-TLS-Sitzung und ihr Zertifikat besitzt. Korrelieren Sie einen fehlgeschlagenen Versuch über beide Logs und bestätigen Sie, welcher Prozess tatsächlich ein Zertifikat für diese Sitzung ausgewählt hat.

Für NPS muss das Zertifikat im Speicher des lokalen Computers liegen, den Zweck Serverauthentifizierung tragen, dem Namen entsprechen, den Clients erwarten, und für das Dienstkonto lesbar sein. Die Microsoft-Zertifikatanforderungen für NPS listen diese Bedingungen auf. Andere EAP-Server haben ihre eigenen Auswahlregeln, also kopieren Sie NPS-Besonderheiten nicht in eine FreeRADIUS-Installation oder umgekehrt. Die Regel, die in beiden Fällen gilt, lautet: Der Endpunkt, der PEAP beendet, besitzt das Zertifikat, das Sie ändern wollen.

Ersetzen Sie das Zertifikat dort, wo EAP endet

Erneuern oder ersetzen Sie das Zertifikat auf dem Endpunkt, der PEAP beendet, über den unterstützten Prozess und behalten Sie den Zweck Serverauthentifizierung und den erwarteten Namen bei. Installieren Sie die vollständige Kette dort, wo der Dienst sie sucht, und gewähren Sie dem Dienst Zugriff auf den privaten Schlüssel. Starten Sie den Dienst neu oder binden Sie ihn neu, denn viele Dienste behalten das alte Zertifikat im Speicher und präsentieren es weiterhin. Eine auf den Rechner kopierte Datei beweist nichts darüber, welches Zertifikat der Dienst tatsächlich präsentiert.

Bestätigen Sie die Änderung, indem Sie den nächsten Versuch mit dem eigenen Log des Dienstes korrelieren oder das von der Sitzung präsentierte Zertifikat prüfen. Zeigt dieses Log noch den alten Fingerabdruck, hat der Neustart nicht gegriffen.

Gehen Sie nicht davon aus, dass die neueste Datei in einem Verzeichnis die verwendete ist. Eine Kopie mit dem richtigen Namen und den falschen Berechtigungen ändert nichts. Beurteilen Sie die Änderung an der präsentierten Identität, nicht an einem Dateizeitstempel.

Was Sie nicht tun sollten

Deaktivieren Sie nicht die PEAP-Validierung und erzwingen Sie keine schwächere innere Methode, um an dem Fehler vorbeizukommen. Das ändert die Richtlinie und entfernt die Serverauthentifizierungseigenschaft, die das abgelaufene Zertifikat überhaupt erst erwischt hat. Sie würden eine funktionierende Prüfung gegen eine funktionierende Verbindung tauschen, und das nächste abgelaufene Zertifikat käme ohne alles, was es ankündigen würde.

Betrachten Sie eine erfolgreiche Verbindung eines anderen Betriebssystems nicht als Beweis dafür, dass das Zertifikat akzeptabel ist. Dieser Client verwendet möglicherweise eine andere EAP-Methode, einen anderen Vertrauensspeicher oder gar keine Servervalidierung, sodass sein Erfolg nichts über die hier gescheiterte Prüfung aussagt. Behalten Sie einen bewussten Negativtest bei, etwa ein Zertifikat mit falschem Namen oder eine nicht vertrauenswürdige Kette, der wie erwartet scheitert. Besteht dieser Test jetzt, haben Sie eine Prüfung entfernt statt ein Zertifikat repariert. Notieren Sie, welche Identität gescheitert ist, damit die nächste Person nicht wieder mit dem Gateway-Zertifikat beginnt.