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 ಗೆ ಸೈನ್ ಇನ್ ಮಾಡಿ ಮತ್ತು ಸರ್ವರ್ ಪ್ರಮಾಣಪತ್ರ ಇನ್ನೂ ಉದ್ದೇಶಿಸಿದಂತೆ ಮಾನ್ಯವಾಗುತ್ತಿದೆ ಎಂದು ದೃಢೀಕರಿಸಿ. ವರ್ಕ್‌ಫ್ಲೋಗೆ ಬೇಕಾದ ಗುರುತುಗಳು ಇನ್ನೂ ಇವೆ ಮತ್ತು ಅನಿರೀಕ್ಷಿತ ನಂಬಿಕೆ ಆಧಾರ ಕಾಣಿಸಿಲ್ಲ ಎಂದು ಪರಿಶೀಲಿಸಿ. ಹಿಂದಿನದಕ್ಕಿಂತ ಹೆಚ್ಚು ನಂಬಿ ಸಂಪರ್ಕ ಕೆಲಸ ಮಾಡಿಸುವ ಸರಿಪಡಿಸುವಿಕೆ ಸರಿಪಡಿಸುವಿಕೆ ಅಲ್ಲ.

ವೀಕ್ಷಣೆ ಮತ್ತು ಸೂಚನೆಯನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿಡಿ: ಒಂದು ಅಳಿಸುವಿಕೆ ಮತ್ತು ಒಂದು ಯಶಸ್ವಿ ಪ್ರಾರಂಭ ಸಾಮಾನ್ಯ ಪರಿಹಾರವಲ್ಲ.

ಸ್ತಬ್ಧತೆ ಮರಳಿದರೆ, ಬೇರೆ ಏನನ್ನೂ ಬದಲಿಸುವ ಮೊದಲು ಕ್ಲೈಂಟ್ ಲಾಗ್ ಮತ್ತು ಬಳಸುತ್ತಿರುವ ಪ್ರೊಫೈಲ್ ಸೆರೆಹಿಡಿಯಿರಿ. ಆ ದಾಖಲೆಯೇ ಊಹೆಯನ್ನು ರೋಗನಿರ್ಣಯವಾಗಿ ಬದಲಿಸುತ್ತದೆ.