SECLEVEL=0 behebt das Symptom, nicht das Zertifikat

Eine OpenVPN-Verbindung schlägt fehl, jemand findet einen Einzeiler, der SECLEVEL=0 hinzufügt, und der Tunnel steht. Geändert hat sich weder das Zertifikat noch die Cipher Suite; verschoben hat sich eine bibliotheksweite Akzeptanzschwelle, und alles, was der Prozess danach tut, erbt die neue Grenze. Das lohnt sich zu verstehen, bevor dieselbe Zeile in jedes Profil des Bestands kopiert wird.

Feststellen, welche Bibliothek und welche Richtlinie gelten

SECLEVEL ist ein OpenSSL-Konzept, also ist die erste Frage, ob dein Build überhaupt OpenSSL verwendet. OpenVPN kann gegen mehr als eine Kryptobibliothek gelinkt werden, und eine Einstellung, die für eine davon gilt, ist für die anderen bedeutungslos. Frage die Binärdatei, womit sie gebaut wurde, und frage dann die Bibliothek, welche Version und Konfiguration sie geladen hat:

openvpn --version | head -3
openssl version -a

Lies die Versionsausgabe sorgfältig, denn Distributionen patchen Vorgaben. Manche liefern eine Systemkonfiguration aus, die die Mindeststufe über die Vorgabe von Upstream hebt, weshalb dasselbe Profil auf zwei Rechnern mit identischen OpenVPN-Paketen unterschiedlich reagiert. Die wirksame Richtlinie ist die, die der laufende Prozess geladen hat, nicht die aus dem Handbuch von Upstream.

Dann trenne die zwei Ebenen, die Leute vermischen. OpenVPN hat eigene TLS-Steuerungen, darunter eine Einstellung für das Zertifikatsprofil und explizite Cipher-Listen, und diese stehen über allem, was die Bibliothek erzwingt. Das Senken der Bibliotheksstufe ändert nicht, welche Cipher deine OpenVPN-Konfiguration auflistet, und das Verengen der OpenVPN-Liste hebt die Schwelle der Bibliothek nicht an. Zu wissen, welche Ebene dich abgewiesen hat, ist der Grund, warum die Lösung keine Vermutung bleibt.

Die drei Dinge trennen, die abgelehnt werden können

Der erste Kandidat ist Identitätsmaterial: ein Zertifikat, dessen Schlüssel zu klein ist oder dessen Signaturalgorithmus die Richtlinie nicht mehr akzeptiert. Der zweite ist ein Schlüsselaustauschparameter, etwa eine Gruppe, die die Richtlinie als zu schwach ansieht. Der dritte ist eine Cipher Suite, die die Richtlinie ausschließt. Alle drei können einen Handshake-Fehler erzeugen, und nur der Fehlertext und die Aushandlungsphase unterscheiden sie.

Keines dieser drei ist die Cipher des Datenkanals. OpenVPN handelt seine Tunnelverschlüsselung getrennt vom TLS-Handshake aus, daher sagt eine Verbindung, die nach einer Änderung der Sicherheitsstufe gelingt, nichts darüber aus, welche Cipher deine Nutzdaten schützt. Wenn die Frage, die du eigentlich stellst, die Vertraulichkeit der Daten betrifft, schaust du auf den völlig falschen Regler.

Das Senken der Stufe erweitert die Akzeptanz für alle drei Eingaben gleichzeitig. Das ist der Punkt, den Leute übersehen: Die Lösung, die ein altes Zertifikat zulässt, lässt auch eine schwache Gruppe und eine Suite zu, die du vielleicht nicht erlauben wolltest. Ein einzelner Fehler gab den Anlass zur Änderung, und die Änderung ist breiter als der Fehler. Diese Asymmetrie ist der Grund, warum eine eng gefasste Ausnahme besser ist als eine Vorgabe für den ganzen Bestand.

Die Eingabe ändern, nicht die Schwelle

Halte den genauen Fehler fest, bevor du die Konfiguration anfasst, einschließlich der Phase, die ihn gemeldet hat, und des Objekts, das er nannte. Ein Zertifikatsproblem löst man, indem man das Zertifikat durch etwas ersetzt, das die aktuelle Richtlinie akzeptiert, was meistens bedeutet, es bei der Zertifizierungsstelle neu auszustellen, statt dieselbe Datei neu zu installieren.

Wenn die abgelehnte Eingabe zu einem Peer gehört, den du nicht kontrollierst, geht es im Gespräch mit dessen Eigentümer um unterstütztes Ersatzmaterial. Deine eigene Schwelle zu senken, um ein System unterzubringen, das niemand wartet, verlagert die Kosten von ihm auf alle, die sich danach verbinden.

Wo der Server die Richtlinie durchsetzt, prüfe, ob eine Einstellung auf OpenVPN-Ebene die eigentliche Ursache ist, bevor du die Bibliothek beschuldigst. Ein Zertifikatsprofil, das eine strengere Klasse verlangt, als das eingesetzte Zertifikat erfüllen kann, schlägt fehl, egal worauf die Sicherheitsstufe gesetzt ist, und dieses Profil zu entfernen ist eine engere Änderung als das Abschalten der Bibliotheksprüfungen.

Wenn du sie senken musst, begrenze sie und dokumentiere sie

Manchmal ist eine genehmigte Kompatibilitätsausnahme die richtige Antwort, besonders für einen Alt-Peer mit einem datierten Abkündigungsplan. Begrenze sie auf den Dienst, der sie braucht, statt auf den ganzen Host: eine dienstspezifische Konfigurationsdatei oder eine eigene OpenSSL-Konfiguration hat einen kleineren Wirkungsradius als ein Export im globalen Profil.

Schreibe vier Dinge zur Ausnahme auf: die genaue Einstellung, den Eigentümer, der sie genehmigt hat, die betroffenen Clients und die Bedingung, unter der sie entfernt wird. Eine Ausnahme ohne Abkündigungsbedingung ist eine dauerhafte Schwächung mit einer befristeten Begründung.

Der Rollback sollte ein einziger Schritt sein, den du bereits getestet hast. Behalte die vorherige Konfiguration, wende die Änderung an, bestätige, dass der Dienst startet, und wisse genau, welche Datei du wiederherstellen musst, wenn sich die nächste Verbindung anders verhält als erwartet.

Identität und Schutz danach überprüfen

Eine erfolgreiche Verbindung beweist nur, dass die geänderten Bedingungen sie zugelassen haben. Bestätige, dass Hostnamen- und Peer-Prüfung noch ihre Arbeit tun, dass das verwendete Zertifikat das ist, das du einsetzen wolltest, und dass der ausgehandelte Datenkanal zur Richtlinie passt, die du zu haben glaubst.

openssl x509 -in /etc/openvpn/client.crt -noout -subject -dates -text | grep -E 'Signature Algorithm|Public-Key'
openvpn --show-tls | head -20

Die Referenz zu den Sicherheitsstufen von OpenSSL sagt ausdrücklich, dass das Framework Grenzen für Schlüssel, Signaturen, Gruppen und Suiten gemeinsam anwendet und dass Stufe null alles erlaubt, was der Callback prüft. Das ist der Umfang dessen, was du geändert hast, und es ist der Satz, den man zitiert, wenn jemand fragt, ob die Lösung eng war.

Die Übergabe, die ein Audit übersteht, sagt, welche Richtlinie welche Eingabe abgelehnt hat, was geändert wurde und was infolgedessen weiter akzeptiert wird. „Es funktioniert mit SECLEVEL=0“ ist eine Beobachtung zu einer Verbindung, keine Sicherheitsbewertung des Deployments.