Gammal P12 feilar på OpenSSL 3: feil passord eller gammal chiffer?

Importdialogen tek passordet ditt, spinner eit augeblikk og seier så at han ikkje kan lese pakka. Ingenting i den meldinga fortel om du skreiv passfrasen feil, eller om fila vart forsegla med ein chiffer klienten ikkje lenger leverer. Dette er ulike feil med ulike løysingar, og eit feil val fører til ein nedgradering av klienten som berre utset avgjerda. Å sjå på kva trinn klienten stoppar skil dei på rundt eitt minutt.

Kva som skjer mellom dialogen og sertifikatlista

.p12-fila er ein behaldar, ikkje eit sertifikat. Inst inne ligg éin eller fleire sertifikatposar og ein privatnøkkelpose som er kryptert med ein nøkkel utleidd frå passordet ditt, pluss ein integritetssjekk som blir kalla MAC over heile fila. Å opne henne tyder å verifisere den MAC-en, dekryptere nøkkelposen og matche sertifikatet med nøkkelen som kjem ut.

Passordproblemet dukkar opp i MAC-trinnet. Chifferproblemet dukkar opp seinare, når nøkkelposen må pakkast ut og bygget som gjer det ikkje har nokon implementasjon av algoritmen som er namngjeven i fila.

Det andre tilfellet er vanleg på dagens system fordi OpenSSL 3 flytta ei gruppe gamle algoritmar til ein valfri legacy provider. Pakker eksporterte av OpenSSL 1.x forsegla vanlegvis sertifikata med 40-bits RC2 og privatnøkkelen med tre-nøkkels Triple DES. Eit standard OpenSSL 3-bygg verifiserer framleis MAC-en med rett passord og feilar så på posen, så passordet var aldri feil og å skrive det på nytt endrar ingenting.

Les behaldaren utan å skrive ut ein nøkkel

Be OpenSSL-bygget på di eiga maskin parse fila og lese punktet der det gir opp. Inspeksjon utan utdatafil let nøkkelen liggje kryptert på disk, og det er den einaste grunnen til at dette trinnet er trygt på ein delt vert.

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

På ei gammal pakke med rett passord skriv dette ut poseattributta og stoppar deretter med digital envelope routines::unsupported. Med feil passord får du Mac verify error: invalid password? før nokon pose blir lesen. Dei to meldingane peikar i motsette retningar, og det er nøyaktig informasjonen klienten heldt tilbake.

Viss feilen er den med algoritmen som ikkje blir støtta, køyr same kommandoen igjen med -legacy lagt til og ingenting anna endra. Det flagget lastar legacy provider berre for den eine prosessen. Det får ikkje VPN-klienten til å parse gamle pakker, det rører ikkje systemomfattande kryptopolitikk, og det er ei måling og ikkje ei reparasjon, fordi fila framleis må erstattast.

Kva feil som tyder kva trinn

Ein kort tabell held dei tre utfalla frå kvarandre, og ordlyden betyr meir enn kvar dialogen dukka opp.

Tekst som not enough data eller header too long høyrer ikkje til nokon av dei to første gruppene. Det er eit formatproblem: ei DER-fil som er døypt om til .pem, ein kopi øydelagd av ein editor som skreiv om linjeslutt, eller ei ufullstendig nedlasting. Samanlikn sjekksummen med den utsendararen sende før du byrjar å sjå på chiffrar.

Behandle Mac verify error berre som prov om passordet. Det tyder at MAC-en rekna ut frå det du skreiv inn ikkje stemmer med den lagra verdien, noko som skjer med ein skrivefeil, med eit passord bufra frå ein tidlegare import, eller med ei fil som er eksportert på nytt under ein annan passfrase. Det seier ingenting om algoritmane inni er gamle.

Bygg ein pakke klienten faktisk kan opne

Når legacy-parsaren stadfestar at fila er sunn, er den varige løysinga ei erstatning der algoritmane blir støtta av målklienten: AES-256-CBC for nøkkel- og sertifikatposane, PBKDF2 med SHA-256 for utleiing, og SHA-256 for MAC-en. PKI-administratoren din kan eksportere det frå same nøkkelmateriale, og sertifikatet inni blir verande det serverane dine allereie stolar på.

Når du må konvertere lokalt, be pkcs12-verktøyet forsegle posane på nytt i staden for å dumpe dei først. Hald båe passfrasane unna skalhistorikken din ved å lese dei frå ei 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

Ei vellukka konvertering seier ingenting om utløp, nøkkelbruk, privatnøkkelmatching eller om serveren stolar på utsendararen si kjede. Ompakking er ei endring i transport, ikkje ei fornying, og kvar av dei treng framleis si eiga sjekk.

Hopp over kvar oppskrift som skriv ein ubeskytta mellomliggande nøkkel eller eit tomt utdatapassord berre fordi klienten då godtok fila. Ei lesbar pakke med vernet fjerna er eit verre utfall enn importfeilen du starta med.

Stadfest at klienten importerte fila du bygde

Ein rein parse i eit terminalvindauge beviser at behaldaren er gyldig. Det beviser ikkje at klienten valde han, fordi ein profil som ligg att kan halde fram med å peike på den gamle fila, og nokre klientar bufrer ein importert identitet under eit namn du ikkje valde.

Skriv ut identiteten du er i ferd med å importere og samanlikn han med det klienten viser i sertifikatvisinga.

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

Fjern den gamle profiloppinga først, og importer deretter. Viss klienten loggar subjektet eller fingeravtrykket han lasta, match det mot linja ovanfor; viss han berre viser eit venleg namn, sjekk utløpsdatoen i staden, sidan han er vanskelegare å forveksle med eit anna sertifikat frå same utsendar.

PKCS12-referansen listar opp provideren, passfrasen og utdataalternativa som blir brukte her. Å halde legacy provider utanfor klientmiljøet er poenget: mål med han, lever utan, og lat privatnøkkelen vere verna på disk.