OpenVPN verify-x509-name: subject, name und name-prefix

Lesen Sie zuerst den Typ des Vergleichs und dann den Text: Eine verify-x509-name Direktive kann korrekt aussehen und trotzdem ein Zertifikat annehmen, dem Sie nicht vertrauen wollten. Zwei Zeilen mit identischem erwarteten Text, aber unterschiedlichen Typen sind unterschiedliche Anforderungen. Lesen Sie zuerst den Typ, dann den Text. Behandeln Sie die Direktive als eine weitere Bedingung der Verbindung, nicht als die gesamte Prüfung.

Was die Option tatsächlich zusichert

Die Direktive benennt eine Identität, die das Zertifikat der Gegenstelle tragen muss. Wenn der Vergleich scheitert, OpenVPN bricht den Handshake ab, und es kommt kein Tunnel zustande. Alles Übrige im Profil gilt weiterhin: Das Zertifikat muss zu einer vertrauenswürdigen CA führen, und die Rollenprüfung muss bestehen, also ist dies eine zusätzliche Bedingung und kein Ersatz. Ein Profil, das die Namenserwartung erfüllt und die Rollenprüfung nicht besteht, ist weiterhin defekt, und das Protokoll sagt das meist.

Es unterscheidet sich auch von der Hostnamen-Validierung eines Browsers. Ein Browser gleicht Namen nach den Regeln seines TLS-Stacks mit subject-Alternativnamen ab, während OpenVPN ein Zertifikatsfeld mit dem von Ihnen gewählten Typ vergleicht. Deshalb kann ein eingefügter Hostname im Browser-Stil in der Direktive eine Abweichung erzeugen, selbst wenn das Zertifikat den Dienst tatsächlich abdeckt.

subject: der vollständige distinguished name, Zeichen für Zeichen

Mit subject, der Voreinstellung, wenn kein Typ geschrieben wird, muss der erwartete Wert den gesamten subject-DN des Zertifikats wiedergeben. Feldreihenfolge, Trennzeichen, Abstände und Escaping zählen alle, weil der Vergleich auf der Zeichenkette so läuft, wie sie kodiert ist. Lassen Sie den Typ weg, haben Sie den strengsten der drei Vergleiche gewählt. Es gibt keinen Normalisierungsschritt, der einen kosmetischen Unterschied rettet. Das ist vor der ersten Erneuerung zu wissen, nicht danach.

Diese Strenge ist über Erneuerungen hinweg brüchig. Eine CA, die Attribute umsortiert, ein zusätzliches Feld einfügt oder das Escaping eines Werts ändert, erzeugt für dieselbe Maschine eine neue Zeichenkette, und eine Direktive, die jahrelang funktionierte, beginnt bei der nächsten Ausstellung zu scheitern. Den akzeptierten DN im Änderungsprotokoll zu behalten, macht aus der nächsten Erneuerung einen Diff. Wo der Betreiber einen vollständigen DN veröffentlicht und seine Form garantiert, ist subject eine vernünftige Wahl; anderswo ist ein engeres Feld leichter wahr zu halten.

name: ein Feld, meist der common name

Der Typ name vergleicht ein einzelnes subject-Feld. Sofern das Profil nichts anderes sagt, ist dieses Feld der common name, und der erwartete Wert ist genau dieses Feld, nicht der DN darum herum.

Der Haken ist, dass moderne Zertifikate den Dienstnamen nicht immer in den CN legen. Viele tragen ihn in einem subject-Alternativnamen und lassen den CN leer oder generisch, sodass ein Zertifikat, das ein Browser akzeptiert, diesen Vergleich trotzdem nicht besteht. Prüfen Sie das Zertifikat, das Ihnen tatsächlich ausgestellt wurde, bevor Sie die Erwartung schreiben, und bestätigen Sie, welches Feld das Profil auswählt. Ein leerer CN im Vergleich mit einem Namen ist eine Abweichung, kein Konfigurationsunfall.

name-prefix: bewusst breit, also eingrenzen

Eine Erwartung vom Typ name-prefix passt auf den Anfang des ausgewählten Felds. Das ist praktisch für ein Namensschema und gefährlich für alles Geteilte.

Mit vpn.example als Erwartung würden sowohl vpn.example.com als auch vpn.example.net durchgehen, sofern der Rest der Kette vertrauenswürdig ist. Die Breite ist die Funktion und zugleich der Teil, der schriftlich begründet gehört. Ein Präfix ist sinnvoll, wenn CA und Namensschema Ihre sind, und deutlich schwächer, wenn eine öffentliche CA in dasselbe Muster ausstellt. Braucht das Schema Flexibilität, begrenzen Sie es an der CA, statt die Client-Prüfung zu erweitern.

Wählen Sie den Typ aus dem Identifikator und belegen Sie ihn dann

Arbeiten Sie rückwärts von der Identität, die der Betreiber beabsichtigt. Veröffentlicht er einen vollständigen DN und hält ihn stabil, subject drückt das aus. Benennt er den Dienst über den common name, verwenden Sie name. Besitzt er ein Namensschema und akzeptiert dessen ganzen Raum, name-prefix sagt das ausdrücklich.

Erneuerungen sind der Ort, an dem die Direktive geprüft wird. Vergleichen Sie die freigegebene Identität mit dem neuen Zertifikat statt mit der alten Datei, denn eine neue Endpunktadresse bedeutet keine neue Zertifikatsidentität. Löschen Sie die Direktive nicht, nur weil eine vertraute Adresse antwortet: Erreichbarkeit und die beabsichtigte Gegenstelle sind verschiedene Tatsachen, und die Adresse beweist nur, dass etwas geantwortet hat. Halten Sie den genauen Fehler und die öffentlichen Namensdetails in einem bereinigten Bericht fest, denn eine Namensabweichung lässt sich ohne jedes private Schlüsselmaterial zeigen.

Nach einer unterstützten Korrektur verbinden Sie sich mit allen beabsichtigten Prüfungen erneut und verifizieren die Ressource, die Sie tatsächlich brauchen. Erfolg heißt, dass der beabsichtigte Server angenommen wurde, nicht dass irgendein Zertifikat durchgeschleust wurde. Das offizielle Handbuch OpenVPN 2.6 manual dokumentiert die drei Typen und ihre Vertrauenshinweise, und es ist die Referenz, die man zitiert, wenn eine Hersteller-Oberfläche dem Profil widerspricht.