TLSインスペクションとは？仕組み・危険性・TLS 1.3時代の安全な導入と確認方法

最終確認日：2026年8月19日

TLSインスペクションは、HTTPS通信を検査装置でいったん復号し、内容を確認してから再暗号化する仕組みです。

マルウェア検査、情報漏えい対策、WAF、IPS、DLPなどに利用できます。

一方で、通信を安全にする装置が、パスワード、Cookie、APIトークン、メール本文などを読める強力な復号地点になります。

したがって、すべての通信を一律に復号する設計は推奨できません。必要な通信だけを限定的に検査し、残りはDNS、IP、通信量、EDR、アプリケーションログなどで監視する設計が基本です。

2026年7月には、TLS 1.3の新しい基準文書としてRFC 9846が公開されました。RFC 9846は従来のRFC 8446を廃止扱いにしています。TLS 1.2はRFC 9851で機能凍結となり、新しいプロトコルにはTLS 1.3を必須とする方針がRFC 9852で示されています。TLSインスペクションのためにTLS 1.3への移行を止める設計は適切ではありません。

結論・要点

TLSインスペクションを導入するときは、次の方針を採用します。

1. 復号の目的を明文化する。
2. 管理対象端末だけを対象にする。
3. mTLS、証明書ピンニング、金融、医療、個人利用などの除外方針を定める。
4. 検査用CAの秘密鍵を厳重に管理する。
5. Authorization、Cookie、本文を無条件にログへ残さない。
6. ECH、HTTP/3、QUICへの対応方針を決める。
7. TLS 1.3を無効化せず、インスペクション側を更新する。
8. 失敗時に全通信を停止させるか、検査を迂回させるかを通信種別ごとに決める。
9. WAF、IPS、EDR、DNSフィルタリング、アプリケーション監査ログを併用する。
10. 小規模な試験導入から始め、証明書エラー率と遅延を確認する。

この記事の要点

• TLSインスペクションは、1本のHTTPS通信を2本のTLS通信に分割する仕組みです。
• TLS 1.3でも、検査装置が正規の通信終端になる方式なら復号できます。
• TLS 1.3では、サーバー秘密鍵だけで過去の通信を復号する旧来方式が使いにくくなりました。
• ECH、HTTP/3、mTLS、証明書ピンニングはTLSインスペクションと衝突する場合があります。
• 検査用CAの侵害は、組織全体のHTTPS通信に影響する重大事故になります。
• すべてを復号せず、必要な通信だけを検査する設計が安全です。
• 復号しない通信も、IP、DNS、通信量、接続頻度、EDR、ログで監視できます。
• 2026年時点のTLS 1.3基準文書はRFC 9846です。

この記事で分かること

この記事では、次の内容を実務レベルで説明します。

• TLSインスペクションの基本的な仕組み
• HTTPS通信を復号できる理由
• リバースプロキシ型とフォワードプロキシ型の違い
• TLS 1.3によって変わったこと
• ECH、QUIC、HTTP/3への影響
• mTLSや証明書ピンニングで障害が起きる理由
• TLSインスペクションが行われているか確認する方法
• 証明書エラーや通信障害の切り分け方法
• 安全な導入手順
• 動作確認とロールバック方法
• kurutann.comのようなCloudflare構成への適用方法

対象読者・前提環境

対象読者

• インフラエンジニア
• セキュリティ担当者
• 社内IT管理者
• SOC、CSIRT担当者
• Webサービス運営者
• WAF、IPS、NDR、EDRの開発者
• HTTPS通信の証明書エラーを調査している人
• CloudflareやSecure Web Gatewayを利用している人

コマンドの前提環境

記事内の確認例は、主に次の環境を想定しています。

記事内の通常確認コマンドは読み取り専用です。

ただし、ルート証明書の追加・削除、TLSポリシーの変更、UDP/443の遮断、復号鍵の記録は通信障害や情報漏えいにつながります。変更前に設定をバックアップし、ロールバック手順を準備してください。

用語と全体像

TLSとは

TLSは、手紙を封筒に入れて封印する仕組みに似ています。

正式には、クライアントとサーバー間の通信について、次の性質を提供するプロトコルです。

• 盗聴されにくくする
• 通信内容の改ざんを検出する
• 接続先が正しいサーバーか確認する

現在のTLS 1.3はRFC 9846で定義されています。RFC 9846は、TLSが盗聴、改ざん、メッセージ偽造を防止する目的で設計されていると説明しています。

TLSインスペクションとは

TLSインスペクションは、組織が管理する「検査室」で封筒をいったん開ける仕組みに似ています。

検査装置は、次の処理を行います。

1. クライアントからのTLS通信を終端する。
2. 通信内容を復号する。
3. URL、HTTPヘッダー、本文、ファイルを検査する。
4. 問題がなければ再暗号化する。
5. 本来のサーバーへ送信する。

製品によっては、次の名称が使われます。

• TLS Inspection
• SSL Inspection
• HTTPS Inspection
• TLS Decryption
• Break and Inspect
• HTTPS Interception

「SSL Inspection」という名称が残っていても、実際に扱っている通信はTLSであることが一般的です。

主な用語

何が起きるのか

通常のTLS通信

通常は、クライアントとWebサーバーの間に1本のTLSセッションが作られます。

ブラウザー
    │
    │ TLSセッション
    │
    ▼
Webサーバー

ブラウザーは、Webサーバーが提示した証明書を確認します。

証明書のホスト名、有効期限、署名元などが正しければ、暗号化通信を開始します。

TLSインスペクションがある通信

TLSインスペクションでは、1本だった通信が2本に分かれます。

ブラウザー
    │
    │ TLSセッションA
    ▼
TLSインスペクション装置
    │
    ├─ 復号
    ├─ URL検査
    ├─ マルウェア検査
    ├─ DLP判定
    ├─ WAF・IPS判定
    └─ 再暗号化
          │
          │ TLSセッションB
          ▼
      Webサーバー

TLSインスペクション装置は、暗号文を横から透視しているわけではありません。

検査装置自身が、クライアント側とサーバー側の両方でTLS通信の正規の終端になります。

