cert8.db אינו מטמון חד־פעמי: בדקו מי הבעלים של המאגר
מחיקת cert8.db משנה מצב אבטחה מתמשך, לא מטמון עמוד. אתרו את הפרופיל שהלקוח פותח, גבו אותו, ותקנו רק את מה שאושר.
שרשור תמיכה ישן אומר למחוק קובץ בשם cert8.db והלא VPN מתחיל לעבוד. הרצף הזה הוא לעתים קרובות יותר צירוף מקרים מאשר תיקון. הקובץ הוא מסד נתונים של תעודות, והסרתו משנה מצב אבטחה מתמשך בדרכים שהפעלה מוצלחת אינה מגלה.
התחברות קפואה אינה בעיית מטמון
מטמון דפדפן שומר עותקים של משאבים; מסד נתונים של תעודות שומר החלטות אמון, תעודות והמפתחות הנלווים. מחיקת השנייה קרובה יותר לאיפוס זהות מאשר לניקוי היסטוריה. אם הלקוח קפא בזמן ההתחברות, הראיה המועילה היא איזה תהליך פתח איזה פרופיל ומה הוא תיעד, ולא איזה קובץ פוסט בפורום הסיר. שחזור הקפיאה וקריאת יומן הלקוח אורכים יותר ממחיקת קובץ, וזו הדרך היחידה לסיבה אמיתית.
שם הקובץ נושא גם היסטוריה: NSS מבדיל בין cert8.db ו-key3.db הישנים לבין cert9.db ו-key4.db של SQLite. רשמו את שורת היומן שראיתם לפני הקפיאה, כי היא הראיה העמידה היחידה שיש לכם.
איזה פרופיל הלקוח באמת פותח
זהו את הלקוח, את שיטת האימות ואת המאגר שהוא קורא. קיימות כאן שלוש דרכי התחברות: בעזרת דפדפן, דפדפן מוטמע ולקוח מקורי, והן אינן חייבות לחלוק פרופיל. מסד נתונים בשם הנכון בספרייה אחרת אינו הוכחה שהתהליך הקפוא פתח אותו. ב-Linux מאגר NSS נמצא בדרך כלל תחת ~/.pki/nssdb של המשתמש או בספריית פרופיל לפי יישום. שתי הפריסות יכולות להתקיים יחד באותה מכונה, לכן בדקו את שתיהן אם ההעברה לאחרונה.
פרטו מה יש במאגר לפני שינוי: certutil -L -d sql:$HOME/.pki/nssdb מדפיס את התעודות, ואותו כלי עם -K מראה אם קיימים מפתחות.
אם הפקודה מדווחת שלא ניתן לפתוח את מסד הנתונים, מצאתם את הפרופיל שהכלי משתמש בו, לא בהכרח זה שה-VPN השתמש בו.
גבו את הפרופיל לפני כל תיקון
סגרו את היישומים המושפעים, ואז העתיקו את כל ספריית הפרופיל בשיטת הגיבוי המאושרת. מסדי נתונים של תעודות ומפתחות הם מצב קשור אך נפרד, ושמירת קובץ שרירותי אחד אינה תוכנית שחזור לכל הזהות. הגנו על העותק, כי הפרופיל עשוי להכיל מפתחות פרטיים. רשמו מה גיביתם והיכן, כדי שתיקון כושל יהיה לו דרך חזרה.
אחר כך אשרו את היקף התיקון המדויק עם המתחזק. איפוס מלא של המאגר, הסרת תעודה מיושנת ידועה אחת ותיקון פרופיל דפדפן הם שלושה שינויים שונים עם שלושה סיכונים שונים.
לאחר התיקון, התחברו ובחנו את המאגר
לאחר תיקון מורשה, התחברו ל-VPN ואשרו שתעודת השרת עדיין מאומתת כמתוכנן. בדקו שהזהויות שהתהליך זקוק להן עדיין קיימות ושאין עוגן אמון לא צפוי שהופיע. תיקון שגורם לחיבור לעבוד על ידי אמון רב יותר מבעבר אינו תיקון.
הפרידו בין התצפית להוראה: מחיקה אחת והפעלה מוצלחת אחת אינן פתרון כללי.
אם הקפיאה חוזרת, תעדו את יומן הלקוח ואת הפרופיל בשימוש לפני שתשנו דבר אחר. הרשומה הזו היא מה שהופך השערה לאבחנה.