Gammal P12 misslyckas i OpenSSL 3: fel lösenord eller gammalt chiffer?

Importdialogen tar ditt lösenord, snurrar ett ögonblick och säger sedan att den inte kan läsa paketet. Inget i det meddelandet säger om du skrev lösenfrasen fel eller om filen förseglades med ett chiffer som klienten inte längre levererar. Det är olika fel med olika åtgärder, och ett felaktigt val leder till en nedgradering av klienten som bara skjuter upp beslutet. Att se efter i vilket steg klienten stannar skiljer dem åt på ungefär en minut.

Vad som händer mellan dialogen och certifikatlistan

En .p12-fil är en behållare, inte ett certifikat. Inuti finns en eller flera certifikatpåsar och en påse med privat nyckel som är krypterad med en nyckel som härletts från ditt lösenord, plus en integritetskontroll som kallas MAC över hela filen. Att öppna den innebär att verifiera den MAC:en, dekryptera nyckelpåsen och matcha certifikatet mot nyckeln som kommer ut.

Lösenordsproblemet dyker upp i MAC-steget. Chifferproblemet dyker upp senare, när nyckelpåsen måste packas upp och bygget som gör det inte har någon implementering av algoritmen som namnges i filen.

Det andra fallet är vanligt på dagens system eftersom OpenSSL 3 flyttade en grupp gamla algoritmer till en valfri legacy provider. Paket som exporterades av OpenSSL 1.x förseglade vanligtvis certifikaten med 40-bitars RC2 och den privata nyckeln med tre nycklars Triple DES. Ett standardbygge av OpenSSL 3 verifierar fortfarande MAC:en med ditt korrekta lösenord och misslyckas sedan på påsen, så lösenordet var aldrig fel och att skriva det igen ändrar inget.

Läs behållaren utan att skriva ut en nyckel

Be OpenSSL-bygget på din egen maskin att tolka filen och läsa punkten där det ger upp. Inspektion utan utdatafil lämnar nyckeln krypterad på disk, och det är den enda anledningen till att steget är säkert på en delad värd.

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

På ett gammalt paket med rätt lösenord skriver detta ut påsens attribut och stannar sedan med digital envelope routines::unsupported. Med fel lösenord får du Mac verify error: invalid password? innan någon påse läses. De två meddelandena pekar i motsatta riktningar, och det är exakt informationen som klienten höll tillbaka.

Om felet är det med den algoritm som inte stöds, kör samma kommando igen med -legacy tillagt och inget annat ändrat. Den flaggan laddar legacy provider bara för den enda processen. Den tvingar inte VPN-klienten att tolka gamla paket, den rör inte den systemövergripande kryptopolicyn, och den är en mätning och inte en reparation, eftersom filen ändå måste bytas ut.

Vilket fel betyder vilket steg

En kort tabell håller de tre utfallen isär, och formuleringen betyder mer än var dialogen dök upp.

Text som not enough data eller header too long hör inte till någon av de två första grupperna. Det är ett formatproblem: en DER-fil som döpts om till .pem, en kopia som skadats av en editor som skrev om radslut, eller en ofullständig nedladdning. Jämför kontrollsumman med den som utgivaren skickade innan du börjar titta på chiffren.

Behandla Mac verify error bara som bevis om lösenordet. Det betyder att MAC:en som beräknats från det du skrev inte stämmer med det lagrade värdet, vilket händer vid ett skrivfel, med ett lösenord som cachats från en tidigare import eller med en fil som exporterats om under en annan lösenfras. Det säger inget om huruvida algoritmerna inuti är gamla.

Bygg ett paket som klienten faktiskt kan öppna

När legacy-tolken bekräftar att filen är frisk är den varaktiga lösningen en ersättning vars algoritmer målklienten stöder: AES-256-CBC för nyckel- och certifikatpåsarna, PBKDF2 med SHA-256 för härledning och SHA-256 för MAC:en. Din PKI-administratör kan exportera det från samma nyckelmaterial, och certifikatet inuti förblir det som dina servrar redan litar på.

När du måste konvertera lokalt, be pkcs12-verktyget att försegla påsarna igen i stället för att dumpa dem först. Håll båda lösenfraserna borta från skalhistoriken genom att läsa dem från en fil.

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

En lyckad konvertering säger inget om utgång, nyckelanvändning, matchning av den privata nyckeln eller om servern litar på utgivarens kedja. Ompaketering är en transportändring, inte en förnyelse, och var och en av dem behöver fortfarande sin egen kontroll.

Hoppa över varje recept som skriver en oskyddad mellanliggande nyckel eller ett tomt utdatalösenord bara för att klienten sedan accepterade filen. Ett läsbart paket med skyddet borttaget är ett sämre utfall än importfelet du började med.

Bekräfta att klienten importerade filen du byggde

En ren tolkning i en terminal bevisar att behållaren är giltig. Det bevisar inte att klienten valde den, eftersom en kvarlämnad profil kan fortsätta peka på den gamla filen, och vissa klienter cachar en importerad identitet under ett namn du inte valde.

Skriv ut identiteten du ska importera och jämför den med vad klienten visar i certifikatvyn.

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

Ta bort den gamla profilposten först och importera sedan. Om klienten loggar subjektet eller fingeravtrycket den laddade, matcha det mot raden ovan; om den bara visar ett vänligt namn, kontrollera utgångsdatumet i stället, eftersom det är svårare att förväxla med ett annat certifikat från samma utgivare.

PKCS12-referensen listar providern, lösenfrasen och utdataalternativen som används här. Att hålla legacy provider utanför klientmiljön är poängen: mät med den, leverera utan, och låt den privata nyckeln vara skyddad på disk.