Cloudflare Gatewayも、TLS復号を有効にするとHTTPS通信を復号し、HTTPポリシーを適用した後、利用者側証明書を使って再暗号化します。復号しなければ、完全なURL、HTTPヘッダー、リクエスト本文などは確認できません。

証明書はどのように置き換わるのか

フォワードプロキシ型では、次の処理が行われます。

1. 利用者が https://service.example/ に接続する
2. 検査装置が本物のservice.exampleへ接続する
3. 検査装置が本物の証明書を検証する
4. 検査装置がservice.example用の代替証明書を生成する
5. 代替証明書を組織の検査用CAで署名する
6. 利用者端末は組織CAを信頼しているため接続を許可する

結果として、ブラウザー上では証明書エラーが表示されない場合があります。

ただし、利用者が直接信頼している相手は本来のWebサーバーではなく、TLSインスペクション装置です。

TLSインスペクションの主な方式

インバウンド型

Cloudflare、CDN、ロードバランサー、Nginxなどで自社ドメインのTLSを終端する方式です。

利用者
  │
  │ TLS A
  ▼
Cloudflare・WAF・ロードバランサー
  │
  │ TLS B
  ▼
Nginx・Django

この方式では、利用者端末へ組織の独自CAを配布する必要はありません。

Webサイト所有者が、正規の証明書をCloudflareやロードバランサーへ設定しているためです。

Cloudflareでは、利用者からCloudflareまでの接続と、Cloudflareからオリジンサーバーまでの接続が別々に管理されます。Cloudflareは、可能であればオリジン証明書を検証するFullまたはFull（strict）を推奨しています。

アウトバウンド型

社内PCからインターネットへの通信を検査する方式です。

社員PC
  │
  ▼
Secure Web Gateway
  │
  ▼
インターネット

この方式では、任意の外部ドメインに対応する代替証明書を検査装置が生成します。

そのため、管理対象端末へ検査用CAの公開証明書を信頼済みルートとして配布します。

セッション鍵共有型

TLS通信を分割せず、TLSエンドポイントからセッション鍵を取得して解析装置へ渡す方式です。

TLS 1.3では前方秘匿性が強化されたため、サーバーの長期秘密鍵だけを使って過去の通信を復号する旧来の方法は使いにくくなりました。NIST SP 1800-37は、企業内部でTLS 1.3の可視性を維持するためのミドルボックス方式や鍵管理方式を検証しています。

ただし、NIST SP 1800-37は標準や必須要件ではなく、企業管理下のデータセンターを対象とした実践ガイドです。外部インターネット全体を復号する方法を推奨しているわけではありません。

自分に関係するか

社内IT管理者

社員PCのWebアクセス、ファイルダウンロード、SaaS利用、情報持ち出しを監視する場合に関係します。

特に次の製品を利用している場合は、TLSインスペクションが含まれる可能性があります。

• Secure Web Gateway
• SASE
• CASB
• 次世代ファイアウォール
• DLP
• Webプロキシ
• エンドポイントセキュリティ製品

Webサイト運営者

Cloudflare、CDN、WAF、ロードバランサーでTLSを終端している場合に関係します。

ただし、自社Webサイトの正規証明書を使うインバウンド終端と、社員の外部通信へ代替証明書を発行するアウトバウンドインスペクションは別の仕組みです。

アプリケーション開発者

次の機能を利用するアプリは、TLSインスペクション環境で接続に失敗する可能性があります。

• 証明書ピンニング
• mTLS
• 独自CA
• 独自TLSライブラリ
• アプリ内に固定された証明書ストア
• HTTP/3または独自QUIC通信

一般利用者

会社や学校が管理する端末では、TLSインスペクションが実施されている場合があります。

次の状態だけでは、直ちに不正な盗聴とは判断できません。

• 証明書の発行者が会社名になっている
• セキュリティ製品のCAが登録されている
• HTTPSサイトでも組織の証明書が表示される

正式な社内規程、利用者への通知、管理権限、対象範囲を確認する必要があります。

原因：なぜTLSインスペクションが必要になり、なぜ障害が起きるのか

TLSインスペクションが導入される理由

HTTPSで暗号化されると、通信経路上のセキュリティ装置はHTTP本文を直接確認できません。

復号しなければ、一般に次の内容は見えません。

• 完全なURLパス
• HTTPヘッダー
• Authorizationヘッダー
• Cookie
• POST本文
• JSON API本文
• アップロードファイル
• ダウンロードファイル
• HTMLやJavaScriptの内容

そのため、次の目的で復号が行われます。

TLS 1.3によって変わったこと

TLS 1.3でもインスペクションは可能

「TLS 1.3ではTLSインスペクションができない」という説明は正確ではありません。

検査装置がクライアントとサーバーの間で実際にTLSを終端する方式なら、TLS 1.3でも復号できます。

影響を受けるのは、主に次の旧来方式です。

暗号化パケットを保存
        ↓
後からサーバー秘密鍵を入手
        ↓
過去の通信を復号

TLS 1.3では、静的RSAや静的Diffie-Hellmanによる鍵交換が削除され、公開鍵ベースの鍵交換は前方秘匿性を持つ設計になりました。サーバーの長期秘密鍵が後から漏れても、過去のセッションを単純には復号できません。

TLS 1.3を無効化するべきではない

2026年7月のRFC 9851は、TLS 1.2を緊急セキュリティ修正などに限定した機能凍結状態としています。

RFC 9852は、新しく設計するTLS利用プロトコルにTLS 1.3を必須とする方針を示しています。可視性を維持するためだけにTLS 1.2へ固定する方法は、長期的な解決策になりません。

ECHによる影響

ECHはEncrypted Client Helloの略です。

従来のTLSでは、接続開始時のClientHelloにSNIが平文で含まれる場合がありました。

SNI: service.example

ECHでは、SNIやALPNなどを含むClientHelloの一部を暗号化します。

RFC 9849は、ECHがSNIやALPNなどの情報を経路上の第三者から保護する仕組みを定義しています。ただし、接続先IPや暗号化されていないDNS問い合わせなど、別の経路から接続先を推測できる場合はあります。

