Altes P12 scheitert an OpenSSL 3: falsches Passwort oder veraltete Chiffre?

Der Importdialog nimmt Ihr Passwort, dreht sich einen Moment und meldet dann, dass er das Bundle nicht lesen kann. Nichts in dieser Meldung sagt Ihnen, ob Sie die Passphrase falsch getippt haben oder ob die Datei mit einer Chiffre versiegelt wurde, die der Client nicht mehr mitliefert. Das sind verschiedene Fehler mit verschiedenen Korrekturen, und die falsche Wahl führt zu einem Downgrade des Clients, das die Entscheidung nur aufschiebt. Wenn Sie beobachten, an welcher Stelle der Client abbricht, trennen Sie beide in etwa einer Minute.

Was zwischen dem Dialog und der Zertifikatliste passiert

Eine .p12-Datei ist ein Container, kein Zertifikat. Darin liegen eine oder mehrere Zertifikatstaschen und eine Privatschlüsseltasche, die mit einem aus Ihrem Passwort abgeleiteten Schlüssel verschlüsselt ist, dazu eine Integritätsprüfung namens MAC über die gesamte Datei. Sie zu öffnen heißt, diesen MAC zu prüfen, die Schlüsseltasche zu entschlüsseln und das Zertifikat mit dem Schlüssel abzugleichen, der dabei herauskommt.

Passwortprobleme treten beim MAC-Schritt auf. Chiffreprobleme treten später auf, wenn die Schlüsseltasche entpackt werden muss und der Build, der das tut, keine Implementierung für den in der Datei genannten Algorithmus hat.

Der zweite Fall ist auf heutigen Systemen verbreitet, weil OpenSSL 3 eine Gruppe alter Algorithmen in einen optionalen Legacy-Provider verschoben hat. Von OpenSSL 1.x exportierte Bundles versiegelten die Zertifikate üblicherweise mit 40-Bit-RC2 und den Privatschlüssel mit Triple DES mit drei Schlüsseln. Ein Standard-OpenSSL-3-Build prüft den MAC weiterhin mit Ihrem korrekten Passwort und scheitert dann an der Tasche, das Passwort war also nie falsch, und es erneut einzutippen ändert nichts.

Lesen Sie den Container, ohne einen Schlüssel auszugeben

Bitten Sie den OpenSSL-Build auf Ihrem eigenen Rechner, die Datei zu parsen und die Stelle zu lesen, an der er aufgibt. Eine Prüfung ohne Ausgabedatei lässt den Schlüssel auf der Platte verschlüsselt, und das ist der einzige Grund, warum dieser Schritt auf einem gemeinsam genutzten Host sicher ist.

openssl pkcs12 -in vpn-identity.p12 -info -noout

Bei einem Legacy-Bundle mit dem korrekten Passwort druckt dies die Taschenattribute und bricht dann mit digital envelope routines::unsupported ab. Mit einem falschen Passwort erhalten Sie Mac verify error: invalid password?, bevor irgendeine Tasche gelesen wird. Die beiden Meldungen zeigen in entgegengesetzte Richtungen, und genau das ist die Information, die der Client zurückgehalten hat.

Wenn der Fehler der mit dem nicht unterstützten Algorithmus ist, führen Sie denselben Befehl erneut aus, mit -legacy ergänzt und sonst nichts geändert. Dieses Flag lädt den Legacy-Provider nur für diesen einen Prozess. Es bringt den VPN-Client nicht dazu, alte Bundles zu parsen, es berührt nicht die systemweite Kryptopolitik, und es ist eine Messung statt einer Reparatur, denn die Datei muss trotzdem ersetzt werden.

Welcher Fehler welche Stufe bedeutet

Eine kurze Tabelle hält die drei Ergebnisse auseinander, und die Formulierung ist wichtiger als die Stelle, an der der Dialog erschien.

