OpenVPN-Schlüsselabfrage nach OpenSSL 3: den Provider prüfen

Niemand hat das Profil angefasst, und doch verlangt derselbe Client jetzt bei jedem Start eine Passphrase für den privaten Schlüssel. Wenn diese Änderung wenige Tage nach einem Distributions-Upgrade auftritt, ist das Upgrade die wahrscheinliche Ursache: OpenSSL 3 hat seine Algorithmusunterstützung neu geordnet, und ein Schlüssel, den die alte Bibliothek anstandslos las, kann unlesbar werden, ohne dass sich ein einziges Byte ändert. Arbeiten Sie die Prüfungen der Reihe nach ab, denn zwei davon sehen allein anhand der Abfrage identisch aus.

Die erste Frage ist, ob der Schlüssel verschlüsselt ist, und die zweite, ob dieser Build ihn entschlüsseln kann. Konfigurationsänderungen ergeben erst Sinn, wenn beide Antworten bekannt sind.

Prüfen Sie, ob der Schlüssel verschlüsselt ist

Lesen Sie die erste Zeile der Datei und lassen Sie dann die Bibliothek sie parsen, denn ein Dateiname beweist nichts. Ein PEM-Block mit der Kennzeichnung ENCRYPTED PRIVATE KEY ist verschlüsseltes PKCS#8, und ein älterer RSA PRIVATE KEY Block mit Proc-Type: 4,ENCRYPTED ist die traditionelle Form; beide erwarten eine Passphrase. Ein unverschlüsselter PRIVATE KEY Block sollte gar keine verlangen. Führen Sie das Parsen unter dem Konto aus, dem die Datei gehört, denn ein Berechtigungsproblem erzeugt einen anderen und weit weniger interessanten Fehler.

Wenn der Schlüssel wirklich unverschlüsselt ist und der Client trotzdem fragt, hören Sie auf, auf die Kryptografie zu schauen, und prüfen Sie, ob das Profil eine askpass-Datei nennt, die der Dienst noch lesen kann.

Prüfen Sie, ob dieser Build ihn entschlüsseln kann

OpenSSL 3 hat seine Algorithmusunterstützung in Provider aufgeteilt, und eine Reihe älterer Chiffren liegt jetzt im legacy-Provider statt im Standard-Provider. Ein mit einer dieser Chiffren verschlüsselter Schlüssel bleibt gültig, doch eine ohne den legacy-Provider geladene Bibliothek kann ihn nicht decodieren. Bei manchen Clients zeigt sich das als wiederkehrende Abfrage, bei anderen als harter Fehlschlag direkt nach der Passphrase.

Parsen Sie denselben Schlüssel zweimal mit derselben Binärdatei: zuerst nur mit dem Standard-Provider, dann mit legacy und Standard gemeinsam auf der Kommandozeile angefordert. Gelingt der zweite Versuch dort, wo der erste scheiterte, stützt sich die Diagnose auf Belege statt auf den Zeitpunkt eines Upgrades. Scheitern beide identisch, ist die Passphrase falsch oder die Datei beschädigt, und keine Provider-Einstellung repariert eines von beidem.

Prüfen Sie die engstmögliche Korrektur

Bevorzugen Sie eine auf den Client begrenzte Änderung gegenüber einer systemweiten. Manche 2.6-Builds akzeptieren eine Profiloption, die beide Provider für den Prozess dieses Daemons lädt, prüfen Sie die Direktive also im Handbuch für Ihre genaue Version, bevor Sie sich darauf verlassen; das Bearbeiten der systemweiten openssl.cnf wirkt stattdessen auf jedes OpenSSL-Programm auf dem Host. Die engere Einstellung lässt sich zudem viel leichter zurücknehmen, sobald der Schlüssel neu codiert ist.

Löschen Sie die Passphrase nicht, damit die Abfrage verschwindet. Das verwandelt einen geschützten Berechtigungsnachweis in eine Klartextdatei und verändert still das Risiko jedes Backups, jeder Kopie und jedes Support-Bundles, in dem er auftaucht. Entscheidend ist der Unterschied zwischen einem Schlüssel, der seine Passphrase braucht, und einem Schlüssel, den diese Bibliothek nicht decodieren kann.

Prüfen Sie den Dienstkontext und codieren Sie dann neu

Sobald der Schlüssel entsperrt werden kann, verschlüsseln Sie ihn mit einem aktuellen Algorithmus neu damit die Abhängigkeit verschwindet. Schreiben Sie die neue Datei mit einer modernen Chiffre, prüfen Sie, dass sie parst, aktualisieren Sie das Profil und behalten Sie die alte Kopie nur, bis eine Verbindung gelingt. Legen Sie die Passphrase niemals auf eine Kommandozeile, wo jeder lokale Benutzer sie aus der Prozessliste lesen kann. Entfernen Sie die alte Datei erst, nachdem die neue vom Dienstkonto aus verbunden hat, nicht nur aus Ihrer Shell.

Prüfen Sie dann die Unit, die den Client tatsächlich startet. Ein in Ihrer Shell lesbarer Schlüssel kann für einen Dienst unlesbar sein, der unter einem anderen Konto oder mit einer gehärteten Home-Verzeichnis-Einstellung läuft.

Notieren Sie die Provider-Einstellung neben dem Profil und bewahren Sie den Zwei-Befehle-Test dabei auf. Wenn ein späteres Upgrade den legacy-Provider entfernt, führen Sie diesen Test erneut aus, um zu sehen, ob der Schlüssel ihn noch braucht oder ob das Profil aus dem Workaround herausgenommen werden kann.

Eine Abfrage ist ein Symptom mit mindestens drei Ursachen, und nur eine davon ist eine fehlende Passphrase.