ECHが有効になると、次の処理が難しくなります。

• SNIによるドメイン分類
• ドメイン単位の復号除外
• SNIだけを使ったアクセス制御
• 復号前の宛先判定

ECHは、すべてのTLSインスペクションを自動的に無効化するものではありません。

明示プロキシ、DNS制御、端末エージェント、製品独自のフォールバックなど、製品によって動作が異なります。

Cloudflare Gatewayは、ECH、mTLS、証明書ピンニングなどをTLS復号の制限事項として明示しています。

QUICとHTTP/3による影響

HTTP/3はQUIC上で動作します。

QUICはTLS 1.3をセキュリティ機構として利用し、HTTP/3はQUIC上でHTTPを提供します。

従来のHTTPSは、主にTCP/443上で動作します。

HTTP/1.1・HTTP/2
        ↓
       TLS
        ↓
       TCP

HTTP/3は次の構造です。

HTTP/3
   ↓
QUIC + TLS 1.3
   ↓
UDP

TCP向けのTLSインスペクション装置がQUICに対応していない場合、次の選択肢があります。

1. QUIC対応プロキシで終端する。
2. HTTP/3は復号せずメタデータだけ監視する。
3. UDP/443を制限し、HTTP/2へのフォールバックを試みる。
4. 対応できないアプリを除外する。

UDP/443を一律に遮断すると、性能低下、接続遅延、一部アプリの通信障害が起きる可能性があります。

RFC 9312も、QUICに対するネットワーク管理は一律ではなく、組織の要件によって適否が異なると説明しています。

mTLSによる影響

通常のTLSでは、主にクライアントがサーバー証明書を検証します。

mTLSでは、サーバー側もクライアント証明書を検証します。

クライアント証明書
        ↓
本来のサーバーが本人確認

検査装置が途中でTLSを分割すると、本来のクライアント証明書と秘密鍵による認証を、そのまま後段へ引き継げない場合があります。

その結果、次のようなシステムで障害が起こります。

• API間認証
• IoT機器
• VPN
• 管理API
• 金融系API
• 社内サービス間通信

mTLS通信は、原則として事前に検出して復号対象から除外する設計を検討します。

証明書ピンニングによる影響

証明書ピンニングを利用するアプリは、OSの信頼済みCAだけではなく、特定の証明書や公開鍵を確認します。

アプリが期待する公開鍵
        ≠
検査装置が生成した証明書の公開鍵

組織CAが端末で信頼されていても、ピンニングされたアプリは接続を拒否します。

Androidの公式資料では、ピンニングは公開鍵のハッシュを使って許可する証明書を限定する仕組みとして説明されています。また、証明書やCAの変更によってアプリが接続不能になるため、一般的なAndroidアプリでは安易なピンニングを推奨していません。Appleもピンニングは必要な場合に限定し、慎重に導入するよう案内しています。

アプリ独自の証明書ストア

OSへ組織CAを登録しても、すべてのアプリがそのCAを信頼するとは限りません。

次の環境は、独自の証明書ストアを使う場合があります。

• Java
• Pythonの一部構成
• Node.js
• コンテナ
• 組み込み機器
• 一部ブラウザー
• モバイルアプリ
• 独自TLSライブラリ

「ブラウザーでは接続できるが、Javaアプリだけ失敗する」という場合は、アプリ独自のトラストストアを確認します。

TLSインスペクションで見えるもの・見えないもの

復号すると見える情報

復号しなくても見える情報

環境やプロトコルによって差がありますが、一般に次のメタデータは利用できます。

• 送信元IP
• 送信先IP
• ポート番号
• 通信量
• 通信時間
• 接続頻度
• TLSバージョン
• 暗号スイート
• 証明書情報
• パケットサイズ
• 通信方向
• ECHが未使用の場合のSNI
• DNS問い合わせ履歴

NISTは、復号しない通信についても、可視メタデータ、ログ、ヒューリスティックなどを使って分析するべきだとしています。また、すべての組織が一律にTLS復号を導入する必要はなく、細かなポリシー制御を推奨しています。

復号しても見えない場合がある情報

TLSの内側で、さらに暗号化されているデータは確認できません。

TLS
 └─ 暗号化されたアプリケーションペイロード
      └─ 復号できない

例として、次の通信があります。

• エンドツーエンド暗号化メッセージ
• パスワード付きZIP
• 暗号化バックアップ
• 独自暗号化API
• 暗号化されたデータベースダンプ
• クライアント側で暗号化してからアップロードするファイル

TLSインスペクションは、すべての情報を読める万能な仕組みではありません。

TLSインスペクションに否定的であるべき5つの理由

1. 復号装置が巨大な攻撃対象になる

TLSインスペクション装置には、平文の通信が集中します。

侵害された場合、次の情報が漏れる可能性があります。

• パスワード
• セッションCookie
• OAuthトークン
• APIキー
• メール本文
• ファイル
• 個人情報
• 社内システムのURL
• 管理画面へのアクセス内容

防御装置を追加した結果、価値の高い単一侵害点を作る可能性があります。

2. 検査用CAの秘密鍵が組織全体の弱点になる

検査用CAの秘密鍵を盗まれると、攻撃者が組織管理端末に対する偽証明書を作成できる可能性があります。

検査用CAは、通常のWebサーバー証明書より大きな権限を持ちます。

次の管理が必要です。

• 専用の検査用CAを使う
• 他用途のCAと共用しない
• 秘密鍵をHSMなどで保護する
• 管理者権限を分離する
• 鍵利用を監査する
• ローテーションと失効手順を準備する

3. 本来のエンドツーエンド保護を分割する

通常は、クライアントが本来のサーバー証明書を直接確認します。

TLSインスペクションでは、クライアントは検査装置が発行した証明書を確認します。

通常
クライアント ───────── 本来のサーバー

TLSインスペクション
クライアント ─ 検査装置 ─ 本来のサーバー

検査装置が本来のサーバー証明書を正しく検証しなければ、利用者側では異常を検出できません。

