サーバー証明書チェーンはクライアントの信頼ストアを上書きできるのか

チェーンが完全なサイトでブラウザーが証明書の警告を出すと、まずサーバーを直そうと考えます。しかし通常、サーバーは正しいものを提示しています。どのアンカーを受け入れるかはクライアントが決めることで、中間証明書の並びをどう変えても、接続の反対側からその判断は変えられません。証明書の問題に見えるものの多くは、この境界で説明できます。

検証はクライアント側で、クライアントのアンカーを使って実行される

パス検証は提示された証明書を取得し、検証システムがすでに持つ信頼アンカーまでのチェーンを構築します。RFC 5280 はこのモデルを記述しており、アンカーの選択をサーバーではなくローカルの実装に置いています。アプリケーションはその上に独自のポリシーを追加できます。固定した鍵、企業の信頼ストア、あるいはより厳格な身元確認です。サーバーが送る証明書一覧は、そのプロセスに差し出される証拠であり、決して指示ではありません。

つまり完全なチェーンは、サーバーが必要な部品を持っていることを証明します。クライアントがそれを受け入れることは証明しません。

サーバーが実際に何を送っているかを見るには、openssl s_client -connect app.example.net:443 -servername app.example.net -showcertsを実行し、出力内の証明書を数えます。そこで不完全なチェーンならサーバー側の修正です。完全なチェーンなら、問題はクライアントとそのアンカーの側に移り、サーバーに発言権はありません。

TLS 検査が実際に変えるもの

検査アプライアンスはクライアント側の TLS セッションを終端し、実際のサービスへ別のセッションを開きます。クライアントはそのアプライアンスの証明書を検証し、証明書はクライアントが信頼するアンカーまで連鎖している必要があります。管理対象の端末が端末管理を通じて検査ルートを受け取るのはこのためで、それがない個人端末が警告を出すのもこのためです。

この配置は意図的でローカルなものです。元のサーバーのチェーンにあるものは、管理されていないブラウザーに代替の身元を受け入れるよう強制できませんし、管理された端末がそうすることを妨げるものもありません。

VPN の終端は HTTPS の復号ではない

VPN 層はクライアントとゲートウェイの間でパケットを運びます。それを外しても、設定を読んでも、内部の HTTPS ペイロードは露出しません。

TLS セッションは依然としてブラウザーとウェブサーバーの間で、同じ検証規則のもとで動き続けます。何かが明示的に終端しない限り変わりません。二つの層を混同すると、VPN 管理者に証明書の提供を求めることになりますが、その証明書は検査プロキシーかサイト自身のものです。信頼ストアを変更する前に、どのコンポーネントが証明書を提示しているかを確認してください。

自分が制御するコンポーネントで期待値を定める

アプリケーションとそのクライアントを運用するなら、期待するサービスの身元、受け入れる発行者、ピン留めやクライアント認証の要件をまとめて定義します。正規の証明書変更が停止にならないよう、更新と復旧を計画します。公開サーバーだけを運用するなら、どの認証を要求し、どのクライアント環境を支援するかを文書化します。好ましいチェーンを送ることは、見知らぬ人の端末を証明することにはなりません。

管理された機器では、非互換性をアプリケーションとネットワークの所有者を通じて解決します。検証を無効にしたり、説明のないルートを追加したり、検査ポリシーをやり過ごそうとしたりしても、意図したピア関係は成立しません。

結果は、例外をすでに追加したマシンではなく、クリーンなクライアントプロファイルで試してください。新しい端末が何を経験するかを示す唯一の確認です。