Lumang P12 bumagsak sa OpenSSL 3: maling password o lumang cipher?

Kinukuha ng import dialog ang password mo, umiikot sandali, at saka sinasabing hindi nito mabasa ang bundle. Walang sinasabi sa mensaheng iyon kung na-type mo nang mali ang passphrase o kung ang file ay na-seal gamit ang cipher na hindi na ibinibigay ng client. Iba ang mga pagkabigo na ito at iba ang mga pagwawasto, at ang maling pagpili ay humahantong sa downgrade ng client na nagpapaliban lang sa desisyon. Ang pagtingin sa yugtong hinihintuan ng client ay naghihiwalay sa kanila sa mga isang minuto.

Ano ang nangyayari sa pagitan ng dialog at listahan ng certificate

Ang .p12 na file ay isang container, hindi certificate. Sa loob ay may isa o higit pang bag ng certificate at isang bag ng pribadong key na naka-encrypt gamit ang key na hinango sa password mo, kasama ang integrity check na tinatawag na MAC sa buong file. Ang pagbukas nito ay nangangahulugan ng pag-verify ng MAC na iyon, pag-decrypt ng key bag at pagtutugma ng certificate sa key na lumalabas.

Dumadating ang problema sa password sa yugtong MAC. Dumadating ang problema sa cipher mamaya, kapag kailangang buksan ang key bag at ang build na gumagawa nito ay walang implementasyon ng algorithm na nakasaad sa file.

Karaniwan ang ikalawang kaso sa mga system ngayon dahil inilipat ng OpenSSL 3 ang isang grupo ng lumang algorithm sa opsyonal na legacy provider. Ang mga bundle na inilabas ng OpenSSL 1.x ay karaniwang nagse-seal ng mga certificate gamit ang 40-bit na RC2 at ng pribadong key gamit ang tatlong-key na Triple DES. Ang default na build ng OpenSSL 3 ay nagbe-verify pa rin ng MAC gamit ang tamang password at pagkatapos ay bumabagsak sa bag, kaya hindi kailanman mali ang password at walang nababago kapag muling nag-type.

Basahin ang container nang hindi nagsusulat ng key

Hilingin sa OpenSSL build sa sarili mong makina na i-parse ang file at basahin ang puntong sumusuko ito. Ang inspeksyon na walang output file ay iniiwan ang key na naka-encrypt sa disk, at iyon lang ang dahilan kung bakit ligtas ang hakbang na ito sa shared host.

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

Sa lumang bundle na may tamang password, ipinapakita nito ang mga attribute ng bag at pagkatapos ay humihinto gamit ang digital envelope routines::unsupported. Sa maling password makakakuha ka ng Mac verify error: invalid password? bago pa mabasa ang anumang bag. Ang dalawang mensahe ay tumuturo sa magkasalungat na direksyon, at iyon talaga ang impormasyong itinago ng client.

Kung ang pagkabigo ay ang sa hindi suportadong algorithm, patakbuhin muli ang parehong command na may idinagdag na -legacy at walang ibang binago. Ang flag na iyon ay naglo-load ng legacy provider para sa isang prosesong iyon lang. Hindi nito pinipilit ang VPN client na i-parse ang lumang bundle, hindi nito ginagalaw ang crypto policy ng buong system, at ito ay pagsukat at hindi pag-aayos, dahil kailangan pa ring palitan ang file.

Aling error ang aling yugto

Ang maikling talahanayan ay naghihiwalay sa tatlong resulta, at ang mga salita ay mas mahalaga kaysa sa kung saan lumitaw ang dialog.

Ang tekstong tulad ng not enough data o header too long ay hindi kabilang sa alinman sa unang dalawang grupo. Problema iyon sa format: isang DER file na pinangalanang .pem, isang kopyang nasira ng editor na nag-rewrite ng dulo ng linya, o hindi kumpletong download. Ihambing ang checksum sa ipinadala ng issuer bago ka magsimulang tumingin sa mga cipher.

Ituring ang Mac verify error bilang ebidensya tungkol sa password lamang. Ibig sabihin, ang MAC na kinakalkula mula sa na-type mo ay hindi tumutugma sa naka-store na halaga, na nangyayari sa typo, sa password na naka-cache mula sa naunang import, o sa file na muling inilabas sa ilalim ng ibang passphrase. Wala itong sinasabi tungkol sa kung luma na ang mga algorithm sa loob.

Bumuo ng bundle na kayang buksan ng client

Kapag nakumpirma ng legacy parser na maayos ang file, ang pangmatagalang solusyon ay kapalit na may mga algorithm na sinusuportahan ng target na client: AES-256-CBC para sa key at certificate bag, PBKDF2 na may SHA-256 para sa derivation, at SHA-256 para sa MAC. Maaaring i-export iyon ng iyong PKI administrator mula sa parehong key material, at ang certificate sa loob ay mananatiling ang pinagkakatiwalaan na ng iyong mga server.

Kapag kailangan mong mag-convert nang lokal, hilingin sa pkcs12 tool na i-seal muli ang mga bag sa halip na i-dump muna ang mga ito. Ilayo ang dalawang passphrase sa history ng shell mo sa pamamagitan ng pagbasa ng mga ito mula sa file.

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

Ang matagumpay na conversion ay walang sinasabi tungkol sa expiry, paggamit ng key, pagtutugma ng pribadong key, o kung pinagkakatiwalaan ng server ang issuing chain. Ang muling pagbabalot ay pagbabago sa transport, hindi renewal, at bawat isa sa mga iyon ay kailangan pa rin ng sariling check.

Laktawan ang anumang recipe na nagsusulat ng walang proteksyong intermediate key o walang laman na output password dahil lang tinanggap ng client ang file pagkatapos. Ang nababasang bundle na tinanggalan ng proteksyon ay mas masamang resulta kaysa sa import failure na sinimulan mo.

Kumpirmahin na na-import ng client ang file na ginawa mo

Ang malinis na parse sa terminal ay nagpapatunay na valid ang container. Hindi nito pinatutunayan na pinili ito ng client, dahil ang natirang profile ay maaaring patuloy na tumuturo sa lumang file, at ang ilang client ay nag-cache ng na-import na identity sa ilalim ng pangalang hindi mo pinili.

I-print ang identity na i-import mo at ihambing ito sa ipinapakita ng client sa certificate view nito.

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

Alisin muna ang lumang profile entry, pagkatapos ay i-import. Kung nila-log ng client ang subject o fingerprint na na-load, itugma ito sa linyang nasa itaas; kung friendly name lang ang ipinapakita, tingnan ang expiry date sa halip, dahil mas mahirap itong ipagkamali sa ibang certificate mula sa parehong issuer.

Ang PKCS12 reference ay naglilista ng provider, passphrase at output option na ginamit dito. Ang pag-iwan sa legacy provider sa labas ng client environment ang punto: sukatin kasama nito, ihatid nang wala ito, at iwanang protektado ang pribadong key sa disk.