CISAも、HTTPSインターセプション製品によってTLSの安全性が低下する可能性を警告しています。

4. プライバシーと労務上の負担が増える

TLSインスペクションでは、技術的には私用メール、金融、医療、認証情報なども確認できます。

日本の個人情報保護委員会は、従業者へのオンラインモニタリングについて、目的の特定、社内規程、責任者と権限、運用ルール、適正運用の確認、従業者への周知などを留意点として挙げています。重要事項を定める場合は、労働組合などへの通知や必要に応じた協議が望ましいとしています。

これはTLSインスペクションだけを対象とした法的見解ではありません。

実際の導入では、法務、労務、個人情報保護担当、情報セキュリティ担当による確認が必要です。

5. 導入しただけで安全になったと誤解しやすい

復号できても、検知ルールがなければ攻撃を見逃します。

次の攻撃は残ります。

• 未知のマルウェア
• 正規SaaSを使った情報流出
• 暗号化ファイル
• アプリ内部の不正操作
• セッション乗っ取り
• 正規アカウントによる不正
• 端末内部だけで完結する攻撃
• 復号対象から除外された通信の悪用

TLSインスペクションは可視性を増やす機能であり、完全な防御ではありません。

確認方法：TLSインスペクションされているか調べる

確認方法1：ブラウザーで証明書の発行者を確認する

目的

接続先から提示されている証明書の発行者を確認します。

実行場所

TLSインスペクションの影響が疑われる端末のブラウザーです。

確認手順

ブラウザーのアドレスバーから、接続情報と証明書チェーンを表示します。

ブラウザーによって表示方法は異なります。

確認する項目は次のとおりです。

• Subject
• Issuer
• 有効期限
• Subject Alternative Name
• 証明書チェーン
• SHA-256フィンガープリント

正常例：インスペクションなし

Subject: service.example
Issuer: Public CA Example

正常例：意図したインスペクションあり

Subject: service.example
Issuer: Example Corporation TLS Inspection CA

組織が正式に運用しているCAであれば、証明書エラーは表示されない場合があります。

異常例

Issuer: Unknown Security Product CA

または、証明書警告が表示されます。

判断方法

組織CAが表示されたことだけでは、異常とは断定できません。

次の項目を確認します。

• 会社が正式に導入したCAか
• 管理対象端末か
• 社内規程に記載されているか
• 証明書のフィンガープリントが管理台帳と一致するか
• 個人所有端末へ意図せず導入されていないか

確認方法2：OpenSSLで証明書チェーンを確認する

目的

TLS接続時に提示された証明書、発行者、検証結果を確認します。

実行場所

影響が疑われるLinux、macOS、WSL、またはOpenSSLが利用できる端末です。

コマンド

HOST="service.example"

openssl s_client \
  -connect "${HOST}:443" \
  -servername "${HOST}" \
  -showcerts \
  -verify_hostname "${HOST}" \
  -verify_return_error \
  </dev/null

OpenSSLの-verify_return_errorを付けない場合、証明書検証エラーがあっても調査のためにハンドシェイクを継続することがあります。厳密な確認では同オプションを付けます。

正常例

subject=CN=service.example
issuer=C=XX, O=Public CA Example
Verification: OK
Verify return code: 0 (ok)

意図したインスペクション例

subject=CN=service.example
issuer=O=Example Corporation, CN=TLS Inspection Issuing CA
Verification: OK
Verify return code: 0 (ok)

Verify return code: 0であっても、接続先が本来のサーバーとは限りません。

クライアントが検査用CAを信頼していれば、代替証明書も正常と判定されます。

異常例

verify error:num=20:unable to get local issuer certificate

または、

verify error:num=62:hostname mismatch

判断方法

unable to get local issuer certificateには、複数の原因があります。

• 組織CAが端末に登録されていない
• アプリ独自の証明書ストアにCAがない
• サーバーの中間証明書が不足している
• 意図しないTLSインスペクションがある
• 検査装置の証明書チェーン設定が誤っている

このエラーだけでTLSインスペクションと断定してはいけません。

確認方法3：証明書のフィンガープリントを取得する

目的

社内ネットワークと、インスペクションされていない比較回線で証明書を比較します。

実行場所

• 社内ネットワーク上の端末
• 管理者が許可した比較用ネットワーク

コマンド

HOST="service.example"

openssl s_client \
  -connect "${HOST}:443" \
  -servername "${HOST}" \
  </dev/null 2>/dev/null |
openssl x509 \
  -noout \
  -subject \
  -issuer \
  -serial \
  -fingerprint \
  -sha256

正常例

両方の回線で発行者とフィンガープリントが同じです。

インスペクションが疑われる例

社内ネットワークでは組織CA、比較回線では公開CAが表示されます。

判断方法

フィンガープリントが違うだけでは断定できません。

CDNのエッジ、証明書更新、複数証明書、RSAとECDSAの出し分けなどによって証明書が変わる場合があります。

発行者、証明書チェーン、ネットワーク経路、社内ポリシーを合わせて判断します。

確認方法4：curlでTLSとHTTP応答を確認する

目的

証明書検証、TLSネゴシエーション、HTTPステータスをまとめて確認します。

実行場所

影響が疑われる端末です。

コマンド

curl --verbose --head https://service.example/

curlは通常、証明書の署名とホスト名を検証します。--verboseはTLS接続やHTTP通信の切り分けに利用できます。

正常例

SSL certificate verify ok.
< HTTP/2 200

または、正規のリダイレクトです。

< HTTP/2 301
< location: https://www.service.example/

異常例

curl: (60) SSL certificate problem:
unable to get local issuer certificate

判断方法

ブラウザーだけ成功してcurlが失敗する場合は、次を確認します。

• curlが参照しているCAストア
• OSのCAストア
• CURL_CA_BUNDLE
• SSL_CERT_FILE
• アプリ独自のCA設定
• プロキシ環境変数

危険な誤対処

次のコマンドを恒久対策として使ってはいけません。

curl --insecure https://service.example/

--insecureは証明書検証を無効化します。

一時的な切り分け以外で使用すると、中間者攻撃や偽サーバーを検出できなくなります。

