TLSインスペクションでアプリが動かない原因は？証明書ピニング・DoH競合まで4ステップで切り分け解決

トラブルシューティングを始める前に、なぜTLSインスペクションがアプリケーションの動作に影響を与えるのか、その背景にある主な原因を理解しておくことが重要です。問題の多くは、セキュリティを強化するための仕組み同士が意図せず競合してしまうことによって発生します。

証明書ピニングは、アプリケーションが特定のサーバー証明書のみを信頼するセキュリティ機能です。アプリ内に正当な証明書の情報を埋め込んでおき、通信時にサーバーから提示された証明書がその情報と一致するかを検証します。これにより、中間者攻撃（MitM攻撃）による通信の盗聴や改ざんを防ぎます。

しかし、TLSインスペクション自体が一種の中間者攻撃と同様の仕組みで動作するため、証明書ピニングを実装しているアプリとは非常に相性が悪くなります。

TLSインスペクションでは、Proxyやファイアウォールが本来のサーバー証明書を自身の証明書で置き換えてクライアントに提示します。アプリ側は、この置き換えられた証明書を「不正な証明書」と判断し、通信を自ら切断してしまうのです。これが、ブラウザでは問題ないサイトが、特定のアプリではエラーになる典型的な原因です。

企業ネットワークでは、セキュリティ強化のためにデバイス認証としてクライアント証明書を利用するケースがあります。クライアントはサーバーにアクセスする際、自身の身分を証明するためにクライアント証明書を提示します。

TLSインスペクションのプロセスにおいて、通信が一度復号され、再度暗号化される過程で、このクライアント証明書の情報が正しくサーバーに伝わらないことがあります。製品によっては、認証に必要なヘッダーが欠落したり、証明書そのものがサーバーに渡されなかったりして認証に失敗し、結果としてアプリが正常に動作しなくなります。

Web通信の標準はHTTP/2やTLS 1.2/1.3ですが、すべてのアプリがこれに準拠しているわけではありません。

最新のセキュリティアプライアンスは、これらの特殊なプロトコルや脆弱な暗号化通信の復号に対応していなかったり、ポリシーによって意図的にブロックしたりすることがあります。その結果、該当アプリの通信が確立できず、動作不良を引き起こします。

Secure DNSは、DNSの名前解決を暗号化する技術（DNS over HTTPS/TLS）です。ユーザーのプライバシーを保護しますが、この仕組みが従来のネットワークセキュリティ機器と競合する場合があります。

多くのファイアウォールやProxyは、宛先のドメイン名（FQDN）に基づいて通信を制御します。この情報は、通常、平文のDNS（UDP/53）クエリを監視して取得しています。DoHが有効になると、DNSクエリ自体がHTTPSで暗号化されるため、セキュリティ機器は宛先ドメインを特定できなくなります。

結果として、正しいセキュリティポリシー（TLSインスペクションの対象/除外など）を適用できず、通信がブロックされる問題が発生します。

問題の原因となりうる要素を理解した上で、実際にトラブルシューティングを進めていきましょう。以下のステップに沿って調査することで、効率的に原因を特定できます。

最初に行うべきは、問題の影響範囲を正確に把握することです。これにより、原因が個別のクライアントにあるのか、ネットワーク全体にあるのかを切り分けられます。

TLSインスペクションを機能させる大前提は、クライアントデバイスがセキュリティ製品（Proxy/FW）のルート証明書を信頼していることです。

問題が発生しているデバイスの証明書ストアを確認し、組織で配布しているルート証明書が「信頼されたルート証明機関」として正しくインストールされているかを確認しましょう。

証明書が存在しない、または信頼されていない場合は、まずこれを正しくインストールします。MDMなどで一括配布している場合は、配布ポリシーがそのデバイスに正しく適用されているかも確認が必要です。

原因がTLSインスペクションそのものにあるのかを確定させる、最も効果的で確実な方法が「一時的な除外」です。

ファイアウォールやProxyのポリシー設定で、問題のアプリの通信（宛先ドメインやIPアドレス）を、一時的にTLSインスペクション（SSL復号）の対象から除外します。

この切り分けは、その後の調査の方向性を決める上で極めて重要です。

原因がTLSインスペクションにあると特定できたら、セキュリティ製品のログで詳細を調査します。

