導入
この記事は、TLSインスペクションの高度な設定シナリオのトラブルシューティングについて説明しています。続行する前に、TLSインスペクション設定と動作を確認し、トラフィックがどのように処理されているかを理解することをお勧めします。
通常、TLSインスペクションはエンドユーザーには見えません。トラフィックが検査されているか確認するためには、アカウントイベントのTLSインスペクションフィールド（1 = 検査済み, 0 = バイパス）を確認するか、ブラウザ内の証明書発行者（Cato Networks）をレビューするか、TLSインスペクションレポートを使用します。
Catoは有名なアプリケーション、デバイス、およびドメイン向けにデフォルトのバイパスルールを含んでいます。これらのシステム管理ルールは編集できず、カスタムルールを作成する前に常に確認する必要があります。詳細については、デフォルトのバイパスルールを参照してください
症状
ブラウザのTLS / 証明書エラー
ユーザーは次のようなエラーを見ることができます：「接続はプライベートではありません」
「安全な接続に失敗しました」
ERR_SSL_PROTOCOL_ERRORERR_SSL_VERSION_OR_CIPHER_MISMATCHERR_EMPTY_RESPONSE
可能な原因
ほとんどのTLSインスペクションの問題は、いくつかの一般的な状況に関連しています。
一部のアプリケーションはTLSインスペクションと互換性がありません。証明書のピン留め、厳密なTLS検証、または相互TLSを使用するアプリケーションは、インターセプションを拒否して接続に失敗します。
クライアント上の証明書信頼の問題が別の頻繁な原因です。 Catoルート証明書が欠落している、信頼されていない、または一貫して展開されていない場合、設定が正しいにもかかわらず、検査されたトラフィックは失敗します。
他のケースでは、問題は宛先サーバーから発生します。期限切れの証明書、不完全なチェーン、ホスト名の不一致、または不明な証明書当局などの問題は、TLSインスペクションが有効なときにはブラウザに表示されないことがありますが、PoPによって強制されます。
レガシーシステムは、TLSプロトコルまたは暗号の不一致によって失敗する可能性があります。時代遅れのTLSバージョンや弱い暗号スイートを使用するアプリケーションは、TLSインスペクションポリシーで定義された要件を満たしていない可能性があります。
モダンなウェブサイトも、複数の依存するドメインが原因で問題を引き起こす可能性があります。メインドメインのみが許可またはバイパスされている一方で、サポートドメインがブロックされているか異なる方法で検査されている場合、ユーザーは読み込みが遅いまたはコンテンツが見当たらないことを経験する可能性があります。
最後に、プラットフォーム固有の動作が役割を果たします。モバイル端末、BYODエンドポイント、およびLinuxシステムは、証明書信頼の制限、アプリケーション固有の検証、またはデフォルトのバイパスルールのために異なる動作をする可能性があります。
初期トラブルシューティング
TLS関連の問題を調査する際の主な目標は、問題がクライアント、ネットワーク（TLSインスペクション）、宛先サーバーのどこから発生しているかを特定することです。
1. 範囲を特定する
問題がクライアント固有かどうかを検証することから始めます。同じURLをテストします：
別のブラウザから
同じネットワーク上の別のデバイスから
同じデバイスから、異なるネットワーク上で（例：ホットスポット）
特定のブラウザーやデバイスに限られている場合、これは通常ローカル信頼または設定の問題を示しています。ネットワーク外で正常に動作する場合、問題はTLSインスペクションまたはポリシーの施行に関連している可能性があります。
2. TLSインスペクション／証明書の発行者を確認する
ブラウザから：
DevToolsを開き、セキュリティタブに移動するか、ロックアイコンをクリックします
証明書チェーンを検査します
発行者を確認します：
プロキシ／エンタープライズCA（例：Cato） → TLSインスペクションがアクティブ
公開CA（例：DigiCert、Let’s Encrypt） → 直接TLSセッション
3. クライアントで証明書の信頼性を検証する
Catoルート証明書がエンドポイントに正しくインストールされていることを確認してください。
ルート証明書がOSトラストストアにあるか確認します：
Windowsでは、コンピューター証明書マネージャーを開くには
certlm.mscと入力し、信頼されたルート証明機関の下にルート証明書を検索してくださいMacでは、キーチェーンアクセスを開いてシステムキーチェーンの下にルート証明書を探してください
システムの日時を確認します
エンドポイントにCatoルート証明書がない場合、ダウンロードして、デバイスへのCato証明書のインストールに従ってインストールします
欠落または不正確な信頼設定により、即座にTLSの失敗が発生します。
4. クライアントからTLSハンドシェイクをテストする
クライアントサイドツールを使用してTLS接続をシミュレートし、どこでなぜハンドシェイクが失敗するのかを正確に特定します。これらのツールは、一般的なブラウザメッセージの背後に隠されたエラーを露呈します。
影響を受けたエンドポイントから以下または類似のものを実行します：
curl.exe -v https://<domain>OpenSSLが利用可能な場合：
openssl s_client -connect <domain>:443 -servername <domain>予想される出力（成功）
* TLS1.2 / TLS1.3を使用したSSL接続
* サーバー証明書：
* 件名: CN=www.google.com
* 発行者: CN=GTS CA 1C3
> HTTP/1.1のGET
< HTTP/1.1 200 OK最初に、問題がクライアント、宛先サーバー、またはTLSインスペクション設定に関連しているかどうかを判断することが重要です
よくある問題のトラブルシューティング
注：
以下に挙げる問題は、TLSインスペクションの展開時に観察される一般的なシナリオを示しています。これらのエラーの多くは一般的なものであり、特定の環境に直接適用されるかどうかは不明です。
記載された症状や解決策がケースに合わない場合は、クライアントマシンからの診断データ（例：SSS, HAR, and PCAP）を収集し、詳細な分析のためにサポートチケットを提出することをお勧めします
失敗したアプリケーションのトラブルシューティング
問題: 特定のアプリケーションが安全な接続を確立することができず、TLSインスペクションが有効になると動作を停止します。
行動期待:
厳密なセキュリティコントロールを持つアプリケーション（例：銀行アプリ、エンドポイントセキュリティツール）は、即座に接続失敗することがあり、沈黙のうちにクラッシュしたり、接続を何度も再試行したりしますこれは、TLSインスペクションが中間者攻撃（MITM）の証明書を導入するため、これらのアプリケーションが特に検出して拒否するように設計されているためです
解決策:
ポリシーの先頭にあるルールを使用して、単一のユーザーまたは送信元IPについてTLSインスペクションをバイパスすることで確認します。アプリケーションがバイパスされたときに動作する場合は、ターゲットされた除外（ドメイン/FQDNベース）を作成し、広範なルールを避けます。さらに、CatoのTLSインスペクション設定ウィザードを使用して、最小限の設定でセンシティブなドメインをバイパスできます。
アプリケーションまたはサーバーが証明書のピンナップまたは厳密なTLS要求を施行する場合、TLSインスペクションは適用できません。そのような場合、正しいアプローチはそのトラフィックを永久にバイパスすることです。
例:
金融アプリがログインに失敗し、そのユーザーに対してTLSインスペクションをバイパスした後でただちに動作する場合、これは非互換性を確認するものです。そのアプリドメインをバイパスリストに追加します。
ブラウザの証明書警告のトラブルシューティング
問題: TLSインスペクションが有効になった後、ユーザーが証明書の警告を確認したり、アプリケーションが失敗したりします。
行動期待:
ユーザーはブラウザの警告（例：「接続が安全ではありません」）に遭遇したり、完全な接続失敗を経験する可能性があります。動作は、Cato証明書が正しくインストールされている場合によってデバイス間で異なるかもしれません。
解決策:
Cato TLSインスペクションルート証明書がすべてのエンドポイントにインストールされ、信頼されていることを確認してください。 GPO/MDMを使用してデプロイし、クライアント上の完全な証明書チェーンを検証します。
プライベート/内部証明書が使用されている場合、適切に信頼されていることを確認するか、関連するTLSインスペクション証明書取り扱い手続きを取ります。
動作が一貫していない場合、単一のユーザーまたはデバイスに対してTLSインスペクションをバイパスすることで検証し、証明書に関連した影響を確認します。
プライベート証明書を使用している場合は、プライベート証明書を使用したTLSインスペクションによるトラフィックの保護を参考にしてください。
ホスト名の誤一致のトラブルシューティング
問題: 特定のウェブサイトにアクセスするときにユーザーがホスト名の誤一致による証明書エラーまたはブロックされた接続に遭遇し、特にTLSインスペクションが有効なときに発生します。
行動期待:
サーバーがリクエストされたホスト名と一致しないCommon Name（CN）またはSANを持つ証明書を提示する場合、接続は無効と見なされます。
TLSインスペクションがない場合、ブラウザはこの不一致を直接検出し、証明書の警告を表示します。
TLSインスペクションが有効になっている場合、ブラウザは元のサーバーではなくCato PoPとTLSセッションを確立します。 PoPはCatoルートCAを使用して証明書に再署名し、クライアントに有効なように見せます。その結果、問題がバックエンドに存在するにもかかわらず、ブラウザに不一致が表示されることはありません。
解決策:
特定のユーザーまたは送信元IPについてTLSインスペクションをバイパスすることで動作を検証します。その後、ブラウザがホスト名の不一致エラーを表示すると、問題が宛先サーバーから発生していることが確認されます。
不一致はサーバーの証明書設定によって引き起こされるため、TLSインスペクションで修正することはできません。適切なアクションは次のいずれかです：
特定のドメインのTLSインスペクションをバイパスすることでアクセスを許可する、または
不一致がセキュリティリスクと見なされる場合、ポリシーに基づいてトラフィックをブロックする
広範なバイパスルールを避け、必要なドメイン/FQDNの除外を使用します。
例:https://www.testingmcafeesites.com/にアクセスする際、サーバーはplatformsplat1.mcafee.comの証明書を提示します。
TLSインスペクションがない場合、ブラウザは直ちにホスト名不一致を警告します。
TLSインスペクションが有効な場合、ブラウザはwww.testingmcafeesites.com向けCatoルートCAによって発行された有効な証明書を見るので、エラーは表示されません。しかし、Cato PoPはバックグラウンドで不一致を検出し、設定されたポリシー（ブロックまたは警告）を施行します。
ウェブサイトまたはアプリケーションの読み込み問題のトラブルシューティング
問題: TLSインスペクションが有効なときにウェブサイトが読み込まれない、部分的に描画される、または期待されない動作をする。
行動期待：
ページが固まったり、無限ロードしたり、部分的に描画されることがあります
ログイン/認証フローが失敗したり、ループしたりすることがあります
一部のサイトは、TLS解読/再暗号化のオーバーヘッドのため遅く表示される可能性があります
動作が一貫していない（例：あるネットワークで動作し、Catoを経由すると失敗する）ことが多い
これは厳密なセキュリティコントロールを使用したり、複雑なTLS依存関係を持つ現代のWebアプリによく現れる傾向があります。
解決策:
特定のユーザーまたは送信元IPについてTLSインスペクションをバイパスすることで確認します。サイトがバイパスされたときに動作する場合、ターゲットされたドメイン/FQDN除外を作成します。
広範なバイパスルールを避け、必要なドメインにのみスコープ除外を使用します。
アプリケーションが厳密なセキュリティメカニズム（例：ピン止めされた証明書や高度なTLS処理）に依存している場合は、インスペクションはサポートされない可能性があるため、バイパスが正しいアプローチです。
シナリオ – モダン・ウェブ・アプリケーション（SaaS）:
一部のSaaSプラットフォーム（例：複数のバックエンドドメイン/CDNを持つアプリ）は部分的に読み込み（UIは動作、APIは失敗）されることがあります。このような場合は、HAR/DevToolsを通じて必要なすべてのドメインを特定し、バイパスルールで完全にカバーされるようにします。
Cato証明書検証エラーのトラブルシューティング
問題: ブラウジングまたはアプリケーション使用中に、CatoのTLS関連エラーが表示されます。
振る舞いの期待：
ユーザーは次のような一般的なエラーに遭遇する可能性があります:
"セキュア接続に失敗しました"
"証明書が信頼されていません"
予期しない接続のリセットまたはドロップ
これらのエラーは通常、特定の原因を明示せず、問題がクライアント、サーバー、またはTLSインスペクションプロセスから発生しているかを明確には示しません。
解決:
振る舞いを検証するために、一人のユーザーまたはソースIPのTLSインスペクションを一時的にバイパスします。
バイパスした際に問題が解決する場合、これは検査中の証明書検証の失.fail.を確認します
中間または発行CAが認識されない場合、Catoの信頼された証明書バンドルにまだ含まれていない証明書の可能性があります
一時的な対応策として、影響を受けたドメイン/アプリケーションのTLSインスペクションをバイパスしつつ、サポートケースを開きます。
Catoは業界標準およびよく使用される認証機関に基づき、信頼された証明書バンドルを継続的に更新します。証明書が有効かつ広く信頼されている場合、次のアップデートで追加される可能性が高いです。
永続的な修正は以下に集中すべきです：
サーバーが完全かつ有効な証明書チェーンを提示するようにする
よく知られた信頼のおけるCAから発行された証明書を使用する
サーバーが無効または不完全な証明書チェーンを提示した場合、TLSインスペクションは正しく接続をブロックします。修正はサーバー側で行う必要があり、必要に応じてTLSインスペクションをバイパスします。
新たに信頼された/最近公開されたドメイン
インターネット上で新たに公開された、最近更新された、または再分類されたドメインは、すべての評価エンジン、証明機関、信頼ストアで一貫して認識されていないことがあります。
これはトラフィックがブロックまたはフラグされるシナリオにつながる可能性があります—単にTLSの失敗によるものではなく、インターネットファイアウォールポリシーによるセキュリティ施行や不完全な証明書信頼が原因です。
振る舞いの期待:
このようなドメインは次の可能性があります：
セキュリティエンジン間で誤分類されたり、一貫性のないカテゴリ分けをされる
証明書が完全に普及していないか、グローバルに信頼されていないものを提示する
不完全な信頼チェーンのためにインスペクション中にTLSエラーを引き起こす
実際の接続性の問題ではなく、ポリシーに基づいてブロックされる
この振る舞いは通常、ドメインがアクティブになった直後や変更を受けた後に見られます。
解決策：
アクセスポイントから直接証明書の有効性を確認して正当性を確認します
ドメインが安全と確認された場合：
ポリシー要件に基づいて許可カテゴリに再分類するか、
ターゲットの許可/バイパスルール を作成します (広範な除外は避ける)
バイパスルールを可能な限り一時的なものとして扱う
ドメインの評判と証明書信頼が世界的に確立された後、再評価を行います
重要注意:
たとえドメインが正当であっても、不完全な証明書普及はTLS関連のエラーを引き起こす可能性があります。これらのケースでは、振る舞いは予想されるものであり、誤設定ではなく制御されたポリシー調整で対処すべきです。
シナリオ – 不完全な証明書チェーン:
サイトがブラウザでは動作する可能性があります (キャッシュされた中間証明書による)、しかしTLSインスペクション中に失敗します。このことは、サーバーが完全な証明書チェーンを提示していないことを示しています。解決策は、サーバー設定を修正するか、ドメインをバイパスすることです。
非サポートのプロトコルおよびレガシーシステム
問題:
アウトデートしたTLSバージョンまたはTLSインスペクション下でサポートされていない弱い暗号スイートを使用するアプリケーションやシステムの接続が失敗します
振る舞いの期待:
失敗は通常、TLSハンドシェイク中に発生し、ブラウザまたはクライアントで直接確認可能です。
一般的なブラウザエラーには以下が含まれます：
ERR_SSL_PROTOCOL_ERRORERR_EMPTY_RESPONSEERR_SSL_VERSION_OR_CIPHER_MISMATCHERR_CONNECTION_CLOSED400 Bad Request 必要なSSL証明書が送信されませんでした
いくつかの場合：
ページが完全に読み込めないことがあります
接続が即座にリセットされることがあります
シッククライアントまたはレガシーアプリケーションが静かに失敗するか一般的な接続エラーを表示する可能性があります
これは、クライアントまたはサーバーが中間者(MITM)として機能するCato PoPと互換性のあるTLSバージョンまたは暗号スイートを交渉できないために発生します
イベントで、TLSエラーの説明項目が特定の情報で入力されていることにも気づくでしょう
エラーの詳細はUnderstanding TLS errorsを参照してください
解決策：
特定のユーザーまたはソースIPのTLSインスペクションを一時的にバイパスして、振る舞いを検証します
アプリケーションがバイパス時に動作する → インスペクション中のTLSネゴシエーションの不一致を確認します
次に、外部ツールを使用してTLSの能力を検証します。例: https://www.ssllabs.com/ssltest/
結果をTLSインスペクションポリシーで比較します：
最小許可TLSバージョン
暗号スイートの適用レベル
確認された場合：
アプリケーションまたはサーバーを更新またはアップグレードして、最新のTLSバージョンと強力な暗号スイートをサポートするようにします
アップグレードが実施できない場合は、影響を受けたアプリケーションまたはドメインのために、ターゲットTLSインスペクションバイパスを設定します
注意：
デフォルトでは、Catoは幅広いTLSバージョンと暗号スイートを許可します。ただし、管理者はTLSインスペクションポリシーを通してより厳しいコントロールを適用することができ (例: 最小TLSバージョンまたは暗号の強度)、これによりレガシーアプリケーションの失敗を引き起こす可能性があります。詳細はこちらをお読みください
シナリオ – レガシー内部アプリケーション:
内部またはサードパーティのレガシーアプリケーションが、TLSインスペクションが有効なCatoを経由する場合にのみ失敗する可能性があり、バイパス時には動作します。これは通常、非推奨のTLSバージョンに依存していることを示しており、アプリケーションのアップグレードまたは恒久的なバイパスが必要です。
OS特有のTLS問題のトラブルシューティング（予想される制限）
問題: 一部のオペレーティングシステムやデバイスタイプ（例: モバイル、BYOD、Linux）での接続性の問題、不整合な振る舞い、またはTLSインスペクションの可視性の欠如。
振る舞いの期待：
振る舞いは、オペレーティングシステムとアプリケーション設計によって大きく変わります。
AndroidおよびLinuxデバイスでは、証明書信頼の制限とアプリケーションの動作のため、TLSインスペクションはデフォルトでバイパスされます。ただし、新しい設定（CMAの高度な設定経由）により、証明書の信頼が適切に確立できる場合、管理者がこれらのプラットフォームでTLSインスペクションを施行することが可能です。
iOSデバイスの場合、TLSインスペクションはサポートされていますが、いくつかのアプリケーション（例: ソーシャルメディアプラットフォーム、Instagram、Facebook、類似アプリ）は、証明書ピニングと既知の非互換性のため、デフォルトでバイパスされます。厳格な検証を強制するその他のアプリケーションは失敗する可能性があり、手動バイパス設定が必要です。
一般的に：
ブラウザは、Cato証明書がインストールされると期待どおりに動作します
ネイティブ/モバイルアプリケーションは、証明書ピニングまたは制限された信頼ストアのため即座に失敗する可能性があります
同じデバイス上でさえ、アプリケーションごとに振る舞いが異なることがあります
解決策：
これらの振る舞いは一般に予期されるものでプラットフォームに依存しており、誤設定を示しているわけではありません。
TLSインスペクションは、管理されたデバイスに主に適用し、証明書の展開がコントロールされるようにします
MDMソリューションを使用して、Cato証明書をシステムレベルでインストール(サポートがある場合)します
よく知られたアプリケーションとプラットフォームのためのデフォルトバイパスルールを認識しておきます
証明書ピニングや厳格な検証により失敗するアプリケーションには、ターゲットTLSインスペクションバイパスを設定します
AndroidやLinuxのようなプラットフォームにTLSインスペクションを施行する際は、広範な展開の前に慎重に互換性を検証します
シナリオ – モバイルアプリの失敗:
モバイルアプリ (例: 銀行またはセキュリティアプリ) がCato上で接続に失敗するが、ブラウザでは動作する場合。アプリは証明書ピニングを強制しており、Cato証明書を信頼していません。これは予測可能な動作であり、そのアプリケーションやサービスでTLSインスペクションをバイパスすることが正しい対応です。
Catoサポートへのケース提出
アプリケーションにコンプライアンスや規制上の理由でTLSインスペクションが必須の場合、またはTLSブロックが予期しないとお考えの際は、サポートチケットにトラブルシューティング手順の結果を投稿してください。チケットには以下の情報を含めてください：
発生した問題の詳細およびユーザーへの全体的な影響。問題を体験しているユーザーのタイムスタンプ/タイムゾーン
関連イベントとファイアウォール/TLSルールの設定。
問題を再現し、サポートセルフサービスを実行しますツールによって生成されたチケット番号を含めてください。
Google検索トラフィックはCASBポリシーによって検査または一致されていません
Google検索トラフィックがCASBポリシーに一致していない場合、これは期待される動作です。 Google検索はCatoのデフォルトのTLSバイパスリストに含まれており、このトラフィックは暗号化解除または検査されません。
Google検索に対するTLSインスペクションは、バックエンド設定変更を通じて有効化できます。必要に応じて、Google検索をTLSインスペクションのスコープに追加するためにサポートチケットをオープンしてください。チケットを投稿する前に、このトラフィックの検査が組織にとって許容可能か、コンプライアンス/法務チームやCISOと内部で確認してください。 Google検索の検査を有効にすると、検索用語を含むフルパスURLが関連するCMA管理者のイベントに表示されます。これがデフォルトで除外されている理由であり、トレードオフが確認され承認されるまでサポートは有効化しません。