Malnova P12 malsukcesas en OpenSSL 3: ĉu malĝusta pasvorto aŭ malnova ĉifro?

La importa dialogo prenas vian pasvorton, turniĝas momenton, kaj poste diras, ke ĝi ne povas legi la pakaĵon. Nenio en tiu mesaĝo diras al vi, ĉu vi mistajpis la pasfrazon aŭ ĉu la dosiero estis sigelita per ĉifro, kiun la kliento ne plu liveras. Tiuj estas malsamaj fiaskoj kun malsamaj riparoj, kaj la malĝusta elekto kondukas al malsuprengrado de la kliento, kiu nur prokrastas la decidon. Observi la stadion, kie la kliento haltas, apartigas ilin en proksimume unu minuto.

Kio okazas inter la dialogo kaj la atestila listo

Dosiero .p12 estas ujo, ne atestilo. Ene estas unu aŭ pluraj atestilaj sakoj kaj privata-ŝlosila sako ĉifrita per ŝlosilo derivita de via pasvorto, plus integreca kontrolo nomata MAC super la tuta dosiero. Malfermi ĝin signifas kontroli tiun MAC, malĉifri la ŝlosilsakon kaj kongruigi la atestilon kun la ŝlosilo, kiu eliras.

Pasvorta problemo aperas ĉe la MAC-stadio. Ĉifra problemo aperas poste, kiam la ŝlosilsako devas esti malpakaĵigita kaj la konstruaĵo, kiu tion faras, ne havas efektivigon por la algoritmo nomita en la dosiero.

La dua kazo estas ofta sur nunaj sistemoj, ĉar OpenSSL 3 translokigis grupon da malnovaj algoritmoj al laŭvola legacy-provizanto. Pakaĵoj eksportitaj de OpenSSL 1.x kutime sigelis la atestilojn per 40-bita RC2 kaj la privatan ŝlosilon per tri-ŝlosila Triple DES. Defaŭlta OpenSSL 3-konstruaĵo ankoraŭ kontrolas la MAC per via ĝusta pasvorto kaj poste fiaskas ĉe la sako, do la pasvorto neniam estis malĝusta kaj retajpi ĝin ŝanĝas nenion.

Legu la ujon sen skribi ŝlosilon eksteren

Petu la OpenSSL-konstruaĵon sur via propra maŝino analizi la dosieron kaj legi la punkton, kie ĝi rezignas. Inspektado sen eliga dosiero lasas la ŝlosilon ĉifrita sur la disko, kaj tio estas la sola kialo, kial ĉi tiu paŝo estas sekura sur dividita gastiganto.

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

Ĉe malnova pakaĵo kun la ĝusta pasvorto tio presas la atributojn de la sako kaj poste haltas per digital envelope routines::unsupported. Kun malĝusta pasvorto vi ricevas Mac verify error: invalid password? antaŭ ol iu ajn sako estas legata. La du mesaĝoj montras en kontraŭajn direktojn, kaj tio estas ĝuste la informo, kiun la kliento kaŝis.

Se la fiasko estas la ne-subtenata-algoritma, rulu la saman komandon denove kun -legacy aldonita kaj nenio alia ŝanĝita. Tiu flago ŝargas la legacy-provizanton nur por tiu unu procezo. Ĝi ne igas la VPN-klienton analizi malnovajn pakaĵojn, ĝi ne tuŝas la sistemvastan kriptopolitikon, kaj ĝi estas mezuro, ne riparo, ĉar la dosiero ankoraŭ devas esti anstataŭigita.

Kiu eraro signifas kiun stadion

Mallonga tabelo tenas la tri rezultojn apartaj, kaj la vortumo pli gravas ol kie la dialogo aperis.

Teksto kiel not enough data aŭ header too long apartenas al neniu el la du unuaj grupoj. Tio estas formata problemo: DER-dosiero renomita al .pem, kopio difektita de redaktilo, kiu reverkis liniajn finojn, aŭ nekompleta elŝuto. Komparu la kontrolsumon kun tiu, kiun la eldoninto sendis, antaŭ ol vi komencos rigardi ĉifrojn.

Traktu Mac verify error nur kiel pruvon pri la pasvorto. Ĝi signifas, ke la MAC kalkulita el tio, kion vi tajpis, ne kongruas kun la konservita valoro, kio okazas pro tajperaro, pro pasvorto kaŝmemorigita de pli frua importo, aŭ pro dosiero reeksportita sub alia pasfrazo. Ĝi diras nenion pri tio, ĉu la algoritmoj ene estas malnovaj.

Konstruu pakaĵon, kiun la kliento povas efektive malfermi

Post kiam la legacy-analizilo konfirmis, ke la dosiero estas sana, la daŭra solvo estas anstataŭaĵo, kies algoritmojn la cela kliento subtenas: AES-256-CBC por la ŝlosilaj kaj atestilaj sakoj, PBKDF2 kun SHA-256 por derivado, kaj SHA-256 por la MAC. Via PKI-administranto povas eksporti tion el la sama ŝlosilmaterialo, kaj la atestilo ene restas tiu, kiun viaj serviloj jam fidas.

Kiam vi devas konverti loke, petu la pkcs12-ilojn resigeli la sakojn anstataŭ unue elverŝi ilin. Tenu ambaŭ pasfrazojn ekster via ŝelhistorio legante ilin el dosiero.

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

Sukcesa konvertiĝo diras nenion pri limdato, ŝlosiluzo, la kongruo de la privata ŝlosilo aŭ ĉu la servilo fidas la eldonan ĉenon. Reenpakado estas transporta ŝanĝo, ne renovigo, kaj ĉiu el tiuj ankoraŭ bezonas sian propran kontrolon.

Preterlasu ĉiun recepton, kiu skribas neprotektitan interan ŝlosilon aŭ malplenan eligan pasvorton nur ĉar la kliento poste akceptis la dosieron. Legebla pakaĵo kun la protekto forigita estas pli malbona rezulto ol la importa fiasko, kun kiu vi komencis.

Konfirmu, ke la kliento importis la dosieron, kiun vi konstruis

Pura analizo en terminalo pruvas, ke la ujo estas valida. Ĝi ne pruvas, ke la kliento elektis ĝin, ĉar restinta profilo povas daŭre montri al la malnova dosiero, kaj iuj klientoj kaŝmemorigas importitan identecon sub nomo, kiun vi ne elektis.

Presu la identecon, kiun vi baldaŭ importos, kaj komparu ĝin kun tio, kion la kliento montras en sia atestila vido.

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

Unue forigu la malnoviĝintan profilan eron, poste importu. Se la kliento protokolas la subjekton aŭ fingrospuron, kiun ĝi ŝarĝis, kongruigu ĝin kun la supra linio; se ĝi montras nur amikan nomon, kontrolu anstataŭe la limdaton, ĉar tio estas pli malfacile konfuzebla kun alia atestilo de la sama eldoninto.

La PKCS12-referenco listigas la provizantajn, pasfrazajn kaj eligajn opciojn uzatajn ĉi tie. La celo estas teni la legacy-provizanton ekster la klienta medio: mezuru kun ĝi, liveru sen ĝi, kaj lasu la privatan ŝlosilon protektita sur la disko.