ファイアウォールやProxyの管理画面で、対象クライアントからの通信ログを確認します。特に「ブロック」「拒否」「ドロップ」といったアクションや、SSL/TLSハンドシェイクに関するエラーログ（例：「Unsupported Cipher Suite」）を探します。

ログだけでは情報が不十分な場合は、パケットキャプチャを行います。クライアント側（Wireshark等）とセキュリティ製品側で同時にキャプチャし、TLSハンドシェイクのどのメッセージで通信が切断されているかを確認することで、原因の特定に大きく近づけます。

切り分けによって特定された原因に応じて、適切な解決策を講じます。多くの場合、セキュリティと利便性のバランスを考慮した設定変更が必要になります。

証明書ピニングが原因の場合、セキュリティ製品側での根本解決は困難です。現実的な対応策は、そのアプリケーションの通信をTLSインスペクションの対象から除外することです。

ZscalerやPalo Alto Networksなどの主要製品では、宛先ドメイン名、IPアドレスなどで柔軟に除外ポリシーを設定できます。アプリ提供元が公開している通信要件（ホワイトリスト）を参考に、必要最小限の範囲で除外設定を行いましょう。Microsoft 365やGoogle Workspaceなど、多くのベンダーが除外推奨ドメインリストを公開しています。

ただし、除外設定を行うと、その通信経路におけるセキュリティ機器によるマルウェア検知や情報漏洩対策が機能しなくなるため、リスク評価を行い、妥当性を判断してください。

クライアント証明書認証が原因の場合も、TLSインスペクションからの除外が最もシンプルで確実な解決策となります。認証が必要なサーバーへの通信を復号対象から外すことで、クライアントとサーバー間の直接的な証明書のやり取りを妨げないようにします。

製品によっては、クライアント証明書認証の通信をパススルーする高度な設定も可能ですが、まずは除外設定での対応を検討しましょう。

ネットワーク内のクライアントがDoHを使い、ポリシー制御に問題が生じている場合、組織としてDoHの利用を制御する必要があります。

ルート証明書のインストール漏れが原因だった場合は、組織内のすべての対象デバイスに証明書を配布するプロセスを見直しましょう。MDMやActive Directoryのグループポリシーを活用し、自動配布の仕組みを確立することが望ましいです。

また、ルート証明書には有効期限があります。期限切れが近づいたら、新しい証明書を作成し、事前にクライアントへ再配布する計画を立てておくことが不可欠です。

ここでは、代表的なSASE/NGFW製品であるZscalerとPalo Alto Networksを例に、設定のポイントを紹介します。

クラウド型セキュアWebゲートウェイのZscalerでは、管理コンソールの「Web Insights」でリアルタイムに近いログを確認でき、ブロック理由や適用ポリシーが一目でわかります。

除外設定は「SSLインスペクションポリシー」で行います。Microsoft 365の「One Click設定」のように、主要SaaSアプリの除外設定を簡単に適用できる機能も便利です。証明書ピニングが疑われるアプリは、このポリシーでインスペクションから除外します。

Palo Altoの次世代ファイアウォールでは、「復号ポリシー」でTLSインスペクションを制御します。トラフィックログや復号ログで、復号の失敗原因を調査できます。

Palo Altoの強みは、アプリケーションを識別する「App-ID」との連携です。特定のアプリ（例：LINE）を指定して「復号しない（no-decrypt）」というポリシーを柔軟に作成できます。証明書ピニングが原因の場合は、該当のApp-IDに対して復号除外ポリシーを作成するのが一般的な対処法です。

TLSインスペクション環境でアプリが動かなくなる問題は、セキュリティ強化の過程で避けては通れない課題です。その原因は、証明書ピニングやクライアント証明書、Secure DNSとの競合など多岐にわたります。

効果的なトラブルシューティングの鍵は、体系的な切り分けです。

このフローを実践することで、根本原因にたどり着くことができます。特定された原因に対しては、多くの場合、対象の通信をインスペクションから「除外設定」することが現実的な解決策となります。ただし、セキュリティと利便性はトレードオフの関係にあるため、除外は必要最小限の範囲に留めることが重要です。

ゼロトラストセキュリティの実現に向けて通信の可視化がますます重要になる中、本記事で紹介した切り分け手順を参考に、問題解決の第一歩を踏み出してみてください。