OpenVPN ohne Client-Zertifikat: Serverrichtlinie, nicht Profil

Sie löschen die Zertifikat- und Schlüsselzeilen, geben das Profil weiter, und die Verbindung scheitert weiterhin mit einem Zertifikatsfehler. Das Profil war nie das, was diese Anforderung durchsetzte. Der Server entscheidet, ob ein Client-Zertifikat Pflicht ist, und keine Änderung auf der Clientseite verhandelt das weg. Die Lösung ist also eine Änderung der Serverrichtlinie, bewusst vorgenommen, wobei alles, was davon abhängt, im selben Durchgang aktualisiert wird.

Das Profil ist nicht die Richtlinie

Community OpenVPN 2.6 wird mit verpflichtenden Client-Zertifikaten ausgeliefert, weil verify-client-cert standardmäßig require ist. Die Einstellung auf none beendet die Forderung nach einem Zertifikat und übergibt die Client-Authentifizierung an die Benutzername-und-Passwort-Regelung, die der Server ohnehin betreibt. Ältere Anleitungen greifen zu client-cert-not-required, der alten Schreibweise derselben Idee, also verwenden Sie die Direktive, die Ihre installierte Version dokumentiert. In jedem Fall geschieht die Änderung auf dem Server, und kein Client-Profil kann sie vornehmen.

Das folgende Fragment ist die gesamte serverseitige Änderung und für sich genommen keine funktionierende Authentifizierungskonfiguration. verify-client-cert none entfernt die Zertifikatsanforderung, während username-as-common-name den Kontonamen zu der Identität macht, die spätere Callbacks und Dateien pro Client sehen. Keine der beiden Zeilen prüft ein Passwort, also muss weiterhin ein Verifier existieren.

verify-client-cert none
username-as-common-name

Dieser Verifier ist ein Plugin oder ein Skript, das von auth-user-pass-verify gesteuert wird, und er muss vorhanden sein, bevor eine der Zeilen oben irgendetwas bedeutet. Die umgekehrte Reihenfolge schafft ein Fenster, in dem der Server kein Zertifikat verlangt und kein Konto prüft.

Was den Server weiterhin verifiziert

Das Weglassen des Client-Zertifikats bedeutet nicht, TLS wegzulassen. Der Server behält sein Zertifikat und seinen Schlüssel, und der Client behält das CA-Vertrauen und die Hostnamenprüfungen, die ihn davon abhalten, mit einem Betrüger zu sprechen. remote-cert-tls server oder das CA-Bündel zu entfernen, weil der Client kein Zertifikat mehr hat, ist ein verbreitetes und schwerwiegendes Missverständnis, und die 2.6-Referenz stellt ausdrücklich klar, dass die beiden Richtungen unabhängig sind. Die eine weist den Server gegenüber dem Client aus; die andere weist den Client gegenüber dem Server aus.

Ein Profil kann auch einen tls-auth- oder tls-crypt-Block enthalten. Das ist ein gemeinsam genutzter Steuerkanalschlüssel mit eigenem Verteilungs- und Rotationszyklus, also ist eine Datei ohne Zertifikat- oder Schlüsselzeilen nicht automatisch sicher zu veröffentlichen. Behandeln Sie sie als Geheimnis, bis Sie sie gelesen haben.

Eine Zertifikatsdatei, die aus einem funktionierenden Profil kopiert wurde, beweist für sich genommen nichts; Besitz bedeutet, den passenden privaten Schlüssel zu halten, was eine zertifikatsauthentifizierte Bereitstellung prüft. Eine Datei, die ein Zertifikat enthält, ist keine Datei, mit der man sich authentifizieren kann.

Was der Verifier leisten muss

Mit entfernter Zertifikatsanforderung ruht alles auf dem Verifier: einem Plugin oder einem Skript, das von auth-user-pass-verify gesteuert wird. Er muss ungültige Anmeldedaten ablehnen, deaktivierte oder ungeeignete Konten ablehnen und geschlossen fehlschlagen, wenn er sein Backend nicht erreicht. username-as-common-name wird oft daneben aktiviert und ändert die Identität, die spätere Callbacks und Konfigurationsdateien pro Client sehen. Es prüft kein Passwort und macht ein ungeeignetes Konto nicht geeignet. Das sind getrennte Aufgaben, und sie zu vermischen ist der Weg, auf dem eine Migration ihren Happy-Path-Test besteht und bei ihrem ersten echten Vorfall scheitert.

Testen Sie die negativen Fälle ebenso sorgfältig wie den positiven. Ein Profil, das eine Passwortabfrage zeigt, beweist nur, dass der Client eine Abfrage zeichnen kann, während ein Server, der das falsche Passwort akzeptiert, etwas deutlich Schlimmeres beweist. Fügen Sie dem Testsatz ein deaktiviertes Konto und einen abgelaufenen Anmeldedatensatz hinzu, nicht nur ein schlechtes Passwort.

Ändern Sie Richtlinie, Profil und Zuordnung gemeinsam

Koordinieren Sie drei Dinge: die Serverdirektive, das Client-Profil und die Identitätszuordnung pro Client. Ändern Sie sie getrennt, und Clients scheitern vor der Verifikation oder verbinden sich unter einem Namen, den der Administrator nicht erwartet hat, was schlimmer ist, weil es wie Erfolg aussieht. Eine Verbindung, die unter der falschen Identität gelingt, ist schwerer zu bemerken als eine, die scheitert.

Halten Sie zwei Testkonten für diesen Pfad bereit, ein gültiges und ein bekannt schlechtes, und verwenden Sie beide nach jeder Änderung am Verifier. Das gültige Konto beweist den Happy Path und die Identitätszuordnung; das schlechte beweist, dass die Ablehnung noch funktioniert. Keiner der Tests sagt etwas über Eignungsregeln aus, also fügen Sie ein Konto hinzu, das aus Richtliniengründen abgelehnt werden sollte, falls die Bereitstellung solche Regeln hat. Führen Sie alle drei nach jeder Änderung aus, denn ein Verifier, der anfängt, alles zu akzeptieren, sieht genau wie ein funktionierender Login aus.

Halten Sie fest, welche Authentifizierungsmethoden der Server tatsächlich akzeptiert, nicht welche das Profil nahelegt. Dieser Eintrag beantwortet die Frage, die Leute immer wieder stellen, nämlich wer sich mit diesem Dienst verbinden kann. Er überlebt auch den nächsten Administrator, der ihn sonst aus einem Paketmitschnitt wiederentdecken würde.