Text wie not enough data oder header too long gehört zu keiner der ersten beiden Gruppen. Das ist ein Formatproblem: eine DER-Datei, die in .pem umbenannt wurde, eine Kopie, die ein Editor durch Neuschreiben der Zeilenenden verunstaltet hat, oder ein unvollständiger Download. Vergleichen Sie die Prüfsumme mit der, die der Aussteller geschickt hat, bevor Sie sich Chiffren ansehen.

Behandeln Sie Mac verify error nur als Beleg über das Passwort. Es bedeutet, dass der aus Ihrer Eingabe berechnete MAC nicht zum gespeicherten Wert passt, was bei einem Tippfehler, bei einem aus einem früheren Import zwischengespeicherten Passwort oder bei einer Datei passiert, die unter einer anderen Passphrase neu exportiert wurde. Über das Alter der enthaltenen Algorithmen sagt es nichts.

Bauen Sie ein Bundle, das der Client wirklich öffnen kann

Sobald der Legacy-Parser bestätigt, dass die Datei in Ordnung ist, ist die dauerhafte Lösung ein Ersatz, dessen Algorithmen der Zielclient unterstützt: AES-256-CBC für die Schlüssel- und Zertifikatstaschen, PBKDF2 mit SHA-256 für die Ableitung und SHA-256 für den MAC. Ihr PKI-Administrator kann das aus demselben Schlüsselmaterial exportieren, und das Zertifikat darin bleibt das, dem Ihre Server bereits vertrauen.

Wenn Sie lokal konvertieren müssen, bitten Sie das pkcs12-Werkzeug, die Taschen neu zu versiegeln, statt sie zuerst auszugeben. Halten Sie beide Passphrasen aus Ihrer Shell-Historie heraus, indem Sie sie aus einer Datei lesen.

openssl pkcs12 -in vpn-identity.p12 -out vpn-identity-aes.p12 \
  -keypbe AES-256-CBC -certpbe AES-256-CBC -macalg sha256 \
  -passin file:old.pass -passout file:new.pass

Eine erfolgreiche Konvertierung sagt nichts über Ablauf, Schlüsselverwendung, die Übereinstimmung des Privatschlüssels oder darüber, ob der Server der ausstellenden Kette vertraut. Neuverpacken ist eine Transportänderung, keine Erneuerung, und jedes dieser Dinge braucht weiterhin seine eigene Prüfung.

Überspringen Sie jedes Rezept, das einen ungeschützten Zwischenschlüssel schreibt oder ein leeres Ausgabepasswort, nur weil der Client die Datei danach akzeptiert hat. Ein lesbares Bundle mit entzogenem Schutz ist ein schlechteres Ergebnis als der Importfehler, mit dem Sie begonnen haben.

Bestätigen Sie, dass der Client die gebaute Datei importiert hat

Ein sauberes Parsen im Terminal beweist, dass der Container gültig ist. Es beweist nicht, dass der Client ihn gewählt hat, denn ein zurückgebliebenes Profil kann weiter auf die alte Datei zeigen, und manche Clients legen eine importierte Identität unter einem Namen ab, den Sie nicht gewählt haben.

Drucken Sie die Identität, die Sie gleich importieren, und vergleichen Sie sie mit dem, was der Client in seiner Zertifikatsansicht zeigt.

openssl pkcs12 -in vpn-identity-aes.p12 -clcerts -nokeys -passin file:new.pass \
  | openssl x509 -noout -subject -dates -fingerprint -sha256

Entfernen Sie zuerst den veralteten Profileintrag, dann importieren Sie. Wenn der Client den geladenen Subjekt oder Fingerabdruck protokolliert, gleichen Sie ihn mit der Zeile oben ab; wenn er nur einen freundlichen Namen zeigt, prüfen Sie stattdessen das Ablaufdatum, da dieses schwerer mit einem anderen Zertifikat desselben Ausstellers zu verwechseln ist.

Die PKCS12-Referenz listet die hier verwendeten Provider-, Passphrase- und Ausgabeoptionen auf. Der Punkt ist, den Legacy-Provider aus der Client-Umgebung herauszuhalten: damit messen, ohne ihn ausliefern und den Privatschlüssel auf der Platte geschützt lassen.