remote-cert-tls server: Was die Direktive in einem OpenVPN-Profil prüft

Drei verschiedene Fragen werden von drei verschiedenen Teilen eines OpenVPN-Profils beantwortet, und ihr Zusammenwerfen führt dazu, dass Leute eine Prüfung abschalten, die funktioniert hat. Ist das Zertifikat des Gegenübers von der Stelle signiert, der ich vertraue? Erklärt dieses Zertifikat die TLS-Serverrolle? Ist es genau der Server, den ich erreichen wollte? remote-cert-tls server beantwortet nur die mittlere Frage, und zwar durch Lesen der Erweiterungen im Zertifikat.

Drei Prüfungen, die man im Kopf leicht zusammenwirft

Der Vertrauensanker lebt in der Direktive ca. Die Rollenprüfung gehört zu remote-cert-tls. Die Identitätsprüfung gehört zu verify-x509-name, wenn ein Profil sie verwendet, oder zu welcher Namensprüfung auch immer die Bereitstellung hinzufügt.

Sie decken unterschiedliche Fehler ab:

Ein Profil kann alle drei haben und trotzdem schwach sein, wenn die CA zu breit geteilt wird, was eine Frage der Schlüsselverwaltung und nicht der Direktive ist.

Was die Rollenprüfung liest

Die Direktive ist ein Makro. Sie expandiert zu einer Schlüsselverwendungsanforderung und einer Anforderung für erweiterte Schlüsselverwendung, die die TLS-Webserverrolle nennt, sodass das Zertifikat des Gegenübers diesen Zweck tatsächlich erklären muss. Ein Zertifikat, das für die Client-Authentifizierung ausgestellt wurde, erfüllt das nicht, selbst wenn dieselbe Stelle beide signiert hat.

Das ist wichtig, weil eine geteilte CA in kleinen Bereitstellungen üblich ist. Eine Stelle signiert jeden Client und den Server, und ohne Rollenprüfung könnte jedes dieser Zertifikate die Serverseite des Handshakes abschließen. Die Prüfung macht dieses Szenario nicht unmöglich, aber sie nimmt ihm die triviale Variante.

Die Direktive ist absichtlich asymmetrisch: Clients tragen remote-cert-tls server, und Server tragen remote-cert-tls client. Tauschen Sie sie, und jede Verbindung scheitert mit einem Rollenfehler, der wie ein defektes Zertifikat aussieht.

Ältere Profile verwenden manchmal ns-cert-type für denselben Zweck. Aktuelle Manpages betrachten diese Option als überholt, deshalb lohnt es sich, ein Profil, das sich noch darauf stützt, zu migrieren statt zu debuggen.

Warum das Abschalten wie eine Lösung wirkt

Wenn die Rollenprüfung scheitert, stoppt die Verbindung mit einem Verifizierungsfehler, und der naheliegende Schritt ist, die Zeile zu löschen. Dann kommt die Verbindung hoch, was sich wie Fortschritt anfühlt und tatsächlich der Fehlermodus ist, den die Direktive verhindern soll. Sie akzeptieren jetzt ein Gegenüber, dessen Zertifikat nie für diese Rolle gedacht war.

Lesen Sie stattdessen den Fehler. Er nennt die Prüfung, die fehlgeschlagen ist, und das Zertifikat auf der anderen Seite lässt sich untersuchen, um zu sehen, welche Erweiterungen es wirklich trägt. Zwei Minuten Lesen entscheiden, ob der Fehler in der Ausstellung oder in der Konfiguration liegt. Raten kostet einen Nachmittag und endet meist mit einem geschwächten Profil. Ein erneuertes Serverzertifikat, das seine erweiterte Schlüsselverwendung verloren hat, ist ein echter Fehler in der Erneuerung, kein Grund, den Client zu lockern.

Die Namensprüfung ist eine eigene Direktive

Die Rollenprüfung zu erfüllen heißt, dass das Gegenüber irgendein Server ist, der von Ihrer Stelle signiert wurde. Es sagt nichts darüber, welcher, was zählt, wenn dieselbe CA Zertifikate für mehrere Gateways ausstellt und eines davon kompromittiert oder umgewidmet ist.

verify-x509-name vergleicht den Zertifikatsbetreff mit einem Wert, den Sie konfigurieren, mit Abgleichmodi für einen exakten Betreff, ein Präfix oder ein einzelnes Feld. Verwenden Sie das Feld, das das Gateway tatsächlich identifiziert, und rechnen Sie damit, es bei einer Namensänderung bewusst zu aktualisieren.

Keine der beiden Direktiven ersetzt guten Schlüsselumgang. Wenn die Client-Schlüsseldatei zusammen mit dem Profil herumkopiert wird, ist die Identität des Gegenübers nur so stark wie die Verteilerliste.

Prüfen Sie das Zertifikat, bevor Sie das Profil bearbeiten

Lesen Sie das Zertifikat des Gegenübers und das Client-Log, in dieser Reihenfolge. Das Zertifikat sagt Ihnen, welche Rollen es erklärt; das Log sagt Ihnen, welche Prüfung es abgelehnt hat.

Diese Befehle geben die Nutzungserweiterungen und die Verifizierungszeilen einer ausführlichen Verbindung aus:

openssl x509 -in server.crt -noout -text | grep -A1 -E "Key Usage|Extended Key Usage"
sudo openvpn --config client.ovpn --verb 4 2>&1 | grep -i verify

Wenn die Erweiterungen die Serverrolle zeigen und das Log immer noch einen Rollenfehler meldet, zeigt das Profil wahrscheinlich auf die falsche Zertifikatsdatei statt auf ein schlechtes Zertifikat. Wenn die Erweiterungen nur die Client-Authentifizierung zeigen, hören Sie auf, den Client anzusehen, und beheben Sie die Ausstellung. Stellen Sie in jedem Fall die Prüfung wieder her, bevor Sie die Verbindung für gesund erklären, denn ein erfolgreicher Handshake nach dem Entfernen der Verifizierung beweist weniger als der Fehler, den er ersetzt hat.