cert8.db không phải bộ nhớ đệm dùng một lần: hãy kiểm tra chủ sở hữu kho
Xóa cert8.db thay đổi trạng thái bảo mật lâu dài, không phải bộ nhớ đệm trang. Tìm hồ sơ mà ứng dụng khách mở, sao lưu và chỉ sửa những gì được phê duyệt.
Một chủ đề hỗ trợ cũ khuyên xóa tệp tên cert8.db và VPN lại hoạt động. Chuỗi đó thường là sự trùng hợp hơn là bản sửa lỗi. Tệp là cơ sở dữ liệu chứng chỉ, và xóa nó thay đổi trạng thái bảo mật lâu dài theo cách mà một lần khởi chạy thành công không cho thấy.
Đăng nhập bị treo không phải vấn đề bộ nhớ đệm
Bộ nhớ đệm trình duyệt lưu bản sao tài nguyên; cơ sở dữ liệu chứng chỉ lưu các quyết định tin cậy, chứng chỉ và các khóa đi kèm. Xóa cái thứ hai gần với việc đặt lại danh tính hơn là xóa lịch sử. Nếu ứng dụng khách bị treo khi đăng nhập, bằng chứng hữu ích là tiến trình nào mở hồ sơ nào và ghi lại gì, không phải tệp nào bị một bài đăng diễn đàn xóa. Tái hiện treo và đọc nhật ký ứng dụng khách mất nhiều thời gian hơn xóa một tệp, và đó là con đường duy nhất đến nguyên nhân thật.
Tên tệp cũng mang lịch sử: NSS phân biệt cert8.db và key3.db cũ với cert9.db và key4.db dựa trên SQLite. Ghi lại dòng nhật ký bạn thấy trước khi treo, vì đó là bằng chứng bền vững duy nhất bạn có.
Ứng dụng khách thực sự mở hồ sơ nào
Xác định ứng dụng khách, phương thức xác thực và kho mà nó đọc. Ở đây có ba đường đăng nhập: có trình duyệt hỗ trợ, trình duyệt nhúng và ứng dụng khách gốc, và chúng không nhất thiết phải dùng chung hồ sơ. Một cơ sở dữ liệu đúng tên ở thư mục khác không phải bằng chứng rằng tiến trình bị treo đã mở nó. Trên Linux, kho NSS thường nằm dưới ~/.pki/nssdb của người dùng hoặc trong thư mục hồ sơ của từng ứng dụng. Cả hai cách bố trí có thể cùng tồn tại trên một máy, vì vậy hãy kiểm tra cả hai nếu việc di chuyển mới xảy ra.
Liệt kê những gì kho chứa trước khi thay đổi: certutil -L -d sql:$HOME/.pki/nssdb in các chứng chỉ, và cùng công cụ với -K cho biết có khóa hay không.
Nếu lệnh báo không mở được cơ sở dữ liệu, bạn đã tìm ra hồ sơ mà công cụ dùng, nhưng không nhất thiết là hồ sơ VPN đã dùng.
Sao lưu hồ sơ trước mọi sửa chữa
Đóng các ứng dụng bị ảnh hưởng, sau đó sao chép toàn bộ thư mục hồ sơ bằng phương thức sao lưu được phê duyệt. Cơ sở dữ liệu chứng chỉ và khóa là trạng thái liên quan nhưng riêng biệt, và lưu một tệp tùy ý không phải kế hoạch khôi phục cho toàn bộ danh tính. Bảo vệ bản sao, vì hồ sơ có thể chứa khóa riêng. Ghi lại bạn đã sao lưu gì và ở đâu, để một sửa chữa thất bại có đường quay lại.
Sau đó xác nhận phạm vi chính xác của sửa chữa với người bảo trì. Đặt lại toàn bộ kho, gỡ một chứng chỉ lỗi thời đã biết và sửa hồ sơ trình duyệt là ba thay đổi khác nhau với ba rủi ro khác nhau.
Sau khi sửa, đăng nhập và kiểm tra kho
Sau một sửa chữa được cho phép, đăng nhập VPN và xác nhận chứng chỉ máy chủ vẫn được xác thực như dự định. Kiểm tra rằng các danh tính quy trình làm việc cần vẫn còn và không xuất hiện neo tin cậy bất ngờ. Một sửa chữa làm kết nối hoạt động bằng cách tin cậy nhiều hơn trước không phải là sửa chữa.
Tách quan sát và hướng dẫn: một lần xóa và một lần khởi chạy thành công không phải giải pháp chung.
Nếu treo quay lại, hãy ghi lại nhật ký ứng dụng khách và hồ sơ đang dùng trước khi thay đổi bất cứ điều gì khác. Bản ghi đó là thứ biến phỏng đoán thành chẩn đoán.