P12 ya zamani inashindwa kwenye OpenSSL 3: nenosiri baya au sifa ya siri ya zamani?

Kidirisha cha kuagiza kinachukua nenosiri lako, kinazunguka kwa muda mfupi kisha kinasema hakiwezi kusoma kifurushi. Hakuna kitu katika ujumbe huo kinachosema kama uliandika nenosiri vibaya au kama faili ilitiwa muhuri na sifa ya siri ambayo mteja haitoi tena. Hizi ni hitilafu tofauti na marekebisho tofauti, na chaguo baya huleta kupunguzwa kwa toleo la mteja kunakochelewesha uamuzi tu. Kuangalia hatua ambayo mteja huacha huwatenganisha kwa takriban dakika moja.

Kinachotokea kati ya kidirisha na orodha ya vyeti

Faili ya .p12 ni chombo, si cheti. Ndani yake kuna mfuko mmoja au zaidi wa vyeti na mfuko wa ufunguo wa faragha uliosimbwa kwa ufunguo uliotokana na nenosiri lako, pamoja na ukaguzi wa uadilifu unaoitwa MAC juu ya faili yote. Kuifungua kunamaanisha kuthibitisha MAC hiyo, kusimbua mfuko wa ufunguo na kuoanisha cheti na ufunguo unaotoka.

Tatizo la nenosiri huja katika hatua ya MAC. Tatizo la sifa ya siri huja baadaye, wakati mfuko wa ufunguo unapaswa kufunguliwa na ujenzi unaofanya hivyo hauna utekelezaji wa algoriti iliyotajwa kwenye faili.

Kesi ya pili ni ya kawaida kwenye mifumo ya leo kwa sababu OpenSSL 3 ilihamisha kundi la algoriti za zamani kwenye legacy provider ya hiari. Vifurushi vilivyosafirishwa na OpenSSL 1.x kwa kawaida vilitia muhuri vyeti kwa RC2 ya biti 40 na ufunguo wa faragha kwa Triple DES ya funguo tatu. Ujenzi chaguo-msingi wa OpenSSL 3 bado huthibitisha MAC kwa nenosiri lako sahihi kisha hushindwa kwenye mfuko, kwa hivyo nenosiri halikuwa baya kamwe na kuandika tena hakubadilishi chochote.

Soma chombo bila kuandika ufunguo nje

Muulize ujenzi wa OpenSSL kwenye mashine yako kuchanganua faili na kusoma mahali inapokata tamaa. Ukaguzi bila faili ya matokeo huacha ufunguo umesimbwa kwenye diski, na hiyo ndiyo sababu pekee hatua hii ni salama kwenye mwenyeji unaoshirikiwa.

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

Kwenye kifurushi cha zamani chenye nenosiri sahihi hii huchapisha sifa za mfuko kisha husimama na digital envelope routines::unsupported. Kwa nenosiri baya unapata Mac verify error: invalid password? kabla mfuko wowote kusomwa. Ujumbe hizi mbili zinaelekeza pande tofauti, na hiyo ndiyo taarifa ambayo mteja aliificha.

Ikiwa hitilafu ni ile ya algoriti isiyotumika, endesha amri hiyo hiyo tena ukiongeza -legacy na hakuna kingine kilichobadilishwa. Bendera hiyo hupakia legacy provider kwa mchakato huo mmoja tu. Haifanyi mteja wa VPN kuchanganua vifurushi vya zamani, haigusi sera ya kripto ya mfumo mzima, na ni kipimo si ukarabati, kwa sababu faili bado inapaswa kubadilishwa.

Hitilafu ipi inamaanisha hatua ipi

Jedwali fupi hutenganisha matokeo matatu, na maneno ni muhimu zaidi kuliko mahali kidirisha kilipotokea.

Maandishi kama not enough data au header too long hayako kwenye kundi lolote la kwanza mawili. Hili ni tatizo la muundo: faili ya DER iliyopewa jina .pem, nakala iliyoharibiwa na kihariri kilichoandika tena miisho ya mistari, au upakuaji usiokamilika. Linganisha checksum na ile iliyotumwa na mtoaji kabla ya kuanza kuangalia sifa za siri.

Chukulia Mac verify error kama ushahidi kuhusu nenosiri pekee. Inamaanisha MAC iliyohesabiwa kutoka ulichoandika hailingani na thamani iliyohifadhiwa, jambo linalotokea kwa makosa ya kuandika, nenosiri lililohifadhiwa kwa cache kutoka uagizaji wa awali, au faili iliyosafirishwa tena chini ya nenosiri lingine. Haisemi chochote kuhusu kama algoriti zilizo ndani ni za zamani.

Jenga kifurushi ambacho mteja anaweza kukifungua kweli

Mara kichanganuzi cha legacy kinapothibitisha faili ni nzuri, suluhisho la kudumu ni badala yenye algoriti ambazo mteja lengwa anaunga mkono: AES-256-CBC kwa mifuko ya ufunguo na vyeti, PBKDF2 na SHA-256 kwa utohozi na SHA-256 kwa MAC. Msimamizi wako wa PKI anaweza kuisafirisha kutoka nyenzo hiyo hiyo ya ufunguo, na cheti kilicho ndani kinabaki kile ambacho seva zako tayari zinaamini.

Unapolazimika kubadilisha kienyeji, muulize zana ya pkcs12 kutia mihuri mifuko tena badala ya kuimwaga kwanza. Weka nenosiri zote mbili mbali na historia ya shell yako kwa kuzisoma kutoka faili.

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

Ubadilishaji uliofanikiwa hausemi chochote kuhusu kuisha muda, matumizi ya ufunguo, ulinganifu wa ufunguo wa faragha au kama seva inaamini mnyororo wa mtoaji. Kufunga upya ni mabadiliko ya usafirishaji, si ukarabati wa muda, na kila kimoja bado kinahitaji ukaguzi wake.

Ruka mapishi yoyote yanayoandika ufunguo wa kati usiolindwa au nenosiri la matokeo tupu kwa sababu tu mteja alikubali faili baadaye. Kifurushi kinachosomeka kilichoondolewa ulinzi ni matokeo mabaya kuliko hitilafu ya uagizaji uliyoanza nayo.

Thibitisha kuwa mteja aliagiza faili ulilojenga

Uchanganuzi safi kwenye terminal huthibitisha chombo ni halali. Hauthibitishi kuwa mteja alikichagua, kwa sababu wasifu uliobaki unaweza kuendelea kuelekeza kwenye faili ya zamani, na baadhi ya wateja huhifadhi utambulisho ulioagizwa chini ya jina usilolichagua.

Chapisha utambulisho unaokaribia kuagiza na ulinganishe na kile mteja anachoonyesha kwenye mwonekano wa vyeti.

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

Ondoa kwanza ingizo la wasifu lililopitwa na wakati, kisha agiza. Ikiwa mteja anaandika kwenye kumbukumbu somo au alama ya kidole aliyopakia, linganisha na mstari ulio juu; ikiwa anaonyesha jina la kirafiki pekee, kagua tarehe ya kuisha badala yake, kwa sababu ni vigumu kuichanganya na cheti kingine cha mtoaji yule yule.

Marejeo ya PKCS12 yanaorodhesha provider, nenosiri na chaguo za matokeo zinazotumika hapa. Kuweka legacy provider nje ya mazingira ya mteja ndio hoja: pima nayo, safirisha bila yeye, na uache ufunguo wa faragha ukilindwa kwenye diski.