cert8.db कोई फेंकने योग्य कैश नहीं है: स्टोर का मालिक जाँचें
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 में साइन इन करें और पुष्ट करें कि सर्वर प्रमाणपत्र अब भी इच्छित रूप से सत्यापित होता है। जाँचें कि वर्कफ़्लो की ज़रूरी पहचानें अब भी मौजूद हैं और कोई अप्रत्याशित भरोसा एंकर नहीं दिखा। जो सुधार पहले से अधिक भरोसा करके कनेक्शन चलाता है वह सुधार नहीं है।
अवलोकन और निर्देश अलग रखें: एक बार मिटाना और एक सफल शुरुआत सामान्य समाधान नहीं है।
अगर जमाव लौटे, तो कुछ और बदलने से पहले क्लाइंट लॉग और इस्तेमाल हो रही प्रोफ़ाइल कैप्चर करें। वही रिकॉर्ड अनुमान को निदान में बदलता है।