Ein OpenVPN-Profil enthält drei Zertifikatsblöcke: Welcher ist geheim?
Ein Profil trägt ein CA-Zertifikat, ein Client-Zertifikat und einen privaten Schlüssel, die gleich aussehen. Nur einer ist geheim, und jeder scheitert auf andere Weise.
Sie öffnen eine .ovpn-Datei, um eine Zeile zu ändern, und finden drei base64-Blöcke, die alle wie Zugangsdaten aussehen. Einer ist unbedenklich zu veröffentlichen, einer ist so sensibel wie ein Passwort, und einer ist ein öffentlicher Schlüssel, der nichts bedeutet, solange nicht etwas anderes mit seinem Gegenstück signiert hat. Leute kleben die ganze Datei in einen Support-Thread, weil die Blöcke austauschbar wirken, und so landet ein Client-Schlüssel in einem öffentlichen Archiv. Zu klären, welcher Block was tut, erklärt den größten Teil der Verwirrung um diese Profile und sagt Ihnen auch, welche Fehler Sie selbst beheben müssen.
Eine Datei, drei Blöcke, verschiedene Aufgaben
Ein typisches Profil bettet einen ca-Block, einen cert-Block und einen key-Block zwischen BEGIN- und END-Markern ein oder verweist auf dieselben drei als separate Dateien. Manche Profile fügen einen vierten Block für einen tls-auth- oder tls-crypt-Schlüssel hinzu, der ein gemeinsames Geheimnis und kein Zertifikat ist. Der Client liest jeden Block nach der Direktive, die ihn benennt, daher zählen die Bezeichnungen mehr als die Reihenfolge des Erscheinens.
Behandeln Sie das zusammengesetzte Profil als sensibel, bis Sie wirklich hineingeschaut haben. Ein öffentliches Zertifikat und ein privater Schlüssel können in derselben Datei nur wenige Zeilen auseinanderliegen, und ein Screenshot mit dem Kopf kann beide enthalten. Das sichtbare base64 von Hand zu schwärzen ist ebenfalls unzuverlässig, weil ein Teilblock noch immer die Zertifikatsmetadaten preisgibt, die Ihre Bereitstellung benennen. Die drei Direktiven ohne ihre Werte zu kopieren reicht meist, um eine sinnvolle Frage zu stellen.
Die Direktiven um die Blöcke herum entscheiden, wie sie verwendet werden. Ändern Sie ca und der Client vertraut einer anderen Instanz; ändern Sie cert ohne key und der Handshake scheitert an einer Nichtübereinstimmung, die nichts mit Vertrauen zu tun hat.
Der CA-Block ist öffentlich, der CA-Schlüssel nie
Eine Zertifizierungsstelle signiert Zertifikate, die einen öffentlichen Schlüssel an eine Identität binden, und ihr eigenes Zertifikat ist der Anker, an dem ein Client entscheidet, ob eine Kette vertrauenswürdig ist. Dieses Zertifikat ist von Natur aus öffentlich: es in jedem Profil mitzuliefern ist normal, und genau deshalb kann eine selbstsignierte Bereitstellung ohne kommerzielle Instanz funktionieren.
Was nie in einem Client-Profil auftauchen darf, ist der private Signaturschlüssel der Instanz. Der Client braucht ihn für keine Prüfung, und seine Anwesenheit bedeutet, dass jeder, der das Profil hat, neue Identitäten für die gesamte Bereitstellung erzeugen kann.
Einer Instanz zu vertrauen ist auch enger, als es klingt. Ein Client, der jedes von der CA signierte Zertifikat akzeptiert, akzeptiert weiterhin ein Zertifikat, das für einen anderen Dienst derselben CA ausgestellt wurde. Optionen, die die erwartete Serverrolle oder den Namen festnageln, schließen diese Lücke, und die TLS-Optionsreferenz listet die Prüfdirektiven auf, die das tun.
Server- und Client-Zertifikat zeigen in entgegengesetzte Richtungen
Das Server-Zertifikat ist das, was der Client prüft, um zu bestätigen, dass er den richtigen Endpunkt erreicht hat. Ihr Client-Zertifikat läuft andersherum: der Server nutzt es, um zu entscheiden, dass dieses Gerät oder dieser Nutzer eines ist, das er aufgenommen hat. Gleiches Format, entgegengesetzte Vertrauensrichtung.
Eine Adresse ist keine Identität. Die richtige IP zu erreichen beweist nichts darüber, wer geantwortet hat, deshalb gehört die Prüfung von Hostname oder Zertifikatsname weiterhin ins Profil. Ein Kontopasswort ersetzt auch nicht stillschweigend ein erforderliches Client-Zertifikat, weil beide in verschiedenen Phasen geprüft werden und eine Bereitstellung beides verlangen kann.
Der private Clientschlüssel ist der Teil, der privat bleiben muss. Wenn er offengelegt worden sein könnte, ändert das Löschen der Datei auf Ihrem Laptop auf dem Server nichts, der das zugehörige Zertifikat weiter akzeptiert, bis der Betreiber es widerruft. Den Betreiber zu bitten, diese Identität zu ersetzen oder zu widerrufen, ist die einzige Lösung, die mitreist.
Zwei Abfragen, die gleich aussehen und es nicht sind
Ein verschlüsselt gespeicherter Schlüssel fragt nach einer Passphrase, bevor der Client ihn nutzen kann. Der VPN-Dienst kann getrennt ein Kontopasswort abfragen, und die beiden Abfragen können Sekunden auseinander mit fast gleichem Wortlaut erscheinen. Die Passphrase schützt eine Datei auf Ihrer Festplatte; das Passwort weist ein Konto gegenüber einem Server aus. Verwechslung schickt Leute zu Passwort-Zurücksetzungen, die unmöglich helfen können.
Lesen Sie die Abfrage, bevor Sie irgendetwas zurücksetzen. Ein Kontopasswort-Reset bewirkt nichts für eine vergessene Schlüssel-Passphrase, ein widerrufenes oder ein abgelaufenes Zertifikat, und das Passwort zurückzusetzen, wenn der Fehler die Zertifikatsprüfung ist, macht aus einer Zwei-Minuten-Korrektur einen Supportfall. Wenn die Beschwerde Gültigkeitsdaten nennt, prüfen Sie zuerst die Geräteuhr und dann das eigene Fenster des genannten Zertifikats.
Wenn das Zertifikat wirklich abgelaufen ist, muss der Ersatz von dem kommen, der es ausgestellt hat. Ein Schlüssel, der jemand anderem gehört, ist kein Erneuerungsweg, und ein funktionierendes Profil von einer Kollegin zu leihen auch nicht.
Was ein sauberer Handshake beweist und was nicht
Einen abgeschlossenen TLS-Handshake zu erreichen heißt, dass die konfigurierte Identitätsbeziehung gehalten hat: das Server-Zertifikat hing an Ihrer CA und Ihr Zertifikat wurde akzeptiert. Es sagt nichts über die Protokollierungspolitik des Betreibers und nichts darüber, ob Ihre Anwendungen laufen, sobald der Tunnel steht.
Routen und DNS sind spätere Phasen der Verbindung, also ist ein unerreichbarer Intranet-Host nach erfolgreicher Anmeldung ein Verbindungsproblem und kein Zertifikatsproblem. Arbeiten Sie an dieser Schicht statt an den Zugangsdaten, und halten Sie Herkunft des Profils, sein privates Material und seine Identitätsprüfungen beisammen, wenn Sie es jemandem geben.