Selbstsigniertes VPN-Zertifikat: Was es bedeutet und wem es vertraut

Zwei Überzeugungen richten hier den meisten Schaden an: dass ein selbstsigniertes VPN-Zertifikat bedeutet, der Tunnel sei nicht verschlüsselt, und dass die Installation dessen, worum der VPN-Client gebeten hat, nur die VPN betrifft. Keine von beiden übersteht den Kontakt mit einer echten Bereitstellung. Ein selbstsigniertes Zertifikat beschreibt eine Signaturbeziehung, kein Sicherheitsurteil, und die Reichweite des Vertrauens, das Sie hinzufügen, hängt davon ab, in welchem Speicher es landet. Ich habe erlebt, wie ein Helpdesk eine Anbieter-Wurzel in einen Windows-Rechner importierte, um eine Warnung zum Schweigen zu bringen, und dann einen Nachmittag damit verbrachte zu erklären, warum der Browser aufgehört hatte, sich über ein unabhängiges Portal zu beschweren. Die beiden Hälften dieser Frage gehören zusammen, behandeln Sie sie also als eine.

Ein Zertifikat ist kein Vertrauensspeicher

Die Datei, die der Server vorlegt, trägt einen öffentlichen Schlüssel, einen Subjektnamen, einen Ausstellernamen, Gültigkeitsdaten und Erweiterungen. Selbstsigniert heißt, dass Subjekt und Aussteller dieselbe Entität sind und die Signatur mit dem eigenen Schlüssel des Zertifikats verifiziert wird. Nichts an dieser Definition sagt, dass die Verbindung schwach ist, und nichts sagt, dass der Client sie akzeptieren wird.

Akzeptanz kommt von woanders: eine CA-Datei, auf die Sie den Client zeigen, ein Fingerabdruck, den Sie von Hand vergleichen, oder eine Wurzel, die bereits in einem Speicher liegt, den der Client liest. Eine Bereitstellung kann völlig solide sein, während ihr Zertifikat jeden öffentlichen Test bestehen würde. openssl verify gegen das Systembündel meldet einen unbekannten Aussteller, und dieser Bericht ist korrekt und kein Fehler.

Die Option ca von OpenVPN ist der klarste Fall app-begrenzten Vertrauens. Diese Datei benennt die Anker, die der Client akzeptieren wird, und sie kann eine private CA oder in einer kleinen Bereitstellung das eigene selbstsignierte Zertifikat des Servers enthalten. Version 2.6 akzeptiert außerdem --peer-fingerprint, um einen SHA-256-Fingerabdruck zu pinnen, statt eine CA-Datei zu verteilen. WireGuard liegt noch weiter draußen: Es hat überhaupt keine Zertifikate, nur einen statischen öffentlichen Schlüssel pro Peer, sodass die Frage nach der Selbstsignatur darauf nicht passt.

Wo Sie Vertrauen installieren, entscheidet, wer es erbt

Legen Sie dasselbe Zertifikat an drei Stellen ab, erhalten Sie drei verschiedene Wirkungsradien. Ein Bündel, das nur der VPN-Client liest, betrifft diesen Client. Eine Wurzel im Betriebssystem-Speicher betrifft jedes Programm, das diesen Speicher konsultiert. Ein Browser mit eigener Vertrauensdatenbank kann beides ignorieren, weshalb eine Warnung einen Import überleben kann, der zu funktionieren schien.

Unter Debian oder Ubuntu verändert das Ablegen einer Datei in /usr/local/share/ca-certificates/ und das Ausführen von update-ca-certificates das systemweite Bündel. Unter Windows schreibt certutil -addstore -f Root in den Maschinenspeicher und benötigt eine erhöhte Eingabeaufforderung, während das Hinzufügen von -user stattdessen den Speicher des aktuellen Benutzers anspricht; die beiden sind nicht austauschbar. Firefox führt seine eigene NSS-Datenbank, sodass ein Import auf Betriebssystemebene dort möglicherweise nie auftaucht.

Der Umfang zählt wegen dessen, was eine Autorität tun kann. Eine ausstellende CA kann für Namen signieren, zu denen sie keine Beziehung hat, sodass alles, was diesem Speicher vertraut, diese Signaturen akzeptiert. Ein einzelnes gepinntes Blatt kann das nicht; es authentifiziert genau eine Peer-Identität. Wenn das Ziel ist, eine VPN zum Verbinden zu bringen, erreicht eine app-begrenzte CA oder ein gepinntes Blatt das, während eine maschinenweite Wurzel ein weit größeres Zugeständnis ist, als das Symptom verlangt.

