TLSインスペクショントラブルシューティング

イントロダクション

この記事は、TLSインスペクションの高度な設定トラブルシューティングシナリオをカバーします。 進行する前に、TLSインスペクション設定と挙動を確認し、トラフィックがどのように処理され、かつ適用されるかを理解することをお勧めします。

標準的な条件では、TLSインスペクションはエンドユーザーに見えません。 トラフィックが検査されているかどうかを確認するには、アカウントイベントのTLSインスペクションフィールドを確認し（1 = 検査済み, 0 = バイパス）、ブラウザで証明書の発行者をレビューするか（Cato Networks）、またはTLSインスペクションレポートを使用します。

Catoは、よく知られたアプリケーション、デバイス、ドメイン向けにデフォルトのバイパスルールを提供します。 これらのシステム管理ルールは編集できず、カスタムルールを作成する前に常に確認する必要があります。 追加の詳細については、デフォルトのバイパスルールをご覧ください。

症状

可能な原因

ほとんどの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://

OpenSSLが利用可能な場合:

openssl s_client -connect :443 -servername

期待される出力（成功）

* TLS1.2 / TLS1.3を使用したSSL接続
* サーバー証明書:
* subject: CN=www.google.com
* issuer: CN=GTS CA 1C3
GET / HTTP/1.1
HTTP/1.1 200 OK

問題が クライアント、宛先サーバー、またはTLSインスペクション設定自体に関連しているかどうかを最初に確認することが重要です。 

一般的な問題のトラブルシューティング

注意：
以下に列挙されている問題は、TLSインスペクション展開で観察される一般的なシナリオを代表しています。 これらのエラーの多くは一般的なものであり、特定の環境に直接適用されるかどうかは不明です。
記述された症状や解決策がケースに一致しない場合、クライアントマシンから診断データ（例：SSS、HAR、およびPCAP）を収集し、詳細な分析のためにサポートチケットを発行することをお勧めします。

アプリケーションのトラブルシューティング 

問題：特定のアプリケーションがセキュアな接続の確立に失敗する、またはTLSインスペクションが有効になった後に動作しなくなる。

期待される動作：
厳格なセキュリティ制御を持つアプリケーション（例：バンキングアプリ、エンドポイントセキュリティツール）は、即座に接続失敗し、静かにクラッシュするか、接続を繰り返し再試行することがあります。 これは、TLSインスペクションが中間者攻撃（MITM）証明書を導入するため、これらのアプリケーションが特に検出して拒否するように設計されているため発生します。

解決策：
ポリシーのトップにあるルールを使用して、単一ユーザーまたは送信元IPに向けたTLSインスペクションのバイパスを検証します。 アプリケーションがバイパス時に動作する場合、ターゲットされた除外（ドメイン/FQDNベース）を作成し、広域的なルールを避けてください。 さらに、CatoのTLSインスペクション設定ウィザードを使用して、最小限の設定でセンシティブなドメインをバイパスすることができます。 

アプリケーションやサーバーが証明書のピンニングや厳密なTLS要件を強制する場合、TLSインスペクションを適用することはできません。 そのような場合、正しいアプローチはそのトラフィックを永久にバイパスすることです。

例：
金融アプリがログインに失敗し、そのユーザーに対するTLSインスペクションをバイパスした直後に動作する場合、これは互換性の欠如を確認します - アプリのドメインをバイパスリストに追加します。 

ブラウザ証明書警告のトラブルシューティング

問題：ユーザーが証明書の警告を見るか、TLSインスペクションが有効化されるとアプリケーションが失敗します。

期待される動作：
ユーザーはブラウザ警告（例：“接続がセキュアではありません”）や完全な接続失敗に遭遇するかもしれません。 Cato証明書が適切にインストールされているかどうかに応じて、動作がデバイス間で異なる可能性があります。

解決策：
すべてのエンドポイントにCato TLSインスペクションのルート証明書がインストールされていて信頼されていることを確認します。 GPO/MDMを使用して展開し、クライアントでフル証明書チェーンを確認します。

