Bevor Sie es umwandeln: SSH-Schlüssel gegen OpenVPN-Zertifikat

Der Import schlägt mit einem Zertifikatfehler fehl, also sieht der naheliegende Schritt wie eine Umwandlung aus. Dieser Instinkt führt Menschen auf einen Weg, auf dem sich die Dateiendung ändert und die Ablehnung genau dieselbe bleibt. Eine ssh-ed25519-Zeile in authorized_keys und ein OpenVPN-Clientzertifikat sind getrennte Berechtigungsobjekte mit unterschiedlichen Ausstellern, unterschiedlichen Kodierungen und unterschiedlichen Sperrwegen. Wer diese Prüfungen der Reihe nach durchgeht, weiß innerhalb einer Minute, ob eine Umwandlung überhaupt helfen kann.

Welches Objekt halten Sie eigentlich?

Es gibt fünf Dinge, die Menschen einen Schlüssel nennen, und nur eines davon ist das, was ein TLS-Profil will. Ein öffentlicher SSH-Schlüssel ist eine einzelne Textzeile mit Typpräfix und base64-Nutzlast. Ein OpenSSH-Zertifikat ist dieser Schlüssel plus eine Signatur, Principals und Optionen, erzeugt von ssh-keygen, das als eigene kleine CA auftritt. Ein X.509-Zertifikat ist eine ganz andere Struktur: Es trägt ein Subjekt, ein Gültigkeitsfenster, Erweiterungen und eine Signatur einer Zertifizierungsstelle. Ein privater Schlüssel ist die geheime Hälfte, und ein ausgegebenes Bündel ist meist ein Zertifikat plus seine Kette plus der private Schlüssel in einer Datei.

Der erste Test kostet einen Befehl. Richten Sie openssl auf die Datei und lassen Sie die Zertifikatsstruktur auslesen:

openssl x509 -in client.crt -noout -subject -issuer

Schlägt das mit einem Unable-to-load- oder PEM-Fehler fehl, ist die Datei kein X.509-Zertifikat, egal wie Sie sie genannt haben. Ein Umbenennen schreibt die ASN.1-Daten im Inneren nicht um, und das Einpacken einer öffentlichen Schlüsselzeile in PEM-Kopfzeilentext tut das auch nicht.

Verlangt das Profil überhaupt ein Zertifikat?

Clientzertifikate sind eine Authentifizierungsmethode unter mehreren, und viele funktionierende TLS-Profile verlangen nie eines. Ein Server kann Benutzer über ein Plugin, Benutzername und Passwort oder ein Token-Backend authentifizieren und trotzdem vom Client verlangen, die Identität des Servers zu prüfen. Enthält das Profil keine Clientzertifikat-Direktive, wird nie ein Zertifikat angefordert, und keine Umwandlung bringt das Gateway dazu, eines anzufordern.

Ältere Konfigurationen mit statischem Schlüssel sind ein dritter Fall. Sie stammen aus der Zeit vor dem TLS-Handshake und erwarten eine Datei mit vorab geteiltem Geheimnis, weshalb auch das Einfügen eines öffentlichen Schlüssels in dieses Feld nicht funktionieren kann. Lesen Sie, was das Profil tatsächlich verlangt, bevor Sie entscheiden, dass die Berechtigung falsch ist.

Was Neukodierung kann und was nicht

Private Schlüssel haben durchaus legitime alternative Container. Derselbe RSA- oder EC-Schlüssel lässt sich als traditionelles PEM, als PKCS#8 oder in einem PKCS#12-Bündel schreiben, und Werkzeuge konvertieren gern dazwischen. Öffentliche Schlüssel haben eine ähnliche Geschichte: ssh-keygen kann die RFC 4716-Form eines SSH-Schlüssels ausgeben, und OpenSSH versteht auch sein eigenes Zertifikatsformat. All das ist Darstellung, und Darstellung ist kein Vertrauen.

Was eine Umwandlung nicht kann, ist eine Signatur einer Zertifizierungsstelle zu erzeugen, die Ihren Schlüssel nie gesehen hat. Ein Zertifikat ist die Aussage eines Ausstellers, dass ein bestimmter öffentlicher Schlüssel zu einem bestimmten Subjekt für einen bestimmten Zweck gehört. Neukodierung bewahrt die Bytes des Schlüssels und lässt die Aussage fehlen, sodass das Gateway nichts gegen seinen Truststore prüfen kann.

An diesem Schritt scheitern die meisten Versuche still: Die Datei endet jetzt auf .crt, der Client liest sie ohne Beschwerde, und der Handshake bricht trotzdem ab, weil die Gegenseite keine Kette zu einem vertrauenswürdigen Aussteller aufbauen kann.

Wo die Zertifizierungsstelle ins Bild kommt

Eine echte Registrierung beginnt mit einem Schlüsselpaar, das Sie kontrollieren, und einem Zertifikatsignierungsantrag, der das vom Betreiber erwartete Subjekt trägt. Der Betreiber prüft den Anspruch, signiert den Antrag mit dem CA-Schlüssel und gibt das ausgestellte Zertifikat zusammen mit jeder Zwischenkette zurück, die der Client vorlegen muss. Danach braucht der Client das CA-Zertifikat, das es signiert hat, denn genau damit kann er bestätigen, dass der Server, mit dem er spricht, zur selben Bereitstellung gehört.

Diese letzte Datei vergisst man leicht und ersetzen kann man sie nicht. Der Signaturschlüssel der CA selbst gehört nie in die Clientkonfiguration, und keine lokale Umwandlung erzeugt die Kette, die Sie erhalten sollten.

Was die Wiederverwendung des SSH-Schlüssels kostet

Angenommen, eine Umwandlung hätte tatsächlich etwas Akzeptables erzeugt. Ein Schlüsselpaar sowohl für SSH-Zugang als auch für VPN-Authentifizierung zu verwenden, koppelt weiterhin zwei unabhängige Sicherheitsentscheidungen. Das Entfernen eines authorized_keys-Eintrags stoppt SSH-Anmeldungen und ändert nichts an einem Zertifikat, das die VPN-CA bereits für denselben öffentlichen Schlüssel ausgestellt hat. Die VPN-Seite wird über ihren eigenen Mechanismus gesperrt, also die Zertifikatssperrliste oder den Registrierungseintrag des Betreibers.

Die Checkliste endet also mit einer Abbruchbedingung statt mit einem Trick. Wenn openssl die Datei nicht als Zertifikat auslesen kann, hören Sie mit dem Umwandeln auf und beschreiben Sie, was Sie haben: SSH-Schlüssel, SSH-Zertifikat, X.509-Zertifikat, privaten Schlüssel oder Bündel. Wenn das Profil kein Clientzertifikat verlangt, hören Sie auf und fragen Sie, welche Authentifizierungsmethode der Server erwartet. Erst wenn beide Antworten auf X.509 zeigen, wird die Registrierung der nächste Schritt, und dieses Gespräch läuft viel schneller mit dem richtigen Substantiv im ersten Satz.