確認方法5：プロキシ環境変数を確認する

Linux・macOS

目的

環境変数で明示プロキシが設定されていないか確認します。

コマンド

env | grep -Ei '^(http|https|all|no)_proxy='

正常例

想定した社内プロキシが表示されます。

HTTPS_PROXY=http://proxy.example.local:8080
NO_PROXY=localhost,127.0.0.1,.example.local

異常例

管理台帳にないプロキシが表示されます。

HTTPS_PROXY=http://127.0.0.1:12345

判断方法

ローカルホストが表示されても、直ちに不正とは限りません。

EDR、開発用デバッグプロキシ、VPNクライアントなどがローカルプロキシを利用する場合があります。

Windows PowerShell

Get-ChildItem Env: |
    Where-Object Name -Match '^(HTTP|HTTPS|ALL|NO)_PROXY$'

透明型プロキシやネットワーク経路上のインスペクションは、環境変数に表示されない場合があります。

確認方法6：Windowsの信頼済みルートCAを確認する

目的

端末へ登録されているルートCAを確認します。

実行場所

Windows PowerShellです。

コマンド

Get-ChildItem Cert:\LocalMachine\Root |
    Select-Object Subject, Thumbprint, NotAfter |
    Sort-Object Subject

正常例

会社が管理している検査用CAが台帳どおりに表示されます。

異常例

次の証明書が見つかります。

• 管理台帳にない会社名
• 不明なセキュリティ製品名
• 有効期限切れ
• 同じ名前で異なるフィンガープリント
• 個人端末に意図せず導入された組織CA

判断方法

不明なCAを見つけても、すぐ削除してはいけません。

削除すると、社内Web、VPN、Wi-Fi、メール、MDM、認証基盤などが停止する可能性があります。

証明書のThumbprintを管理者へ提示し、用途を確認します。

確認方法7：HTTP/3通信を確認する

目的

HTTP/3が利用できるか、ネットワークまたは検査装置がQUICを制限していないか確認します。

実行場所

HTTP/3対応のcurlが導入された検証端末です。

コマンド

curl --http3-only --head https://service.example/

正常例

HTTP/3 200

異常例

curl: option --http3-only:
the installed libcurl version does not support this

この場合は、ネットワーク障害ではなくcurl自体がHTTP/3非対応です。

別の異常例として、HTTP/3だけがタイムアウトし、通常のcurlではHTTP/2へ接続できる場合があります。

判断方法

次を確認します。

• curlのHTTP/3対応
• UDP/443のファイアウォール設定
• TLSインスペクション製品のQUIC対応
• VPNやSASE製品のQUIC設定
• HTTP/2へのフォールバック結果

上級者向け：SSLKEYLOGFILEについて

2026年7月にRFC 9850として、TLSセッションの秘密情報を記録するSSLKEYLOGFILE形式が公開されました。

この形式を使うと、対応するパケットキャプチャーをWiresharkなどで復号できます。

ただし、RFC 9850は次の点を明確にしています。

• テストデータを扱う環境向けである
• ファイルが漏れるとTLSの主要な安全性が失われる
• 本番システムで使用してはいけない

本番ブラウザー、本番API、管理画面、個人情報を扱う通信で有効化してはいけません。

よくある症状と原因

対処方法：安全にTLSインスペクションを導入する

手順1：目的を一文で定義する

最初に、なぜ復号が必要なのかを定義します。

悪い例は次のとおりです。

セキュリティを強化するため

範囲が広すぎます。

良い例は次のとおりです。

管理対象Windows端末から外部Webサイトへアップロードされる
個人情報と秘密鍵をDLPで検出するため

目的が具体的であれば、復号対象と除外対象を決められます。

手順2：本当に本文の復号が必要か判断する

NISTも、すべての通信を復号するのではなく、細かなポリシー制御と非復号通信のメタデータ分析を組み合わせる考え方を示しています。

手順3：管理対象端末だけにCAを配布する

検査用CAは、原則として次の端末だけに配布します。

• 組織所有端末
• MDM管理端末
• GPO管理端末
• セキュリティポリシーへ同意した端末
• 検証用端末

個人所有端末へ一律に配布すると、退職後、紛失後、管理外ネットワークでも組織CAが残る可能性があります。

手順4：検査専用CAを分離する

推奨構成は次のとおりです。

オフラインまたは厳重管理されたルートCA
              │
              ▼
TLSインスペクション専用中間CA
              │
              ▼
アクセス先ごとに生成する代替証明書

避けるべき構成は次のとおりです。

同じCAを複数用途で共用
 ├─ TLSインスペクション
 ├─ VPN
 ├─ Wi-Fi
 ├─ クライアント証明書
 ├─ コード署名
 └─ 社内Web証明書

検査用CAが侵害された場合の影響範囲を限定できなくなります。

CA管理の最低要件

• 秘密鍵を端末へ配布しない
• 秘密鍵を平文ファイルで保管しない
• HSMまたは同等の鍵保護を検討する
• 管理者と監査者を分離する
• 鍵利用ログを保管する
• 証明書の有効期限を監視する
• 緊急失効手順を準備する
• 新旧CAの切り替え手順を試験する
• CAフィンガープリントを台帳化する

手順5：除外対象を先に決める

TLSインスペクションを有効化してから障害サイトを除外する方法では、利用者影響が大きくなります。

先に次の通信を洗い出します。

• mTLS
• 証明書ピンニング
• OSアップデート
• セキュリティ製品の更新
• EDR、VPN、SASEの制御通信
• 金融・決済
• 医療・健康
• 個人メール
• パスワード管理サービス
• 行政手続き
• 自己署名証明書を使う社内システム
• ECH利用サービス
• HTTP/3専用アプリ
• 独自TLSプロトコル
• 障害対応用の緊急通信

金融や医療を必ず除外しなければならないと一律に断定することはできません。

組織の業務要件、規制、利用規程、製品能力を基に判断します。

手順6：本来のサーバー証明書を厳格に検証する

検査装置は、本来のサーバーへ接続するときに次を検証します。

