Ein verschlüsselter privater Schlüssel und ein unverschlüsselter enthalten dasselbe Schlüsselmaterial. Die Umwandlung erzeugt keine neue Identität, setzt kein VPN-Konto zurück und macht die alte Datei nicht ungültig. Sie schreibt eine zweite Kopie, und diese Kopie trägt ein anderes Ruherisiko.

Ob der Tausch sich lohnt, hängt davon ab, wo die Datei liegen wird und wer sie lesen kann.

Was die Umwandlung tatsächlich ändert

Vor der Umwandlung schützt eine Passphrase den Schlüssel, die der Betreiber angibt. Nach der Umwandlung schützen ihn Dateisystemberechtigungen und jede Zugriffskontrolle, die die Datei umgibt. Die Kryptografie hat sich nicht geändert; die Zahl der Dinge zwischen einem Angreifer und dem Schlüssel hat sich geändert. Das ist der ganze Vergleich.

Eine Tabelle macht den Unterschied konkret.

FormWhat protects itHow it fails
Encrypted keyA passphrase plus file accessWeak passphrase, or an offline attack on the file
Unencrypted keyFile permissions and host security onlyAny reader copies it silently

Keine der beiden Formen ist automatisch sicherer. Sie scheitern auf unterschiedliche Weise, und nur eine dieser Weisen hinterlässt einen Logeintrag.

Wann es besser ist, die Passphrase zu behalten

Kann ein unterstützter Client die Passphrase abfragen oder aus einem genehmigten Secret Store holen, bringt die Umwandlung nichts. Sie behalten eine Kopie, eine Schutzgrenze und eine Datei weniger zu verwalten. Die meisten VPN-Clients, die PEM-Schlüssel akzeptieren, können das.

Die Umwandlung ist auch der falsche Schritt, wenn ein Team den Schlüssel teilt. Eine unverschlüsselte Datei auf einem gemeinsam genutzten Host wird zu einem Geheimnis, das jeder mit Shell-Zugriff kopieren kann.

Wann eine unverschlüsselte Kopie gerechtfertigt ist

Manche Dienste können nicht abfragen, manche Container binden Geheimnisse schreibgeschützt ein, und manche Geräte lesen eine Schlüsseldatei beim Start ohne interaktiven Weg. In diesen Fällen kann ein unverschlüsselter Schlüssel in einem ordentlich beschränkten Verzeichnis das unterstützte Design sein. Die Rechtfertigung ist die Umgebung, nicht die Bequemlichkeit.

Wenn Sie nicht sagen können, wer die Datei lesen kann und warum, lautet die Antwort nein.

Der Befehl und seine scharfen Kanten

Für einen dateibasierten Schlüssel, den OpenSSL 3.5 unterstützt, die pkey-Referenz dokumentiert das Entfernen der Passphrase und eine interaktive Abfrage, wenn die Eingabe verschlüsselt ist und keine Passwortquelle angegeben wird. Die minimale Form ist kurz, und sie lässt sich leicht unvorsichtig ausführen.

umask 077
openssl pkey -in protected-key.pem -out new-private-key.pem

Drei scharfe Kanten. Die E/A der Ausgabedatei ist nicht atomar, daher kann ein vorhandener Ausgabepfad mitten im Schreiben abgeschnitten werden. Verwenden Sie den Eingabepfad nicht als Ausgabe, und experimentieren Sie nicht mit der einzigen geschützten Kopie. Geben Sie die Passphrase an der Abfrage ein, nicht auf der Kommandozeile, wo sie in der Shell-Historie landet.

Prüfen Sie das Ergebnis, bevor Sie eine VPN-Konfiguration ändern: openssl pkey -in new-private-key.pem -pubout sollte denselben öffentlichen Schlüssel ausgeben, den Sie vorher hatten.

Was die Umwandlung nicht tut

Sie widerruft nicht die verschlüsselte Kopie, die dort weiterhin existiert, wo Sie sie liegengelassen haben. Sie ändert weder das Passwort des VPN-Kontos noch das Zertifikat. Und sie repariert keine Offenlegung, die bereits geschehen ist. Wenn ein Schlüssel abgeflossen ist, lautet die Lösung Ersatz und serverseitiger Widerruf, nicht eine lokale Formatänderung.

Löschen Sie die Zwischendatei bewusst, und bestätigen Sie, dass der Pfad, den Sie löschen, der von Ihnen erstellte ist.

Ähnliche Artikel