余分なルート証明書はどの検証器に影響するか

そこにあるはずのないルート証明書を見つけたとき、最初の疑問はそれが誰の身元を騙れるかです。正直な答えは、どのソフトウェアがそのストアを参照するか、そして VPN がどのようにゲートウェイを検証するかによって変わります。ブラウザ、パッケージマネージャー、ピン留めされたフィンガープリントを使う VPN クライアントが、同じ信頼判断を共有するとは限りません。範囲を決める前に、検証器を洗い出してください。

システムストアのルートは万能鍵ではない

ルートをインストールすると、その鍵で署名された証明書が、影響を受けるストアを使うプログラムにとって受け入れ可能になります。ただし、一部のアプリケーションは独自のバンドルを同梱したり、ピン留めされた値を確認したりするため、どこでも自動的に受け入れられるわけではありません。また、誰かがマシン上でコードを実行した証明にもなりません。信頼の変更は複数ある能力の一つにすぎません。証明書はインシデント全体ではなく、範囲を定めるべき所見として扱ってください。

ストアは証明書と同じくらい重要です。ユーザーレベルのバンドルとシステム全体のアンカーでは、届く利用者が異なります。

各検証器とその信頼ソースを洗い出す

影響を受けるワークフローで証明書を検証するコンポーネントをすべて書き出します。ブラウザ、パッケージマネージャー、メールクライアント、VPN です。次に、それぞれが読む信頼ソースを特定します。

ls /usr/local/share/ca-certificates
trust list | grep -i -E "vpn|corp"

ディレクトリの一覧は Debian 系システムでローカルに追加されたアンカーを示し、信頼一覧はシステムストアが現在公開している内容を示します。独自のストアを持つブラウザはそこに現れず、Java や Python のアプリケーションはさらに別のバンドルを使う場合があります。どの項目が想定内でどれが想定外かを、表示名だけでなくフィンガープリントを使って記録してください。この一覧こそ、何かを削除する前にインシデント対応担当者が必要とするものです。

VPN 自身のピア検証を確認する

VPN が プライベート CA や明示的なフィンガープリントを持っている場合、ゲートウェイは自身の設定に照らして評価されます。クライアントが期待する内容と、ゲートウェイが提示する内容を比較してください。

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts </dev/null 2>/dev/null | openssl x509 -noout -fingerprint -sha256 -subject

出力には、エンドポイントが提示する証明書の SHA-256 フィンガープリントとサブジェクトが含まれ、設定値と比較できます。OpenVPN のピアフィンガープリントオプションは、システムストアが署名者を受け入れることを要求せずに、トンネルに対してその比較を行います。この独立性はトンネルには有用ですが、ブラウザについては何も語りません。期待するフィンガープリントがそもそも疑わしい接続からコピーされていた場合には、これも役に立ちません。

証明書の外側までインシデントの範囲を定める

デバイス所有者の手順に従って、不正なアンカーを削除し、通常それに伴う変更を探します。新しいサービス、改変されたクライアント、変更されたプロキシ設定です。管理されたマシンでは、他のソフトウェアが依存するものを削除する前に、正規の設定を確認してください。検証器ごとに、信頼の出どころ、期待する身元、現在の設定が正しいと確認した方法を記録します。清掃後にトンネルが動作することは一つの観察であり、エンドポイントが清潔である証拠ではありません。

次に、そのストアを使っていたワークフローを再テストします。アンカーを削除すると、それに正当に依存していた内部サービスが壊れる可能性があるためです。想定された信頼関係が機能し、想定外のものが機能しないときに復旧は完了します。