• ホスト名
• 有効期限
• 証明書チェーン
• 信頼済みCA
• 署名アルゴリズム
• TLSバージョン
• 失効状態
• 用途制限

次の設定は避けます。

上流証明書が無効でも利用者には正常な代替証明書を返す

この設定では、本来のサーバーが偽装されていても、利用者側からは正常に見えます。

手順7：ログに秘密情報を残さない

復号できることと、すべてを保存することは別です。

標準では、次の情報をマスキングまたは保存対象外にします。

• Authorization
• Proxy-Authorization
• Cookie
• Set-Cookie
• パスワード
• セッションID
• APIキー
• CSRFトークン
• クレジットカード番号
• アクセストークン
• リフレッシュトークン
• ファイル本文

推奨するログ例は次のとおりです。

{
  "timestamp": "2026-08-19T08:30:00+09:00",
  "device_id": "managed-device-001",
  "user_id_hash": "sha256:...",
  "host": "service.example",
  "path_template": "/api/items/{id}",
  "method": "POST",
  "status": 403,
  "policy_id": "tls-dlp-012",
  "action": "block",
  "reason": "private_key_detected",
  "request_body_stored": false,
  "authorization_stored": false
}

手順8：Fail OpenとFail Closedを通信ごとに決める

Fail Open

検査装置が停止したとき、復号せず通信を通します。

Fail Closed

検査装置が停止したとき、通信を遮断します。

すべての通信へ同じモードを設定する必要はありません。

例えば、管理APIはFail Closed、一般Web閲覧はFail Openとアラート、という設計も考えられます。

手順9：小規模なカナリア導入を行う

最初から全端末へ展開してはいけません。

次の順番で拡大します。

検証端末
   ↓
セキュリティ・IT部門
   ↓
限定された一般利用者
   ↓
特定部署
   ↓
全体展開

各段階で次を測定します。

• TLSハンドシェイクエラー率
• 証明書警告件数
• HTTPエラー率
• p50、p95、p99遅延
• CPU使用率
• メモリ使用率
• 同時接続数
• ファイル検査待ち時間
• バイパス率
• HTTP/3からHTTP/2へのフォールバック
• ヘルプデスク問い合わせ件数

手順10：ロールバック順序を決める

安全なロールバック例

1. 新規TLSインスペクションポリシーを停止する
2. 通信が直接経路または旧経路へ戻ったことを確認する
3. 認証、SaaS、更新通信を確認する
4. 数日間監視する
5. 不要になったCAを端末から削除する

危険な順序

1. 端末から組織CAを削除する
2. 検査装置は稼働したまま
3. 全HTTPS通信で証明書エラーが発生する

CAの削除を先に実施してはいけません。

補助対策：すべてを復号しないための構成

TLSインスペクションを減らすには、通信経路だけではなく、エンドポイント、アプリケーション、ID基盤から情報を集めます。

kurutann.comへの適用例

筆者の考察： 以下はCloudflare、Nginx、Django、EXkururuIPROSを組み合わせる場合の推奨構成です。実際の本番設定を直接確認した結果ではなく、設計上の提案です。

kurutann.comのような公開Webサービスでは、一般利用者の端末へ独自CAを導入するフォワードプロキシ方式は適しません。

次の構成を利用します。

利用者
  │
  │ TLSセッションA
  ▼
Cloudflare
  ├─ WAF
  ├─ Bot対策
  ├─ Rate Limit
  └─ エッジイベント
  │
  │ TLSセッションB
  ▼
Nginx
  ├─ アクセスログ
  ├─ エラーログ
  ├─ URI・Status
  └─ Upstream遅延
  │
  ▼
Django
  ├─ 認証イベント
  ├─ 権限判定
  ├─ CSRF判定
  ├─ API監査ログ
  └─ 業務イベント

Cloudflareでは、利用者からCloudflareまでと、Cloudflareからオリジンまでが別々の接続です。オリジンとの接続には、証明書を検証するFull（strict）を優先します。

EXkururuIPROSには、復号した本文を無条件に送るのではなく、次のイベントを連携します。

Cloudflareセキュリティイベント
               +
Nginxアクセス・エラーログ
               +
Django認証・権限・業務イベント
               +
EXkururuIPROSのフローメタデータ
               ↓
        相関分析・スコアリング

推奨する設計は次のとおりです。

• Authorizationを保存しない
• Cookieを保存しない
• POST本文を標準では保存しない
• URLは必要に応じてテンプレート化する
• ユーザーIDはハッシュ化を検討する
• Cloudflare、Nginx、Django間で相関IDを持つ
• WAF遮断とDjango認証失敗を同一タイムラインに統合する
• 攻撃判定に必要なフィールドだけをEvent Schemaへ入れる
• 本文検査が必要なAPIだけ、Django側で専用バリデーションを行う

この方式なら、一般利用者のTLSを自前で再度中間者復号せずに、アプリケーションの意味を持つセキュリティイベントを取得できます。

動作確認

機能確認項目

セキュリティ確認項目

性能確認項目

導入前後で次を比較します。

TLSハンドシェイク時間
DNS時間
接続時間
TTFB
ダウンロード時間
p50
p95
p99
エラー率
タイムアウト率
再送率
CPU使用率
メモリ使用率
同時接続数

単純な平均値だけでは、少数の大きな遅延を見逃します。

p95やp99も確認します。

ロールバック確認

本番導入前に、実際に次のテストを行います。

1. インスペクションを有効化する。
2. 検証通信を行う。
3. ポリシーを停止する。
4. 直接通信へ戻ることを確認する。
5. 証明書警告が出ないことを確認する。
6. CAを残した状態でも直接通信できることを確認する。
7. 最後に検証端末からCAを削除する。
8. CA削除後も通常通信が継続することを確認する。

再発防止

証明書ライフサイクルを管理する

次の情報を台帳化します。

• CA名
• Subject
• Issuer
• Serial Number
• SHA-256フィンガープリント
• 有効期限
• 管理責任者
• 利用製品
• 配布対象
• 配布方法
• 秘密鍵の保管場所
• 失効手順
• 更新手順
• ロールバック手順

