P12 i vjetër dështon në OpenSSL 3: fjalëkalim i gabuar apo shifër e vjetër?

Dialogu i importimit merr fjalëkalimin tuaj, rrotullohet për një çast dhe më pas thotë se nuk mund ta lexojë paketën. Asgjë në atë mesazh nuk ju thotë nëse e shtypët gabim frazëkalimin apo nëse skedari u vulos me një shifër që klienti nuk e ofron më. Këto janë dështime të ndryshme me rregullime të ndryshme, dhe zgjedhja e gabuar çon në një ulje të versionit të klientit që vetëm e shtyn vendimin. Vëzhgimi i fazës ku klienti ndalon i ndan ato për rreth një minute.

Çfarë ndodh midis dialogut dhe listës së certifikatave

Skedari .p12 është një kontejner, jo një certifikatë. Brenda ka një ose më shumë qese certifikatash dhe një qese çelësi privat të kriptuar me një çelës të nxjerrë nga fjalëkalimi juaj, plus një kontroll integriteti të quajtur MAC mbi të gjithë skedarin. Ta hapësh do të thotë të verifikosh atë MAC, të dekriptosh qesen e çelësit dhe të përputhësh certifikatën me çelësin që del.

Problemi i fjalëkalimit shfaqet në fazën MAC. Problemi i shifrës shfaqet më vonë, kur qesja e çelësit duhet të shpaketohet dhe ndërtimi që e bën këtë nuk ka implementim për algoritmin e emërtuar në skedar.

Rasti i dytë është i zakonshëm në sistemet e sotme sepse OpenSSL 3 zhvendosi një grup algoritmesh të vjetër në një legacy provider opsional. Paketat e eksportuara nga OpenSSL 1.x zakonisht i vulosnin certifikatat me RC2 40-bit dhe çelësin privat me Triple DES me tre çelësa. Ndërtimi i paracaktuar i OpenSSL 3 ende verifikon MAC me fjalëkalimin tuaj të saktë dhe më pas dështon në qese, prandaj fjalëkalimi nuk ishte kurrë i gabuar dhe shtypja përsëri nuk ndryshon asgjë.

Lexoni kontejnerin pa shkruar një çelës

Kërkojini ndërtimit të OpenSSL në makinën tuaj ta analizojë skedarin dhe të lexojë pikën ku dorëzohet. Inspektimi pa skedar dalës e lë çelësin të kriptuar në disk, dhe kjo është e vetmja arsye pse ky hap është i sigurt në një host të ndarë.

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

Në një paketë të vjetër me fjalëkalimin e saktë kjo shtyp atributet e qeses dhe më pas ndalon me digital envelope routines::unsupported. Me fjalëkalim të gabuar merrni Mac verify error: invalid password? përpara se të lexohet ndonjë qese. Të dy mesazhet tregojnë drejtime të kundërta, dhe pikërisht ky është informacioni që klienti e mbajti të fshehur.

Nëse dështimi është ai i algoritmit të pambështetur, ekzekutoni të njëjtin komandë përsëri me -legacy të shtuar dhe asgjë tjetër të ndryshuar. Ai flamur ngarkon legacy provider vetëm për atë proces të vetëm. Nuk e detyron klientin VPN të analizojë paketa të vjetra, nuk prek politikën kriptografike të sistemit, dhe është matje e jo rregullim, sepse skedari gjithsesi duhet zëvendësuar.

Cila gabim tregon cilën fazë

Një tabelë e shkurtër i mban tre rezultatet të ndara, dhe formulimi ka më shumë rëndësi sesa vendi ku u shfaq dialogu.

Tekst si not enough data ose header too long nuk i përket asnjërës prej dy grupeve të para. Ky është problem formati: një skedar DER i riemërtuar në .pem, një kopje e dëmtuar nga një redaktues që rishkroi fundet e rreshtave, ose një shkarkim i paplotë. Krahasoni checksum-in me atë që dërgoi lëshuesi përpara se të shikoni shifrat.

Trajtoni Mac verify error vetëm si provë për fjalëkalimin. Do të thotë që MAC i llogaritur nga ajo që shtypët nuk përputhet me vlerën e ruajtur, gjë që ndodh me një gabim shtypi, me një fjalëkalim të ruajtur në cache nga një import i mëparshëm, ose me një skedar të rieksportuar nën një frazëkalim tjetër. Nuk thotë asgjë për atë nëse algoritmet brenda janë të vjetra.

Ndërtoni një paketë që klienti vërtet mund ta hapë

Pasi analizuesi legacy konfirmon se skedari është i shëndoshë, zgjidhja e qëndrueshme është një zëvendësim me algoritme që klienti i synuar mbështet: AES-256-CBC për qeset e çelësit dhe certifikatave, PBKDF2 me SHA-256 për nxjerrjen dhe SHA-256 për MAC. Administratori juaj i PKI mund ta eksportojë atë nga i njëjti material çelësi, dhe certifikata brenda mbetet ajo që serverat tuaj tashmë i besojnë.

Kur duhet të konvertoni lokalisht, kërkojini mjetit pkcs12 t'i rivulosë qeset në vend që t'i hedhë fillimisht. Mbajini të dy frazëkalimet jashtë historikut të shell-it duke i lexuar nga një skedar.

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

Një konvertim i suksesshëm nuk thotë asgjë për skadimin, përdorimin e çelësit, përputhjen e çelësit privat ose nëse serveri beson zinxhirin e lëshuesit. Ripaketimi është një ndryshim transporti, jo një rinovim, dhe secili prej tyre ende kërkon kontrollin e vet.

Anashkaloni çdo recetë që shkruan një çelës të ndërmjetëm të pambrojtur ose një fjalëkalim dalës bosh vetëm sepse klienti pastaj e pranoi skedarin. Një paketë e lexueshme me mbrojtjen e hequr është një rezultat më i keq sesa dështimi i importimit me të cilin filluat.

Konfirmoni që klienti importoi skedarin që ndërtuat

Një analizim i pastër në terminal provon që kontejneri është i vlefshëm. Nuk provon që klienti e zgjodhi, sepse një profil i mbetur mund të vazhdojë të tregojë skedarin e vjetër, dhe disa klientë e ruajnë identitetin e importuar nën një emër që nuk e zgjodhët.

Shtypni identitetin që do të importoni dhe krahasoni atë me atë që klienti tregon në pamjen e certifikatave.

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

Hiqni fillimisht zërin e vjetër të profilit, pastaj importoni. Nëse klienti regjistron subjektin ose gjurmën e gishtit që ngarkoi, përputheni me rreshtin më sipër; nëse tregon vetëm një emër miqësor, kontrolloni në vend të tij datën e skadimit, sepse është më e vështirë të ngatërrohet me një certifikatë tjetër të të njëjtit lëshues.

Referenca PKCS12 rendit provider-in, frazëkalimin dhe opsionet e daljes të përdorura këtu. Mbajtja e legacy provider jashtë mjedisit të klientit është pika: matni me të, dorëzoni pa të, dhe lëreni çelësin privat të mbrojtur në disk.