プライベートまたは内部の証明書が使用されている場合、それらが適切に信頼されているか、関連するTLSインスペクションの証明書処理手順に従うことを確認してください。

動作が一貫していない場合、単一のユーザーまたはデバイスに対してTLSインスペクションをバイパスして、証明書関連の影響を確認することで検証します。

組織内でプライベート証明書を使用している場合、TLSインスペクションを使用したプライベート証明書によるトラフィック保護を参照してください。 

ホスト名の不一致のトラブルシューティング

問題：ユーザーが特定のウェブサイトにアクセスする際、特にTLSインスペクションが有効な場合に、ホスト名の不一致による証明書エラーやブロックされた接続に遭遇します。

期待される動作：
サーバーが要求されたホスト名と一致しない一般名（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依存関係を持つモダンなウェブアプリで観察されます。

解決策:
特定のユーザーまたは送信元IPアドレスのTLSインスペクションをバイパスして検証します。 サイトがバイパスされている場合、対象となるドメイン/FQDN除外を作成します。

広範なバイパスルールを避け、必要なドメインにのみ除外をスコープしてください。

アプリケーションが厳密なセキュリティメカニズムに依存している場合（例: ピン留めされた証明書や高度なTLS処理）、インスペクションがサポートされない可能性があります。バイパスすることが正しいアプローチです。

シナリオ – 最新のWebアプリケーション（SaaS）:
一部のSaaSプラットフォーム（例: 複数のバックエンドドメイン/CDNを持つアプリ）は部分的に読み込まれることがあります（UIは機能し、APIは失敗します）。 これらの場合、HAR/DevToolsで必要なドメインをすべて特定し、バイパスルールに完全なカバレッジを確保してください。

Cato証明書検証エラーのトラブルシューティング

問題:ブラウジングやアプリケーションの使用中に、CatoのTLS関連のエラーが表示されます。

期待される動作

ユーザーは次のような一般的なエラーに遭遇する可能性があります: 

  • "安全な接続に失敗しました"
  • "証明書が信頼されていません"
  • 予期しない接続のリセットまたはドロップ

これらのエラーは通常、クライアント、サーバー、またはTLSインスペクションプロセスのどこから問題が発生したか明確に示さない、特定されていないエラーです。

解決策:
単一のユーザーまたは送信元IPに対してTLSインスペクションを一時的にバイパスして動作を検証します。

  • バイパスして問題が解決される場合、これはインスペクション中の証明書検証失敗を確認します。
  • 中間または発行CAが認識されていない場合、これは証明書がCatoの信頼できる証明書バンドルにまだ含まれていない可能性があります。

一時的な対策として、影響を受けているドメイン/アプリケーションのTLSインスペクションをバイパスすることを推奨し、サポートケースを開いてください。

Catoは業界標準に沿って、信頼できる証明書バンドルを継続的に更新し、最も一般的に使用される証明書当局を含んでいます。 証明書が有効で広く信頼されている場合、今後の更新で追加される可能性があります。

恒久的な対策は以下に集中すべきです:

  • サーバーが完全で有効な証明書チェーンを提示することを保証する
  • よく知られた信頼できるCAによって発行された証明書を使用する

サーバーが無効または不完全な証明書チェーンを提示した場合、TLSインスペクションは正しく接続をブロックします。 恒久的な対策として、サーバーサイドで対応するか、必要であればTLSインスペクションをバイパスします。

新たに信頼される/最近公開されたドメイン

新しく公開された、最近更新された、またはインターネット上で再分類されたドメインは、すべての信頼エンジン、証明書当局、または信頼ストアで一貫して認識されていない場合があります。

これにより、TLSの失敗だけでなく、インターネットファイアウォールポリシーによるセキュリティ施行や不完全な証明書信頼によってトラフィックがブロックまたはフラグされることがあります。

期待される動作:
そのようなドメインは:

  • セキュリティエンジン間で誤分類されたり、一貫性のないカテゴリに分類されたりする可能性があります
  • 完全に伝播されていない、または世界的に信頼されていない証明書を提示する可能性があります
  • 完全な信頼チェーンの欠如によりインスペクション中にTLSエラーを発生させる可能性があります
  • 実際の接続問題ではなく、ポリシーに基づいてブロックされる可能性があります

