cert8.db എന്നത് വലിച്ചെറിയാവുന്ന കാഷ് അല്ല: സ്റ്റോറിന്റെ ഉടമയെ പരിശോധിക്കുക

പഴയ ഒരു സപ്പോർട്ട് ത്രെഡ് cert8.db എന്ന ഫയൽ ഇല്ലാതാക്കാൻ പറയുന്നു, പിന്നെ VPN വീണ്ടും പ്രവർത്തിക്കുന്നു. ആ ക്രമം പരിഹാരത്തേക്കാൾ കൂടുതലായി യാദൃച്ഛികതയാണ്. ഫയൽ ഒരു സർട്ടിഫിക്കറ്റ് ഡാറ്റാബേസ് ആണ്, അത് നീക്കം ചെയ്യുന്നത് വിജയകരമായ പ്രവർത്തനം കാണിക്കാത്ത രീതിയിൽ സ്ഥിരമായ സുരക്ഷാ നില മാറ്റുന്നു.

സ്തംഭിച്ച ലോഗിൻ കാഷ് പ്രശ്നമല്ല

ബ്രൗസർ കാഷ് വിഭവങ്ങളുടെ പകർപ്പുകൾ സൂക്ഷിക്കുന്നു; സർട്ടിഫിക്കറ്റ് ഡാറ്റാബേസ് വിശ്വാസ തീരുമാനങ്ങൾ, സർട്ടിഫിക്കറ്റുകൾ, അവയോട് ചേരുന്ന കീകൾ എന്നിവ സൂക്ഷിക്കുന്നു. രണ്ടാമത്തേത് ഇല്ലാതാക്കുന്നത് ചരിത്രം മായ്ക്കുന്നതിനേക്കാൾ ഐഡന്റിറ്റി പുനഃസജ്ജീകരിക്കുന്നതിനോട് അടുത്താണ്. സൈൻ-ഇൻ സമയത്ത് ക്ലയന്റ് സ്തംഭിച്ചെങ്കിൽ, ഉപയോഗപ്രദമായ തെളിവ് ഏത് പ്രോസസ് ഏത് പ്രൊഫൈൽ തുറന്നു, എന്ത് രേഖപ്പെടുത്തി എന്നതാണ്, ഫോറം പോസ്റ്റ് ഏത് ഫയൽ നീക്കി എന്നതല്ല. സ്തംഭനം ആവർത്തിച്ച് ക്ലയന്റ് ലോഗ് വായിക്കാൻ ഫയൽ ഇല്ലാതാക്കുന്നതിനേക്കാൾ സമയം എടുക്കും, എന്നാൽ യഥാർത്ഥ കാരണത്തിലേക്കുള്ള ഏക വഴി അതാണ്.

ഫയലിന്റെ പേരിൽ ചരിത്രവുമുണ്ട്: NSS പഴയ cert8.db, key3.db എന്നിവയെ SQLite അടിസ്ഥാനമാക്കിയ cert9.db, key4.db എന്നിവയിൽ നിന്ന് വേർതിരിക്കുന്നു. സ്തംഭനത്തിന് മുൻപ് കണ്ട ലോഗ് വരി എഴുതി സൂക്ഷിക്കുക, കാരണം അതാണ് നിങ്ങളുടെ കൈവശമുള്ള ഏക സ്ഥിരമായ തെളിവ്.

ക്ലയന്റ് യഥാർത്ഥത്തിൽ ഏത് പ്രൊഫൈൽ തുറക്കുന്നു

ക്ലയന്റ്, അതിന്റെ പ്രാമാണീകരണ രീതി, അത് വായിക്കുന്ന സ്റ്റോർ എന്നിവ തിരിച്ചറിയുക. ഇവിടെ സൈൻ-ഇന്നിന് മൂന്ന് വഴികളുണ്ട്: ബ്രൗസർ സഹായത്തോടെ, ഉൾച്ചേർത്ത ബ്രൗസർ, നേറ്റീവ് ക്ലയന്റ്, ഒരേ പ്രൊഫൈൽ പങ്കിടേണ്ടതില്ല. മറ്റൊരു ഡയറക്ടറിയിൽ ശരിയായ പേരുള്ള ഡാറ്റാബേസ് ഉണ്ടായിരിക്കുന്നത് സ്തംഭിച്ച പ്രോസസ് അത് തുറന്നു എന്നതിന് തെളിവല്ല. Linux ൽ NSS സ്റ്റോർ സാധാരണയായി ഉപയോക്താവിന്റെ ~/.pki/nssdb ക്ക് കീഴിലോ ഓരോ ആപ്പിന്റെയും പ്രൊഫൈൽ ഡയറക്ടറിയിലോ ആണ്. രണ്ട് ക്രമീകരണങ്ങളും ഒരേ യന്ത്രത്തിൽ നിലനിൽക്കാം, അതിനാൽ മൈഗ്രേഷൻ സമീപകാലത്താണെങ്കിൽ രണ്ടും പരിശോധിക്കുക.

