Ang cert8.db ay hindi itatapong cache: tingnan ang may-ari ng imbakan

Isang lumang thread ng suporta ang nagsasabing burahin ang file na cert8.db at gumagana na muli ang VPN. Ang ganoong pagkakasunod-sunod ay mas madalas na pagkakataon kaysa pag-aayos. Ang file ay isang database ng sertipiko, at ang pag-alis nito ay nagbabago ng permanenteng kalagayang panseguridad sa paraang hindi isinisiwalat ng matagumpay na paglulunsad.

Ang nakapirming login ay hindi problema sa cache

Ang cache ng browser ay nag-iimbak ng mga kopya ng mapagkukunan; ang database ng sertipiko ay nag-iimbak ng mga desisyon sa pagtitiwala, sertipiko at ang mga susi na kasama ng mga ito. Ang pagbura ng pangalawa ay mas malapit sa pag-reset ng pagkakakilanlan kaysa sa paglilinis ng kasaysayan. Kung nag-freeze ang client habang nagla-log in, ang kapaki-pakinabang na ebidensya ay kung aling proseso ang nagbukas ng aling profile at ano ang naitala nito, hindi kung aling file ang inalis ng isang post sa forum. Ang paggawa muli ng pag-freeze at pagbasa ng log ng client ay mas matagal kaysa pagbura ng file, at iyon lamang ang tanging daan sa tunay na dahilan.

Ang pangalan ng file ay may dalang kasaysayan: pinag-iiba ng NSS ang lumang cert8.db at key3.db sa cert9.db at key4.db ng SQLite. Isulat ang linya ng log na nakita mo bago ang pag-freeze, dahil iyon lamang ang matibay na ebidensyang mayroon ka.

Aling profile ang talagang binubuksan ng client

Kilalanin ang client, ang paraan ng pagpapatunay nito at ang imbakan na binabasa nito. May tatlong landas ng login dito: tinutulungan ng browser, naka-embed na browser at native na client, at hindi nila kailangang magbahagi ng profile. Ang database na may tamang pangalan sa ibang direktoryo ay hindi patunay na binuksan ito ng nag-freeze na proseso. Sa Linux, ang imbakan ng NSS ay karaniwang nasa ilalim ng ~/.pki/nssdb ng gumagamit o sa direktoryo ng profile bawat aplikasyon. Maaaring magkasabay ang dalawang layout sa isang makina, kaya tingnan ang pareho kung bago ang migrasyon.

Ilista ang laman ng imbakan bago ito baguhin: ipiniprinta ng certutil -L -d sql:$HOME/.pki/nssdb ang mga sertipiko, at ang parehong tool na may -K ay nagpapakita kung may mga susi.

Kung iniuulat ng command na hindi mabuksan ang database, natagpuan mo ang profile na ginagamit ng tool, ngunit hindi kinakailangan ang ginamit ng VPN.

Gumawa ng backup ng profile bago ang anumang pag-aayos

Isara ang mga apektadong aplikasyon, pagkatapos kopyahin ang buong direktoryo ng profile gamit ang aprubadong paraan ng backup. Ang mga database ng sertipiko at susi ay magkaugnay ngunit magkahiwalay na kalagayan, at ang pag-save ng isang arbitraryong file ay hindi plano sa pagbawi para sa buong pagkakakilanlan. Protektahan ang kopya, dahil maaaring may pribadong susi ang profile. Itala kung ano at saan ka nag-backup, upang ang nabigong pag-aayos ay may daan pabalik.

Pagkatapos ay kumpirmahin ang eksaktong saklaw ng pag-aayos sa tagapangasiwa. Ang buong pag-reset ng imbakan, pag-alis ng isang kilalang lumang sertipiko at pag-aayos ng profile ng browser ay tatlong magkaibang pagbabago na may tatlong magkaibang panganib.

Pagkatapos ng pag-aayos, mag-log in at siyasatin ang imbakan

Pagkatapos ng awtorisadong pag-aayos, mag-log in sa VPN at kumpirmahin na ang sertipiko ng server ay binibigyang-bisa pa rin ayon sa layunin. Tingnan na naroon pa rin ang mga pagkakakilanlang kailangan ng workflow at walang hindi inaasahang angkla ng pagtitiwala na lumitaw. Ang pag-aayos na nagpapagana ng koneksyon sa pamamagitan ng mas malaking pagtitiwala kaysa dati ay hindi pag-aayos.

Paghiwalayin ang obserbasyon at tagubilin: ang isang pagbura at isang matagumpay na paglulunsad ay hindi pangkalahatang solusyon.

Kung bumalik ang pag-freeze, kunin ang log ng client at ang profile na ginagamit bago baguhin ang anupaman. Ang rekord na iyon ang nagpapalit ng haka sa diagnosis.