Starý P12 selhává na OpenSSL 3: špatné heslo, nebo zastaralá šifra?

Dialog importu převezme vaše heslo, chvíli se točí a potom oznámí, že balík nedokáže přečíst. Nic v té zprávě neříká, zda jste heslo přepsali špatně, nebo zda byl soubor zapečetěn šifrou, kterou klient už nedodává. Jsou to různé poruchy s různými opravami a špatná volba vede k downgradu klienta, který rozhodnutí jen odkládá. Sledování fáze, ve které se klient zastaví, je oddělí zhruba za minutu.

Co se děje mezi dialogem a seznamem certifikátů

Soubor .p12 je kontejner, ne certifikát. Uvnitř je jedna nebo více tašek s certifikáty a taška se soukromým klíčem zašifrovaná klíčem odvozeným z vašeho hesla, plus kontrola integrity zvaná MAC nad celým souborem. Otevřít ho znamená ověřit tuto MAC, dešifrovat tašku s klíčem a spárovat certifikát s klíčem, který z ní vzejde.

Problém s heslem přichází v kroku MAC. Problém s šifrou přichází později, když je třeba tašku s klíčem rozbalit a sestavení, které to dělá, nemá implementaci algoritmu uvedeného v souboru.

Druhý případ je na současných systémech běžný, protože OpenSSL 3 přesunul skupinu starých algoritmů do volitelného legacy poskytovatele. Balíky exportované OpenSSL 1.x obvykle pečetily certifikáty 40bitovým RC2 a soukromý klíč trojklíčovým Triple DES. Výchozí sestavení OpenSSL 3 stále ověří MAC se správným heslem a poté selže na tašce, takže heslo nikdy nebylo špatné a jeho opětovné napsání nic nezmění.

Přečtěte kontejner, aniž byste zapsali klíč

Požádejte sestavení OpenSSL na svém počítači, aby soubor analyzovalo a přečetlo bod, kde to vzdává. Prohlídka bez výstupního souboru nechá klíč zašifrovaný na disku, a to je jediný důvod, proč je tento krok bezpečný na sdíleném hostiteli.

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

U zastaralého balíku se správným heslem to vypíše atributy tašky a poté se zastaví s digital envelope routines::unsupported. Se špatným heslem dostanete Mac verify error: invalid password? dřív, než se přečte jakákoli taška. Obě zprávy ukazují opačným směrem, a to je přesně informace, kterou klient zamlčel.

Pokud jde o poruchu s nepodporovaným algoritmem, spusťte stejný příkaz znovu s přidaným -legacy a beze změny čehokoli jiného. Tento přepínač načte legacy poskytovatele jen pro tento proces. Nepřiměje klienta VPN analyzovat staré balíky, nesahá na systémovou kryptografickou politiku a je to měření, nikoli oprava, protože soubor se stejně musí nahradit.

Která chyba znamená kterou fázi

Krátká tabulka drží tři výsledky oddělené a formulace je důležitější než to, kde se dialog objevil.

Text jako not enough data nebo header too long nepatří do žádné z prvních dvou skupin. To je problém formátu: soubor DER přejmenovaný na .pem, kopie poškozená editorem, který přepsal konce řádků, nebo neúplné stažení. Porovnejte kontrolní součet s tím, který poslal vydavatel, než začnete zkoumat šifry.

Berte Mac verify error jen jako důkaz o heslu. Znamená, že MAC spočítaná z toho, co jste napsali, neodpovídá uložené hodnotě, což se stává při překlepu, při heslu uloženém v mezipaměti z dřívějšího importu nebo při souboru znovu exportovaném pod jiným heslem. Nic neříká o tom, zda jsou algoritmy uvnitř staré.

Sestavte balík, který klient opravdu otevře

Jakmile legacy parser potvrdí, že je soubor v pořádku, trvalým řešením je náhrada, jejíž algoritmy cílový klient podporuje: AES-256-CBC pro tašky s klíčem a certifikáty, PBKDF2 se SHA-256 pro odvození a SHA-256 pro MAC. Váš správce PKI to může exportovat ze stejného klíčového materiálu a certifikát uvnitř zůstane ten, kterému vaše servery už důvěřují.

Když musíte převádět lokálně, požádejte nástroj pkcs12, aby tašky znovu zapečetil, místo aby je nejprve vypsal. Udržte obě hesla mimo historii shellu tím, že je budete číst ze souboru.

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

Úspěšná konverze nic neříká o platnosti, použití klíče, shodě soukromého klíče ani o tom, zda server důvěřuje vydavatelskému řetězci. Přebalení je změna přepravy, ne obnova, a každá z těch věcí stále potřebuje vlastní kontrolu.

Přeskočte každý recept, který zapisuje nechráněný mezilehlý klíč nebo prázdné výstupní heslo jen proto, že klient pak soubor přijal. Čitelný balík se strženou ochranou je horší výsledek než porucha importu, se kterou jste začali.

Ověřte, že klient importoval soubor, který jste sestavili

Čistá analýza v terminálu dokazuje, že je kontejner platný. Nedokazuje, že ho klient vybral, protože zbylý profil může dál ukazovat na starý soubor a někteří klienti ukládají importovanou identitu pod jméno, které jste nezvolili.

Vypište identitu, kterou se chystáte importovat, a porovnejte ji s tím, co klient ukazuje ve svém zobrazení certifikátů.

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

Nejprve odstraňte zastaralou položku profilu, potom importujte. Pokud klient zaznamenává subjekt nebo otisk, který načetl, porovnejte ho s řádkem výše; pokud ukazuje jen přátelský název, zkontrolujte místo toho datum vypršení, protože to se s jiným certifikátem od stejného vydavatele plete obtížněji.

Reference PKCS12 uvádí zde použité volby poskytovatele, hesla a výstupu. Smyslem je držet legacy poskytovatele mimo prostředí klienta: měřte s ním, dodávejte bez něj a nechte soukromý klíč na disku chráněný.