മാറ്റുന്നതിന് മുൻപ് സ്റ്റോറിൽ എന്തുണ്ടെന്ന് പട്ടികപ്പെടുത്തുക: certutil -L -d sql:$HOME/.pki/nssdb സർട്ടിഫിക്കറ്റുകൾ അച്ചടിക്കുന്നു, അതേ ഉപകരണം -K സഹിതം കീകൾ ഉണ്ടോ എന്ന് കാണിക്കുന്നു.

ഡാറ്റാബേസ് തുറക്കാനാവില്ലെന്ന് കമാൻഡ് റിപ്പോർട്ട് ചെയ്താൽ, ഉപകരണം ഉപയോഗിക്കുന്ന പ്രൊഫൈൽ കണ്ടെത്തി, പക്ഷേ VPN ഉപയോഗിച്ചത് അതുതന്നെയെന്ന് ഉറപ്പില്ല.

ഏതെങ്കിലും പരിഹാരത്തിന് മുൻപ് പ്രൊഫൈൽ ബാക്കപ്പ് എടുക്കുക

ബാധിത ആപ്പുകൾ അടച്ച്, അനുവദിച്ച ബാക്കപ്പ് രീതിയിൽ മുഴുവൻ പ്രൊഫൈൽ ഡയറക്ടറിയും പകർത്തുക. സർട്ടിഫിക്കറ്റ്, കീ ഡാറ്റാബേസുകൾ ബന്ധപ്പെട്ടതെങ്കിലും വേറിട്ട നിലയാണ്, ഒരു ഏകപക്ഷീയ ഫയൽ സൂക്ഷിക്കുന്നത് മുഴുവൻ ഐഡന്റിറ്റിക്കും വീണ്ടെടുക്കൽ പദ്ധതിയല്ല. പകർപ്പ് സംരക്ഷിക്കുക, പ്രൊഫൈലിൽ സ്വകാര്യ കീകൾ ഉണ്ടാകാം. എന്ത്, എവിടെ ബാക്കപ്പ് ചെയ്തു എന്ന് രേഖപ്പെടുത്തുക, പരാജയപ്പെട്ട പരിഹാരത്തിന് മടങ്ങാനുള്ള വഴിയുണ്ടാകാൻ.

പിന്നെ പരിഹാരത്തിന്റെ കൃത്യമായ പരിധി പരിപാലകനുമായി സ്ഥിരീകരിക്കുക. മുഴുവൻ സ്റ്റോറും പുനഃസജ്ജീകരിക്കുക, അറിയപ്പെടുന്ന ഒരു പഴയ സർട്ടിഫിക്കറ്റ് നീക്കുക, ബ്രൗസർ പ്രൊഫൈൽ പരിഹരിക്കുക എന്നിവ മൂന്ന് വ്യത്യസ്ത മാറ്റങ്ങളാണ്, മൂന്ന് വ്യത്യസ്ത അപകടസാധ്യതകളോടെ.

പരിഹാരത്തിന് ശേഷം സൈൻ ഇൻ ചെയ്ത് സ്റ്റോർ പരിശോധിക്കുക

അനുവദിച്ച പരിഹാരത്തിന് ശേഷം VPN ലേക്ക് സൈൻ ഇൻ ചെയ്ത് സർവർ സർട്ടിഫിക്കറ്റ് ഇപ്പോഴും ഉദ്ദേശിച്ചപോലെ സാധൂകരിക്കുന്നുണ്ടെന്ന് ഉറപ്പാക്കുക. വർക്ക്ഫ്ലോയ്ക്ക് ആവശ്യമായ ഐഡന്റിറ്റികൾ ഇപ്പോഴുമുണ്ടെന്നും അപ്രതീക്ഷിതമായ വിശ്വാസ ആങ്കർ പ്രത്യക്ഷപ്പെട്ടിട്ടില്ലെന്നും പരിശോധിക്കുക. മുൻപിനേക്കാൾ കൂടുതൽ വിശ്വസിച്ച് ബന്ധം പ്രവർത്തിപ്പിക്കുന്ന പരിഹാരം പരിഹാരമല്ല.

നിരീക്ഷണവും നിർദ്ദേശവും വേർതിരിച്ച് സൂക്ഷിക്കുക: ഒരു ഇല്ലാതാക്കലും ഒരു വിജയകരമായ പ്രവർത്തനവും പൊതുവായ പരിഹാരമല്ല.

സ്തംഭനം മടങ്ങിയെത്തിയാൽ, മറ്റെന്തെങ്കിലും മാറ്റുന്നതിന് മുൻപ് ക്ലയന്റ് ലോഗും ഉപയോഗത്തിലുള്ള പ്രൊഫൈലും പകർത്തുക. ആ രേഖയാണ് ഊഹത്തെ രോഗനിർണയമാക്കി മാറ്റുന്നത്.