要約

  • ルートの削除、不信任の基準日、ブラウザーの新バージョンは意図された方針を変えるが、全OS、アプリ、コンテナ、組み込み検証器への反映を証明しない。
  • 更新済み端末の台数ではなく、信頼元とクライアント群ごとの拒否テストを用い、検証主体の移行として運用する必要がある。

管理下の検証環境を仮定してみよう。最新のChrome群があるTLSチェーンを拒否する一方、企業管理下のWindowsクライアントと古いコンテナイメージ内のサービスは受け入れる。三つの仮想試験で証明書は同一である。

これは証明書構文の例外ではない。異なる三つの信頼判断が表面化したのである。

2024年、Chromeは特定のEntrustルートに対する対象限定の不信任を発表した。判定は最初のSigned Certificate Timestampの日付に依存し、公表された基準日より後の証明書はChrome 131から既定で信頼されず、それ以前の証明書は別扱いとなった。全クライアントが同時に解釈する一つのファイル削除ではなく、発効日、ブラウザー版、明示的に信頼されたローカルルートを伴う受入規則だった。

Chromeの構造はフリート問題を可視化する。Windows、macOS、ChromeOS、Linux、Androidでは、Chrome独自のルートストアと組み込み検証器への移行が進んだ。iOS上のChromeにはAppleのプラットフォーム規則が適用される。企業ポリシーは一時的にChrome Root StoreとOS検証器の選択も許し、ChromeはOSが明示的に信頼したローカルルートも取り込める。ブラウザー名だけでは信頼元全体を特定できない。

Microsoftの文書は別の差異を示す。Removal、EKU Removal、Disallow、Disable、NotBeforeは異なる。信頼CTLからのRemovalはチェーンを既定で不信頼にするが、一部ストアでは手動導入で信頼が戻り得る。Disallowはより強く、禁止CTLへの登録によって手動導入では信頼を戻せない。DisableとNotBeforeには、それぞれ時間と用途に関する別の意味がある。

これらの状態は更新経路を通って届く。接続されたWindowsクライアントは信頼・禁止CTLを自動取得できる。隔離環境では同じ情報を内部のファイルサーバーやWebサーバーに転送できる。MicrosoftはAuthRootとDisallowedの検証、および最終同期時刻の確認方法を示している。サーバーにポリシーがあるだけでは、クライアントが取り込んだ証拠にならない。

Appleは現行の共有ルートストアを公開し、旧版も保存している。インストール済みストア版は運用証拠になる。同時に、古い端末の状態を現在のWeb一覧で代用できないことも示す。Mozillaも信頼ビットの無効化と証明書の削除を区別し、将来日で実施でき、派生ディストリビューターが異なる選択を維持することを認める。

測定する前に措置を定義する

「ルートを削除する」だけではインシデント指示として曖昧すぎる。全チェーンの拒否、基準日後の発行だけの拒否、特定用途の削除、あるプログラムだけでの不信任、私設サービス向け例外の維持など、目的は異なる。必要な試験結果もそれぞれ異なる。

移行の分母は登録端末数ではなく検証主体の群である。ブラウザーと版、OSストア、アプリ実行環境、ランタイム証明書信頼バンドル、コンテナ基盤、機器ファームウェア、組み込みクライアント、管理例外を区別する。各群についてルート指紋、観測チェーン、期待する受入または拒否を保存する。不信任後も接続できる古いクライアントは、可用性監視が緑でも失敗である。

公開文書が証明するのは方針と配布機構であり、事業者の在庫、私設ルート、コンテナ更新、ファームウェア周期、実際の判定ではない。運用上の結論は推論である。信頼変更は業務を守る実際の検証主体と照合しなければならない。特定顧客、ルート運営者、プラットフォームの障害を主張するものではない。

出典