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-ში და დაადასტურეთ, რომ სერვერის სერტიფიკატი კვლავ დადასტურდება განზრახვისამებრ. შეამოწმეთ, რომ სამუშაო ნაკადისთვის საჭირო იდენტობები კვლავ არსებობს და მოულოდნელი ნდობის საყრდენი არ გამოჩენილა. შეკეთება, რომელიც კავშირს მუშაობას აიძულებს უფრო მეტი ნდობით, ვიდრე ადრე, შეკეთება არ არის.
გამოყავით დაკვირვება და მითითება: ერთი წაშლა და ერთი წარმატებული გაშვება ზოგადი გადაწყვეტა არ არის.
თუ გაყინვა დაბრუნდა, დააფიქსირეთ კლიენტის ჟურნალი და გამოყენებული პროფილი, სანამ სხვა რამეს შეცვლიდეთ. სწორედ ეს ჩანაწერი აქცევს ვარაუდს დიაგნოზად.