Ein korrektes VPN-Passwort ersetzt kein fehlendes Zertifikat

Die Anmeldedaten stimmen, das Profil lässt sich sauber importieren, und die Verbindung scheitert dennoch, bevor die Authentifizierung abgeschlossen ist. Unter Windows lautet die Meldung möglicherweise Fehler 798, zu einem Zertifikat, das für die EAP-Methode nicht gefunden wurde. Bei OpenVPN zeigt das Client-Log einen TLS-Handshake, der den Server nie zufriedenstellt. Beide beschreiben dasselbe fehlende Objekt: ein Client-Zertifikat, das der Client vorlegen sollte.

Ein Passwort beweist die Kenntnis eines Geheimnisses; ein Zertifikat beweist den Besitz eines Schlüssels, und das eine ersetzt das andere nicht.

Das Passwort war nie das Problem

Fehler 798 ist ein fehlgeschlagener Zertifikatabruf. Der Client wurde nach einem Zertifikat gefragt, das zur konfigurierten Authentifizierungsmethode passt, durchsuchte seinen Speicher und fand nichts Brauchbares. Das kann bedeuten, dass das Zertifikat fehlt, ohne privaten Schlüssel vorliegt, abgelaufen ist oder an einem Ort gespeichert ist, den der Abruf nicht erreicht. Ein erneuter Versuch des Passworts kann keine dieser Bedingungen ändern, deshalb kehrt der Fehler auch bei korrekten Anmeldedaten zurück.

Lesen Sie die Meldung, bevor Sie danach handeln. Eine Ablehnung der Anmeldedaten, ein fehlgeschlagener Zertifikatabruf und ein fehlgeschlagener TLS-Handshake sind drei verschiedene Befunde, und nur einer davon betrifft das Passwort.

Was der Client-Speicher enthalten muss

Zwei Objekte sind beteiligt. Das Client-Zertifikat muss für den Benutzer installiert sein, der den VPN-Client ausführt, zusammen mit seinem privaten Schlüssel, und die ausstellende Wurzel muss vertrauenswürdig sein. Eine .cer-Datei enthält nur das öffentliche Zertifikat, kann also allein nichts authentifizieren. Im Windows-Zertifikatmanager gehört die Client-Identität in den persönlichen Speicher des aktuellen Benutzers und die Wurzel in den Speicher der vertrauenswürdigen Stammzertifikate.

Die Installation der Identität im Computerspeicher oder nur im Stammzertifikatsspeicher erfüllt keinen Abruf, der auf den persönlichen Speicher des Benutzers zielt. Prüfen Sie Speicher, Kennzeichen für den privaten Schlüssel und Gültigkeitsdaten gemeinsam, und starten Sie dann den Client neu, damit er den Speicher erneut liest.

Zwei Produkte, dieselbe fehlende Anmeldedatei

OpenVPN-Server verlangen standardmäßig ein Client-Zertifikat. Wer auth-user-pass zum Client hinzufügt, sendet einen Benutzernamen und ein Passwort, und der TLS-Handshake verlangt weiterhin ein Zertifikat, sodass ein Passwort allein die Verbindung unter verify-client-cert require nicht herstellen kann. Der Server lässt sich so einstellen, dass er keines verlangt, was das Passwort zur einzigen Client-Anmeldedatei macht und eine echte Schwächung darstellt. Ein Shell-Skript hinter auth-user-pass-verify kann Anmeldedaten prüfen, und es verlangt aktivierte Skriptausführung, was es zu einem riskanteren Entwurf macht als ein ordentliches Authentifizierungs-Backend.

Ein reines Passwortprofil hängt außerdem von gepushten Optionen ab, die wiederum davon abhängen, dass der Pull-Mechanismus aktiviert ist.

Beheben Sie ein fehlendes Zertifikat nicht durch Abschalten der Prüfungen

Die Versuchung ist, die Überprüfung zu lockern, damit die Meldung verschwindet. Das entfernt die Kontrolle, die ihre Aufgabe erfüllte, und hinterlässt eine Verbindung, die nicht mehr beweist, was sie behauptet. Wenn das Gateway kürzlich seine Wurzel gewechselt hat, laden Sie das Client-Paket erneut herunter, statt das Profil zu bearbeiten, denn das alte Paket kann noch die bisherige Wurzel enthalten. Fehlt die Option zur Zertifikatsauthentifizierung im Profil-Editor, zeigt die installierte Windows-Version diese Methode möglicherweise nicht; aktualisieren Sie das System, statt XML von Hand zu bearbeiten.

Halten Sie fest, welcher Speicher das Zertifikat enthielt, welcher Benutzer den Client ausführte und ob der private Schlüssel vorhanden war. Diese drei erklären nahezu jeden Fall dieses Fehlers.

Das Passwort war in Ordnung. Die Anmeldedatei, die die Methode tatsächlich brauchte, lag woanders.