Kann ein RSA-Zertifikat mit dh none in OpenVPN funktionieren?

Hier ist eine Serverkonfiguration, die dh none neben einem Zertifikat nennt, das RSA sagt, dazu der nagende Verdacht, dass eines davon falsch sein muss. Nichts ist falsch. Das Zertifikat signiert und authentifiziert; der Schlüsselaustausch stellt ein gemeinsames Geheimnis her. Das sind zwei verschiedene Aufgaben im selben Handshake, und TLS erlaubt einem RSA-Zertifikat, einen Handshake zu authentifizieren, der ephemere Elliptische-Kurven-Vereinbarung nutzt.

Die Verwirrung kommt meist mit einer Migrationsanleitung. Sie sagt, die DH-Parameterdatei durch dh none zu ersetzen, der Leser bemerkt, dass das Zertifikat kein Elliptische-Kurven-Zertifikat ist, und die beiden Fakten werden als Widerspruch behandelt.

Warum die beiden Einstellungen zusammenhängen wirken

Die ältere OpenVPN-Konfiguration verlangte eine DH-Parameterdatei, weil Diffie-Hellman im endlichen Körper Domänenparameter benötigt, auf die sich beide Seiten einigen. Die Direktive dh zeigte auf diese Datei. Wenn eine Bereitstellung auf ECDH wechselt, kommen die Parameter stattdessen von einer benannten Kurve, und die Datei wird nicht mehr gebraucht, was dh none ausdrückt.

Zertifikate sind eine eigene Achse. Sie tragen einen öffentlichen Schlüssel und eine Signatur, die die Identität des Servers belegen, und dieser Schlüssel kann RSA oder Elliptische Kurve sein, unabhängig davon, wie der Sitzungsschlüssel vereinbart wird. Ein Handshake, der ECDHE zur Schlüsselvereinbarung und RSA zur Authentifizierung nutzt, ist üblich und weit verbreitet.

Die Benennung verschlimmert die Überschneidung. Elliptische Kurve erscheint sowohl in ECDHE- als auch in ECDSA-Suitennamen, daher liegt die Annahme nahe, dass jede Verbindung, die eine Kurve erwähnt, ein Kurvenzertifikat enthalten muss. Das ist nicht der Fall.

Einen TLS 1.2-Suitennamen richtig lesen

Nehmen Sie ECDHE-RSA-AES256-GCM-SHA384. Das erste Token ist die Schlüsselaustauschfamilie: ephemeres Elliptische-Kurven-Diffie-Hellman. Das zweite ist die Authentifizierungsfamilie: RSA. Der Rest beschreibt den Datensatzschutz und den im Handshake verwendeten Hash.

Eine ECDHE-ECDSA-Suite nutzt dieselbe Schlüsselaustauschfamilie mit einer anderen Authentifizierungsmethode, braucht also ein Elliptische-Kurven-Zertifikat. Eine DHE-RSA-Suite nutzt ephemeres Diffie-Hellman im endlichen Körper mit RSA-Authentifizierung, und diese braucht tatsächlich DH-Parameter.

Lesen Sie einen Suitennamen von links nach rechts und ordnen Sie jeden Teil seiner Aufgabe zu. Sobald die Token getrennt sind, ändert sich die Frage von „passt mein Zertifikat zu dh none“ zu „erlaubt mein Server eine Suite, deren Schlüsselaustausch keine DH-Datei braucht“.

Was dh none tatsächlich deaktiviert

dh none weist den Server an, keine DH-Parameterdatei für den endlichen Körper zu laden. Es deaktiviert weder Authentifizierung noch Zertifikatsprüfung noch TLS selbst. Es verlangt jedoch, dass der ausgehandelte Schlüsselaustausch keine dieser Parameter benötigt, was praktisch eine ECDHE-Suite oder einen TLS 1.3-Handshake bedeutet.

Genau aus dieser Anforderung entsteht der Bruch. Ist die TLS-Chiffrepolitik des Servers auf DHE-Suiten beschränkt oder bietet ein Client nur solche an, hinterlässt das Entfernen der Parameterdatei keine nutzbare Schlüsselaustauschmethode, und der Handshake schlägt fehl. Der Fehler erscheint meist während des Handshakes des Steuerkanals, vor jeder Benutzerauthentifizierung. Lesen Sie die Chiffreliste, bevor Sie der fehlenden Datei die Schuld geben.

Auf der Elliptische-Kurve-Seite wird die Kurve durch die TLS-Konfiguration des Servers gewählt, und OpenVPN bietet in älteren Zweigen eine Option, sie zu wählen. TLS 1.3 behandelt die Gruppenaushandlung innerhalb des Protokolls und konsultiert die DH-Datei überhaupt nicht.

dh none ist für sich genommen keine Sicherheitsabwertung. Die Stärke des Austauschs hängt dann von der Kurve und Suite ab, die tatsächlich ausgehandelt werden, weshalb der nächste Schritt darin besteht, auf die Wahl der Peers zu schauen statt auf die fehlende Datei.

Die Aushandlung vor dem Bearbeiten bestätigen

Erhöhen Sie die Ausführlichkeit von Server und Client und lesen Sie die Steuerkanalzeile, die OpenVPN nach einer Verbindung ausgibt. Sie nennt die TLS-Version und die ausgehandelte Chiffre und meldet den Schlüsseltyp des Peer-Zertifikats. Diese eine Zeile beantwortet die Frage, die die Konfigurationsdatei nur andeutet.

Zeigt sie TLS 1.2 mit einer ECDHE-RSA-Suite und einem RSA-Zertifikat, ist die Kombination genau das, was dh none erwartet, und es gibt nichts zu reparieren. Zeigt sie eine DHE-Suite oder ein Handshake-Scheitern ohne gemeinsame Chiffre, liegt die Lösung in der Chiffrepolitik oder den Fähigkeiten des Clients, nicht im Zertifikat.

Testen Sie den ältesten Client, den Sie unterstützen wollen, denn ein aktueller Client kann TLS 1.3 aushandeln, während ein älterer auf TLS 1.2-Suiten beschränkt ist. Hat der älteste Client keine Überschneidung, erweitern Sie entweder die erlaubten Suiten oder aktualisieren Sie diesen Endpunkt.

Schalten Sie die Zertifikatsprüfung nicht ab, um ein Handshake-Scheitern zu umgehen. Das Scheitern sagt Ihnen, dass sich die Peers nicht auf einen Schlüsselaustausch einigen konnten, und das Abschalten der Prüfung entfernt die Identitätsgarantie, ohne die Vereinbarung zu lösen.

Checkliste: Ist das Zertifikat RSA, ist eine ECDHE-Suite erlaubt, zeigt das Protokoll diese Suite, und handelt auch der älteste unterstützte Client sie aus? Wenn alle vier ja sind, erledigt dh none seine Aufgabe.