■ はじめに
前回は、企業ネットワークとSSLインスペクションの全体像を整理しました。
👉 プロキシが通信の間に入り、内容を検査する仕組みでした。
今回はその中身、
「実際に何が起きているのか」 を証明書ベースで説明します。
■ まずは通常のHTTPS通信
通常のHTTPS通信では、ブラウザはサーバの証明書を検証します。
PC → Webサイト
↓
証明書を受け取る
ここで重要なのが 証明書チェーン です。
■ 証明書チェーンとは
証明書は単体で信頼されているわけではありません。
以下のような「つながり」で信頼されています。
[ルートCA]
↓
[中間CA]
↓
[サーバ証明書]
ブラウザはこのチェーンをたどって、
👉 最終的に信頼できるルートCAにたどり着くか
を確認しています。
■ SSLインスペクションがある場合
ここからが本題です。
SSLインスペクションが有効な環境では、通信はこうなります。
PC → プロキシ → Webサイト
このとき実際には、通信は分断されています。
■ 実際に起きていること
① プロキシ ↔ Webサイト
プロキシ → Webサイト
- 通常のHTTPS通信
- 本物の証明書を使用
② PC ↔ プロキシ
PC → プロキシ
ここが重要です。
👉 プロキシは別の証明書をPCに渡します
■ 証明書はどうなっているのか
本来：
example.com の証明書（本物）
SSLインスペクション環境では：
example.com の証明書（プロキシが生成）
👉 ドメイン名は同じ
👉 でも中身（署名者）が違う
■ じゃあなぜエラーにならないのか？
ここが一番のポイント。
👉 企業内のルートCAがPCにインストールされているから
■ 企業内CAの存在
企業では独自のCA（認証局）を持っています。
[企業ルートCA]
↓
[プロキシが発行した証明書]
このルートCAがPCに信頼済みとして登録されているため、
👉 プロキシの証明書でも「正しい」と判断される
■ まとめると
SSLインスペクションではこうなっています。
PC →（企業CAで署名された証明書）→ プロキシ
プロキシ →（本物の証明書）→ Webサイト
👉 通信は2つに分かれている
■ 実務でハマるポイント（軽く触れる）
この仕組みによって、こんなことが起きます。
- Pythonの通信がエラーになる
- 証明書検証エラーが出る
原因は👇
👉 OSやアプリが企業CAを信頼していない
■ 次回（もう一段深い話）
👉 SSLインスペクションでハマるポイント（実務編）
- 証明書検証の厳格化（Pythonなど）
- AKI（Authority Key Identifier）が無いケース
- なぜ一部のクライアントだけ失敗するのか
■ まとめ
- SSLインスペクションは通信を2つに分ける仕組み
- プロキシが証明書を生成してクライアントに渡す
- 企業内CAを信頼しているためエラーにならない
- 技術的には「中間者」だが、管理された仕組み