ポリシーをコードまたは構成管理対象にする

TLSインスペクションポリシーは、画面上だけで変更しない方が安全です。

最低限、次を記録します。

変更前設定
変更後設定
差分
変更理由
申請者
承認者
適用日時
対象端末
有効期限
ロールバック方法

例外設定に有効期限を付ける

一度追加した除外設定を永久に残すと、復号されない通信が増え続けます。

各例外には次を設定します。

• 所有者
• 理由
• 対象ドメイン
• 対象アプリ
• 追加日
• 見直し日
• 廃止条件
• 代替監視方法

自動監視を行う

次の監視を自動化します。

• TLSエラー率
• 証明書期限
• CAフィンガープリント変更
• インスペクション装置のCPU
• 接続キュー
• p95、p99遅延
• バイパス率
• 例外ポリシー増加数
• HTTP/3フォールバック率
• 上流証明書検証エラー
• 管理者によるCA操作
• 機密情報を含むログ

ECHとQUICの対応状況を定期確認する

ECH、QUIC、HTTP/3は、製品アップデートによって対応状況が変わります。

次の項目を定期確認します。

• 製品が対応するTLSバージョン
• ECH対応
• QUIC終端
• HTTP/3検査
• mTLSバイパス
• ピンニングアプリの識別
• アプリ別ポリシー
• 証明書配布方法
• 対応OS
• 対応ブラウザー

インシデント対応手順を準備する

検査用CAの秘密鍵漏えいを想定します。

CA侵害を検知
   ↓
対象CAによる新規発行を停止
   ↓
検査ポリシーを停止または代替経路へ切り替え
   ↓
新しいCAを生成
   ↓
管理端末へ新CAを配布
   ↓
旧CAを失効
   ↓
旧CAを端末から削除
   ↓
影響調査と監査

CA削除を最初に実行すると全社通信障害になる可能性があります。

注意点・よくある誤解

誤解1：TLS 1.3はインスペクションできない

正しくありません。

アクティブにTLSを終端する方式なら、TLS 1.3でも復号できます。

難しくなったのは、サーバー秘密鍵だけで過去の通信を受動的に復号する方式です。

誤解2：証明書検証が成功したので本来のサーバーへ直接接続している

正しくありません。

検査用CAが端末で信頼されていれば、検査装置が生成した証明書も検証に成功します。

発行者と証明書チェーンを確認する必要があります。

誤解3：鍵マークが表示されているので誰にも復号されていない

正しくありません。

鍵マークは、ブラウザーが現在の接続相手とのTLS通信を信頼していることを表します。

現在の接続相手が検査装置である可能性は残ります。

誤解4：Cloudflareを使うことは社員通信への中間者攻撃と同じ

同じではありません。

自社ドメインの正規証明書を使ってCloudflareで終端するリバースプロキシ構成と、任意の外部サイトへ代替証明書を発行するフォワードプロキシ構成は異なります。

誤解5：すべて復号するほど安全になる

正しくありません。

復号範囲を広げるほど、次のリスクも増えます。

• プライバシー侵害
• ログへの秘密情報混入
• CA秘密鍵の価値上昇
• 装置負荷
• アプリ互換性障害
• 単一障害点
• 管理コスト

誤解6：接続できないサイトはすべて除外すればよい

危険です。

攻撃者が意図的に検査不能な通信方式を使えば、除外経路を悪用できます。

除外する場合は、次の補助対策を付けます。

• DNS制御
• IPレピュテーション
• EDR
• アプリ許可リスト
• 接続先制限
• 監査ログ
• 通信量監視

誤解7：curl --insecureで接続できれば解決した

解決していません。

証明書検証を無効化して問題を隠しただけです。

CA配布、証明書チェーン、ホスト名、検査ポリシーを修正します。

誤解8：SSLKEYLOGFILEは本番調査にも使える

RFC 9850は、本番システムで使用してはいけないと明記しています。

秘密ファイルが漏れると、対応するTLS通信を復号されます。

まとめ

TLSインスペクションは、HTTPS通信を復号してWAF、IPS、DLP、マルウェア検査などへ渡す仕組みです。

技術的には、1本のTLS通信を次の2本へ分割します。

クライアント ↔ 検査装置
検査装置     ↔ 本来のサーバー

TLS 1.3でも、検査装置が正規の終端として動作する方式なら復号できます。

ただし、TLS 1.3の前方秘匿性により、サーバー秘密鍵だけで過去の通信を復号する旧来方式は使いにくくなりました。

2026年時点では、次の変化も考慮する必要があります。

• TLS 1.3の基準はRFC 9846
• TLS 1.2は機能凍結
• 新規プロトコルはTLS 1.3が基本
• ECHがSNIなどを暗号化
• HTTP/3がQUIC上で動作
• mTLSやピンニングがインスペクションと衝突
• SSLKEYLOGFILEはテストデータ限定

TLSインスペクションは強力ですが、同時に高権限な復号基盤です。

最適な設計は、すべてを復号することではありません。

必要な通信だけを選択的に復号
            +
DNS・IP・通信量の分析
            +
EDR・DLP
            +
WAF・IPS
            +
アプリケーション監査ログ

この組み合わせにより、TLSの安全性、利用者のプライバシー、業務の可用性、攻撃検知を両立しやすくなります。

FAQ

Q1. TLSインスペクションは中間者攻撃ですか？

暗号技術上の構造は中間者攻撃に似ています。

ただし、組織が管理する端末に正式なCAを配布し、利用者へ通知し、管理された通信経路で実施する点が異なります。

許可、管理、目的、透明性がない場合は、不正な通信傍受になる可能性があります。

Q2. TLS 1.3でも復号できますか？

できます。

検査装置がクライアント側とサーバー側のTLS終端になる方式であれば復号できます。

サーバー秘密鍵を後から使うだけの受動復号は、前方秘匿性によって難しくなりました。

Q3. ECHが有効なら完全に検査できなくなりますか？

一律には判断できません。

ECHはSNIやALPNなどを保護しますが、明示プロキシ、DNSポリシー、端末エージェントなどを使う製品もあります。