Sie verschlüsseln weiterhin ohne öffentliche CA

Der TLS-Handshake leitet Sitzungsschlüssel ab, unabhängig davon, ob das Peer-Zertifikat zu etwas verkettet, dem Sie bereits vertrauen. Selbstsigniert bedeutet nicht Klartext und nicht, dass der Verkehr unterwegs lesbar ist. Es bedeutet, dass der Client keinen A-priori-Grund hat zu glauben, der Schlüssel gehöre dem Server, den er angefragt hat.

In dieser Lücke leben echte Angriffe. Ein Client, der so konfiguriert ist, jedes Zertifikat zu akzeptieren, sei es durch eine deaktivierte Verifizierungseinstellung oder eine trotzdem-vertrauen-Schaltfläche, die einmal geklickt und vergessen wurde, verschlüsselt fröhlich zu dem, der antwortet. Die Abfangung geschieht im Authentifizierungsschritt, bevor Anwendungsdaten fließen. Verschlüsselung ohne Identitätsprüfung hält einen passiven Beobachter draußen und tut wenig anderes.

Dem Aussteller zu vertrauen überspringt nicht die Namensprüfung

Kettenvalidierung, Namensabgleich und Zertifikatszweck sind getrennte Entscheidungen. Eine Kette kann gültig sein, während der Name falsch ist, und ein Name kann passen, während das Zertifikat für eine andere Rolle ausgestellt wurde. RFC 5280 definiert die Felder, die diese Beschränkungen tragen, und wie streng ein Client sie durchsetzt, ist Sache jeder Anwendung.

OpenVPN macht die Trennung sichtbar. verify-x509-name pinnt das erwartete Subjekt über name-, name-prefix- oder subject-Abgleich. remote-cert-tls server verlangt, dass das Peer-Zertifikat als Serverzertifikat verwendbar ist, was ein reines Client-Zertifikat ablehnt, selbst wenn der Aussteller vertrauenswürdig ist. Keine der beiden Einstellungen wird durch das Ausliefern einer CA-Datei ersetzt.

Prüfen Sie das Zertifikat, bevor Sie irgendetwas entscheiden:

• openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName zeigt, wer es ausgestellt hat, für welche Namen und bis wann.
• openssl verify -CAfile ca.crt server.crt prüft, ob die Kette, die Sie ausliefern wollen, das Blatt tatsächlich validiert.
• openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -CAfile ca.crt -verify_return_error funktioniert für TLS-Endpunkte wie ein Webportal; das OpenVPN-Protokoll auf 1194 ist kein reiner TLS-Strom, daher gilt dieser Test dort nicht.

Ein Zertifikat mit abgelaufenem Datum, ohne subjectAltName für den Namen, mit dem Sie sich verbinden, oder ohne serverAuth-Verwendung scheitert, unabhängig davon, wie sorgfältig der Anker installiert wurde.

Fünf Prüfungen, bevor Sie eines akzeptieren

Vergleichen Sie den Fingerabdruck über einen Kanal, der nicht die Verbindung ist, die Sie reparieren wollen: eine Konsole, ein Installationsprogramm, das Sie bereits haben, eine signierte Konfigurationsdatei. openssl x509 -in server.crt -noout -fingerprint -sha256 auf dem Server und derselbe Wert im Client-Protokoll genügen, um zu wissen, dass Sie ein Objekt betrachten.

Entscheiden Sie als Nächstes, was Sie installieren: ein Blatt oder eine Autorität, die mehr prägen kann. Dann entscheiden Sie, wohin es geht, und benennen Sie die Anwendungen, die diesen Speicher lesen. Schreiben Sie den Entfernungspfad auf, solange Sie ihn noch erinnern, denn vertrauen-und-weiter ist der Weg, auf dem ein vorübergehender Import dauerhaft wird.

Planen Sie schließlich die Änderung. Ein gepinntes Zertifikat oder ein Fingerabdruck muss über denselben vertrauenswürdigen Kanal aktualisiert werden, wenn das Zertifikat rotiert, und eine private CA hat ihren eigenen Ausstellungs- und Widerrufslebenszyklus. Wenn der private Schlüssel leckt, repariert das erneute Vertrauen in eine Kopie desselben Zertifikats nichts; die Identität muss ersetzt werden.

Wenn eine Warnung alle fünf Prüfungen übersteht, ist die nützliche Frage nicht, welche Schaltfläche sie verstummen lässt, sondern welchen Speicher der Client tatsächlich liest und woher diese Wurzel kam. Beantworten Sie das, und der Import, den Sie gerade vornehmen wollen, wird eine Entscheidung statt eines Reflexes.