Gammel P12 feiler på OpenSSL 3: feil passord eller gammel chiffer?

Importdialogen tar passordet ditt, spinner et øyeblikk og sier så at den ikke kan lese pakken. Ingenting i den meldingen forteller om du skrev passfrasen feil, eller om filen ble forseglet med en chiffer klienten ikke lenger leverer. Dette er forskjellige feil med forskjellige løsninger, og feil valg fører til en nedgradering av klienten som bare utsetter avgjørelsen. Å se på hvilket trinn klienten stopper skiller dem på rundt et minutt.

Hva som skjer mellom dialogen og sertifikatlisten

.p12-filen er en beholder, ikke et sertifikat. Inni ligger én eller flere sertifikatposer og en privatnøkkelpose som er kryptert med en nøkkel utledet fra passordet ditt, pluss en integritetssjekk som kalles MAC over hele filen. Å åpne den betyr å verifisere den MAC-en, dekryptere nøkkelposen og matche sertifikatet med nøkkelen som kommer ut.

Passordproblemet dukker opp i MAC-trinnet. Chifferproblemet dukker opp senere, når nøkkelposen må pakkes ut og bygget som gjør det ikke har noen implementasjon av algoritmen som er navngitt i filen.

Det andre tilfellet er vanlig på dagens systemer fordi OpenSSL 3 flyttet en gruppe gamle algoritmer til en valgfri legacy provider. Pakker eksportert av OpenSSL 1.x forseglet vanligvis sertifikatene med 40-bits RC2 og privatnøkkelen med tre-nøkkels Triple DES. Et standard OpenSSL 3-bygg verifiserer fortsatt MAC-en med riktig passord og feiler så på posen, så passordet var aldri feil og å skrive det på nytt endrer ingenting.

Les beholderen uten å skrive ut en nøkkel

Be OpenSSL-bygget på din egen maskin parse filen og lese punktet der den gir opp. Inspeksjon uten utdatafil lar nøkkelen ligge kryptert på disk, og det er den eneste grunnen til at dette trinnet er trygt på en delt vert.

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

På en gammel pakke med riktig passord skriver dette ut posens attributter og stopper deretter med digital envelope routines::unsupported. Med feil passord får du Mac verify error: invalid password? før noen pose leses. De to meldingene peker i motsatte retninger, og det er nøyaktig informasjonen klienten holdt tilbake.

Hvis feilen er den med algoritmen som ikke støttes, kjør samme kommando igjen med -legacy lagt til og ingenting annet endret. Det flagget laster legacy provider bare for den ene prosessen. Det får ikke VPN-klienten til å parse gamle pakker, det rører ikke systemomfattende kryptopolitikk, og det er en måling og ikke en reparasjon, fordi filen fortsatt må erstattes.

Hvilken feil betyr hvilket trinn

En kort tabell holder de tre utfallene fra hverandre, og ordlyden betyr mer enn hvor dialogen dukket opp.

Tekst som not enough data eller header too long hører ikke til noen av de to første gruppene. Det er et formatproblem: en DER-fil som er omdøpt til .pem, en kopi ødelagt av en editor som skrev om linjeslutt, eller en ufullstendig nedlasting. Sammenlign sjekksummen med den utstederen sendte før du begynner å se på chiffere.

Behandle Mac verify error bare som bevis om passordet. Det betyr at MAC-en beregnet fra det du skrev inn ikke stemmer med den lagrede verdien, noe som skjer med en skrivefeil, med et passord bufret fra en tidligere import, eller med en fil som er eksportert på nytt under en annen passfrase. Det sier ingenting om hvorvidt algoritmene inni er gamle.

Bygg en pakke klienten faktisk kan åpne

Når legacy-parseren bekrefter at filen er sunn, er den varige løsningen en erstatning der algoritmene støttes av målklienten: AES-256-CBC for nøkkel- og sertifikatposene, PBKDF2 med SHA-256 for utledning, og SHA-256 for MAC-en. PKI-administratoren din kan eksportere det fra samme nøkkelmateriale, og sertifikatet inni forblir det serverne dine allerede stoler på.

Når du må konvertere lokalt, be pkcs12-verktøyet forsegle posene på nytt i stedet for å dumpe dem først. Hold begge passfrasene unna skallhistorikken din ved å lese dem fra 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 vellykket konvertering sier ingenting om utløp, nøkkelbruk, privatnøkkelmatching eller om serveren stoler på utstederkjeden. Ompakking er en endring i transport, ikke en fornyelse, og hver av dem trenger fortsatt sin egen sjekk.

Hopp over enhver oppskrift som skriver en ubeskyttet mellomliggende nøkkel eller et tomt utdatapassord bare fordi klienten da godtok filen. En lesbar pakke med beskyttelsen fjernet er et verre utfall enn importfeilen du startet med.

Bekreft at klienten importerte filen du bygde

En ren parse i et terminalvindu beviser at beholderen er gyldig. Det beviser ikke at klienten valgte den, fordi en profil som ligger igjen kan fortsette å peke på den gamle filen, og noen klienter bufrer en importert identitet under et navn du ikke valgte.

Skriv ut identiteten du er i ferd med å importere og sammenlign den med det klienten viser i sertifikatvisningen.

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

Fjern den gamle profiloppføringen først, og importer deretter. Hvis klienten logger subjektet eller fingeravtrykket den lastet, match det mot linjen ovenfor; hvis den bare viser et vennlig navn, sjekk utløpsdatoen i stedet, siden den er vanskeligere å forveksle med et annet sertifikat fra samme utsteder.

PKCS12-referansen lister opp provideren, passfrasen og utdataalternativene som brukes her. Å holde legacy provider utenfor klientmiljøet er poenget: mål med den, lever uten, og la privatnøkkelen være beskyttet på disk.