ドメインがアクティブになるか変更後に行われることが一般的です。

解決策:

  • Endpointから直接証明書を検証して正当性を確認します
  • ドメインが安全と確認される場合:
    • ポリシー要件に基づいて許可されたカテゴリに再分類するか、
    • 対象となる許可/バイパスルール（広範な除外を回避）を作成します
  • 可能な場合にのみ、バイパスルールを一時的なものとして扱います
  • 評判と証明書の信頼が世界中で完全に確立された後にドメインを再評価します

重要な注記:
ドメインが正当でも、証明書の不完全な伝播によりTLS関連のエラーが発生する可能性があります。 これらのケースでは、動作が期待されているため、誤設定ではなく、制御されたポリシー調整によって処理されるべきです。

シナリオ – 不完全な証明書チェーン:
サイトがブラウザで直接機能する（キャッシュされた中間ファイルによる）が、TLSインスペクションで失敗する場合があります。 これはサーバーが完全な証明書チェーンを提示していないことを示しています。 解決策はサーバー設定を修正するか、ドメインをバイパスすることです。

サポートされていないプロトコルとレガシーシステム

問題:
時代遅れのTLSバージョンまたは弱い暗号スイーツを使用しているアプリケーションまたはシステムの接続が失敗します。この場合、TLSインスペクションの対象外です。

期待される動作:
失敗は通常、TLSハンドシェイク中に発生し、ブラウザやクライアントに直接表示されます。

一般的なブラウザエラーは次の通りです:

  • ERR_SSL_PROTOCOL_ERROR
  • ERR_EMPTY_RESPONSE
  • ERR_SSL_VERSION_OR_CIPHER_MISMATCH
  • ERR_CONNECTION_CLOSED
  • 400 Bad Request
必須のSSL証明書が送信されませんでした

場合によっては:

  • ページが完全に読み込まれないかもしれません
  • 接続が直ちにリセットされる可能性があります
  • 制約を抱えたクライアントやレガシーアプリケーションは、静かに失敗するか一般接続エラーを表示する可能性があります

これは、クライアントまたはサーバーがMITMとしてのCato PoPと互換性のあるTLSバージョンまたは暗号スイーツを交渉できないために発生します。

イベントで、TLSエラー説明フィールドに具体的な情報が入っていることも確認されます。 

エラーの詳細についてはTLSエラーの理解を参照してください。 

解決策:

  • 特定のユーザーまたは送信元IPに対してTLSインスペクションを一時的にバイパスして動作を検証します。
  • アプリケーションがバイパス時に機能する場合、これはインスペクション中のTLS交渉不一致を確認します。

次に、外部ツール（https://www.ssllabs.com/ssltest/）を使用してTLSの機能を検証します

TLSインスペクションポリシーと結果を比較します:

  • 許可された最小TLSバージョン
  • 暗号スイート施行レベル

確認される場合:

  • アプリケーションまたはサーバーを更新またはアップグレードして、最新のTLSバージョンと強力な暗号スイーツをサポートします
  • アップグレードが現実的でない場合、影響を受けたアプリケーションやドメインに対してターゲットTLSインスペクションのバイパスを構成します

注:
デフォルトでは、Catoは幅広いTLSバージョンと暗号スイートを許可します。 ただし、管理者はTLSインスペクションポリシーで厳しい制御を強制できます（例: 最小TLSバージョン、暗号の強度）。これにより、レガシーアプリケーションが失敗する可能性があります。 詳細についてはこちらをお読みください

 

シナリオ – レガシー内部アプリケーション:
内部またはサードパーティのレガシーアプリケーションは、TLSインスペクションを有効にしている場合にのみ失敗し、バイパス時には機能します。 これにより、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ルールの設定。
  • 問題を再現して、サポートセルフサービスを実行します。 ツールによって生成されたチケット番号を含めてください。

 

この記事は役に立ちましたか？

0人中0人がこの記事が役に立ったと言っています

0件のコメント