製品ごとの対応確認が必要です。

Q4. HTTP/3を止めれば解決しますか？

一部環境ではHTTP/2へフォールバックします。

ただし、遅延増加や一部アプリの停止が起こる可能性があります。

UDP/443を遮断する前に、検証端末で確認してください。

Q5. mTLS通信はインスペクションできますか？

製品と構成によりますが、難しい場合が多くあります。

本来のサーバーがクライアント証明書を直接確認するため、TLSを途中で分割すると認証情報を引き継げない場合があります。

原則として除外を検討します。

Q6. 証明書ピンニングはTLSインスペクション対策になりますか？

検査装置の代替証明書を拒否する効果はあります。

一方で、正規の証明書更新やCA変更でもアプリが停止する可能性があります。

AndroidとAppleの公式資料も、ピンニングを慎重に扱うよう案内しています。

Q7. シークレットモードなら検査されませんか？

検査されます。

シークレットモードは、主に端末内の履歴やCookie保存を制限する機能です。

ネットワーク経路上のTLSインスペクションは回避しません。

Q8. VPNを使えばTLSインスペクションを回避できますか？

構成によります。

企業管理端末では、VPN自体が制御されたり、端末エージェントがVPNの前後で通信を検査したりする場合があります。

許可されていないVPNを使って組織のセキュリティ対策を回避してはいけません。

Q9. 自宅の個人PCにも会社のCAを入れるべきですか？

原則として慎重に判断します。

個人端末へ組織CAを入れると、会社の管理外になった後も信頼設定が残る可能性があります。

可能であれば、会社所有の管理端末を使用します。

Q10. WAFを使うには社員PCへの独自CAが必要ですか？

自社Webサイトを保護する一般的なリバースプロキシ型WAFでは不要です。

WAFは自社ドメインの正規証明書を使ってTLSを終端します。

社員の外部Web閲覧を検査するフォワードプロキシ型とは別です。

Q11. TLSインスペクションなしでIPSは動作しますか？

動作します。

IP、ポート、通信量、接続頻度、TLSメタデータなどを使った検知は可能です。

HTTP本文を使うシグネチャーやファイル検査には復号が必要です。

Q12. TLSインスペクションを導入すればEDRは不要ですか？

不要にはなりません。

TLSインスペクションは通信内容を見ます。

EDRは、通信を発生させたプロセス、ファイル、コマンド、ユーザー操作などを確認します。

両者は役割が異なります。

参考情報

IETF・RFC

RFC 9846：The Transport Layer Security Protocol Version 1.3

2026年7月公開のTLS 1.3基準文書です。RFC 8446を廃止扱いにしています。

https://www.rfc-editor.org/info/rfc9846/

RFC 9851：TLS 1.2 is in Feature Freeze

TLS 1.2を機能凍結とする文書です。

https://www.rfc-editor.org/info/rfc9851/

RFC 9852：New Protocols Using TLS Must Require TLS 1.3

新しいTLS利用プロトコルにTLS 1.3を必須とするBest Current Practiceです。

https://www.rfc-editor.org/info/rfc9852/

RFC 9849：TLS Encrypted Client Hello

ECHによってSNIやALPNなどを保護する仕様です。

https://www.rfc-editor.org/info/rfc9849/

RFC 9001：Using TLS to Secure QUIC

QUICでTLSを利用する方法を定義しています。

https://www.rfc-editor.org/info/rfc9001/

RFC 9114：HTTP/3

QUIC上でHTTPを提供するHTTP/3仕様です。

https://www.rfc-editor.org/info/rfc9114/

RFC 9312：Manageability of the QUIC Transport Protocol

QUICのネットワーク運用と可視性について説明しています。

https://www.rfc-editor.org/info/rfc9312/

RFC 9850：The SSLKEYLOGFILE Format for TLS

TLSセッション秘密情報のログ形式です。本番利用を禁止しています。

https://www.rfc-editor.org/info/rfc9850/

NIST

NIST SP 1800-37：Addressing Visibility Challenges with TLS 1.3 within the Enterprise

企業内部でTLS 1.3の可視性を維持する方式を検証した実践ガイドです。

https://csrc.nist.gov/pubs/sp/1800/37/final

NIST SP 1800-37 FAQ

適用範囲、細粒度ポリシー、非復号通信の分析などを説明しています。

https://www.nccoe.nist.gov/addressing-visibility-challenges-tls-13-within-enterprise-faqs

CISA

HTTPS Interception Weakens TLS Security

HTTPSインターセプション製品がTLSの安全性を低下させる可能性についての警告です。

https://www.cisa.gov/news-events/alerts/2017/03/16/https-interception-weakens-tls-security

Cloudflare

TLS decryption

Cloudflare GatewayのTLS復号、必要な証明書、制限事項を説明しています。

https://developers.cloudflare.com/cloudflare-one/traffic-policies/http-policies/tls-decryption/

SSL/TLS Encryption Modes

利用者とCloudflare、Cloudflareとオリジンの2接続とFull（strict）を説明しています。

https://developers.cloudflare.com/ssl/origin-configuration/ssl-modes/

OpenSSL・curl

OpenSSL s_client

証明書チェーンと検証エラーを調査するコマンドの公式資料です。

https://docs.openssl.org/4.0/man1/openssl-s_client/

curl SSL CA Certificates

curlの証明書検証とCAストアについての公式資料です。

https://curl.se/docs/sslcerts.html

モバイルアプリ

Android Network Security Configuration

カスタムCAと証明書ピンニングについての公式資料です。

https://developer.android.com/privacy-and-security/security-config

Android Security with Network Protocols

証明書ピンニングの運用上の問題を説明しています。

https://developer.android.com/privacy-and-security/security-ssl

Apple Identity Pinning

Appleプラットフォームでのピンニングについての公式資料です。

https://developer.apple.com/news/?id=g9ejcf8y

日本のモニタリング指針

個人情報保護委員会：従業者へのオンラインモニタリングに関する留意点

目的、規程、責任者、運用ルール、従業者への周知などを説明しています。

https://www.ppc.go.jp/all_faq_index/faq1-q5-7