ca md too weak: Zertifikat neu ausstellen oder Stufe senken?

Ein OpenVPN-Client, der letzten Monat noch lief, scheitert jetzt beim Start mit ca md too weak, und das Profil auf der Platte ist Byte für Byte dasselbe, das funktionierte. Die Meldung betrifft die Signatur auf dem Zertifikat einer Zertifizierungsstelle, nicht die Datenverschlüsselung, den auth-Digest oder das Kontopasswort. Drei Bedingungen entscheiden, ob die Lösung neues Identitätsmaterial, eine neue Kette oder eine bewusste Richtlinienänderung ist. Arbeiten Sie sie der Reihe nach ab, und Sie vermeiden das übliche Ergebnis, bei dem der Tunnel zurückkommt, indem jede TLS-Verbindung auf dem Host geschwächt wird.

Was der Fehler tatsächlich benennt

OpenSSL wirft diesen Prüffehler beim Aufbau einer Kette, wenn das als CA handelnde Zertifikat einen Signatur-Digest trägt, den die Sicherheitsstufe der Bibliothek nicht mehr akzeptiert. MD5 wird auf der Standardstufe abgelehnt, SHA-1 wird abgelehnt, sobald die Stufe angehoben wird. Der Digest des Endzertifikats wiegt hier weniger als der Digest des Ausstellers, der es signiert. Dieselbe Richtlinie kann eine Root ablehnen, die am Tag ihrer Ausstellung völlig gewöhnlich war.

Deshalb bewirkt das Bearbeiten von auth oder data-ciphers nichts für diesen Fehler. Diese Einstellungen regeln, wie Pakete nach dem Handshake geschützt werden, während das abgelehnte Objekt ein Identitätsdokument ist, das geprüft wird, bevor ein Tunnel existiert. Ein Zertifikat kann bequem innerhalb seines Gültigkeitsfensters liegen und dennoch eine Signatur tragen, die die Bibliothek nicht akzeptiert.

Halten Sie die Prüfungen im Kopf getrennt, und der Fehler wirkt nicht mehr rätselhaft. Gültigkeitsdaten, Schlüsselverwendung und Signatur-Digest sind unabhängige Tests, und genau einer davon ist gerade gescheitert.

Bedingung eins: Ist das abgelehnte Objekt die Root?

Drucken Sie jedes Zertifikat im Profil aus und lesen Sie die Felder subject und issuer. Eine selbstsignierte Root zeigt in beiden denselben Wert, und ihr Signaturalgorithmus ist der, auf dem die ganze Kette ruht. Sitzt der schwache Digest dort, erbt jedes Blatt darunter das Problem. Notieren Sie den Algorithmus neben dem subject, damit der spätere Vergleich mechanisch statt aus dem Gedächtnis erfolgt.

Gebündelte CA-Dateien enthalten oft mehrere Blöcke, also identifizieren Sie den Block, der tatsächlich geladen wird, statt anzunehmen, der erste sei schuld. Der Befehl openssl x509 -in ca.pem -noout -subject -issuer -text beschreibt jeweils ein Zertifikat, was bedeutet, das Bündel zuerst zu teilen, wenn es mehr enthält. Vergleichen Sie den ausgegebenen Signaturalgorithmus mit dem Digest, den Sie aus der Entstehungszeit der Root erwarten würden.

Ein mit SHA-256 signiertes Blatt unter einer schwachen Root scheitert weiterhin, weil die Kettenprüfung bis ganz nach oben läuft. Diese Reihenfolge ist es, die die nächste Bedingung wichtig macht.

Bedingung zwei: Kontrollieren Sie den Aussteller?

Gehört die Root Ihrer Organisation, ist die dauerhafte Lösung eine neue Root mit modernem Digest plus neu ausgestellte Blätter, geliefert als eine Profilaktualisierung. Das kostet ein Wartungsfenster und einen Plan für Geräte, die das Update nicht am selben Tag bekommen können.

Hat ein Dritter die Kette ausgestellt, ist die Lösung eine Anfrage an diesen Betreiber, und die einzige nützliche lokale Aktion ist, sich nicht mehr auf das alte Material zu verlassen. Den PEM-Text zu bearbeiten oder die Datei neu zu speichern ändert nichts, was die Signatur abdeckt.

Ein Zwischenfall verdient einen Namen: eine interne Root, die älter ist als die aktuellen Vorgaben, aber noch Material signiert, dem andere Systeme vertrauen. Sie zu ersetzen heißt, jeden Konsumenten zu prüfen, einschließlich Geräten, die das alte Zertifikat per Fingerabdruck pinnen. Zählen Sie diese Konsumenten, bevor Sie die Änderung planen, denn ein Root-Tausch, der einen übersieht, tauscht einen Startfehler gegen einen Ausfall.

Bedingung drei: Was das Absenken der Stufe sonst noch akzeptiert

Die Sicherheitsstufe zu senken oder OpenVPNs Legacy-Zertifikatsprofil zu wählen, lässt den Client den alten Digest wieder akzeptieren. Es lockert auch andere Prüfungen derselben Bibliothek, für jede Verbindung, die dieser Prozess aufbaut.

In einem Labor mag das vertretbar sein, oder als kurze Brücke, während Ersatzmaterial vorbereitet wird, solange die Ausnahme auf ein Profil begrenzt ist und ein Enddatum trägt. Als dauerhafte Einstellung auf einem gemeinsam genutzten Host erweitert sie leise, was jeder TLS-Client dort vertrauen wird.

Schreiben Sie die Ausnahme mit Verantwortlichem und Rückbauschritt auf. Eine undokumentierte Stufenänderung ist nach einem halben Jahr nicht von einem Fehler zu unterscheiden, und der nächste Ingenieur wird nicht wissen, dass es je eine Entscheidung war.

Die Entscheidung, als Regel formuliert

Ersetzen Sie die Kette, wenn Sie den Aussteller kontrollieren und seine Konsumenten aufzählen können. Eskalieren Sie zum Aussteller, wenn nicht. Senken Sie die Stufe nur als datierte, begrenzte Ausnahme mit bereits geplanter Ersetzung. Alles andere lässt dasselbe Zertifikat stehen und verschiebt das Risiko an einen weniger sichtbaren Ort.

Testen Sie das Profil dann von einem sauberen Client erneut, bestätigen Sie, dass der Handshake durchläuft, und bewahren Sie den genauen Ablehnungstext auf, falls es weiter scheitert. Eine präzise Fehlermeldung ist das Billigste, was Sie demjenigen geben können, der die nächste Schicht besitzt.