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 にサインインし、サーバー証明書が意図どおりに検証され続けていることを確認します。ワークフローに必要な識別情報が残っていること、予期しない 信頼のアンカー が現れていないことを点検します。以前より多く信頼して接続を通す修復は修復ではありません。

観察と指示は分けてください。削除一回と起動成功一回は一般的な解決策ではありません。

停止が再発したら、他を変える前にクライアントのログと使用中のプロファイルを取得してください。その記録が推測を診断に変えます。