管理対象デバイスが暗号化されたトラフィックを処理する場合にのみ、[復号 - 再署名（Decrypt - Resign）] または [復号 - 既知のキー（Decrypt - Known Key）] のルールをセットアップします。復号ルールには、パフォーマンスに影響を及ぼす可能性があるオーバーヘッドの処理が必要です。

パッシブまたはインライン タップ モード インターフェイスを使用するデバイスでトラフィックを復号化することはできません。

パッシブおよびインライン タップ モードのインターフェイスはサポートされていません。

TLS/SSL トラフィックはパッシブまたはインライン タップ モードのインターフェイスでは復号できません。

TLS 1.3 はサポートされません

Firepower システムは現在、TLS バージョン 1.3 の暗号化または復号化をサポートしていません。ユーザが TLS 1.3 暗号化をネゴシエートする Web サイトにアクセスすると、Web ブラウザに次のようなエラーが表示されることがあります。

• ERR_SSL_PROTOCOL_ERROR

• SEC_ERROR_BAD_SIGNATURE

• ERR_SSL_VERSION_INTERFERENCE

この動作を制御する方法の詳細については、Cisco TAC にお問い合わせください。

次によって禁止されている場合は、トラフィックを復号してはいけません。

• 法律：たとえば、一部の法域では、財務情報の復号化が禁止されています

• 会社のポリシー：たとえば、会社によって特権的な通信の復号化が禁止されている場合があります

• プライバシー規制

• 証明書のピン留め（TLS/SSL ピニングとも呼ばれる）を使用するトラフィックは、接続の切断を防ぐため、暗号化されたままにする必要があります

特定の種類のトラフィックで復号をバイパスする場合、トラフィックの処理は行われません。暗号化トラフィックは最初に SSL ポリシーによって評価され、次にアクセス コントロール ポリシーに進みます。この場合、最終的な許可またはブロックの決定が行われます。暗号化されたトラフィックは、次のものを含むがこれらに限定されない任意の TLS/SSL ルール条件で許可またはブロックできます。

• 証明書のステータス（期限切れまたは無効な証明書など）

• プロトコル（セキュアでない SSL プロトコルなど）

• ネットワーク（セキュリティ ゾーン、IP アドレス、VLAN タグなど）

• 正確な URL または URL カテゴリ

• [ポート（Port）]

• ユーザ グループ

[復号 - 再署名（Decrypt - Resign）] アクションには、1 つの認証局証明書と秘密キーを関連付けることができます。トラフィックがこのルールに一致した場合、システムは CA 証明書を使用してサーバ証明書を再署名してから、中間者（man-in-the-middle）として機能します。ここでは 2 つの TLS/SSL セッションが作成され、1 つはクライアントと管理対象デバイスの間、もう 1 つは管理対象デバイスとサーバの間で使用されます。各セッションにはさまざまな暗号セッションの詳細が含まれており、システムはこれを使用することでトラフィックの復号化と再暗号化が行えます。このアクションは、証明書の秘密キーを各自の管理下にあるキーに置き換えてセッション キーを取得するため、発信トラフィックに適しています。

サーバ証明書の再署名では、証明書の公開キーを CA 証明書の公開キーに置き換えるか、あるいは証明書全体が置き換えられます。通常、サーバ証明書全体を置き換える場合は、TLS/SSL 接続が確立された時点で、証明書が信頼できる認証局によって署名されていないことがクライアント ブラウザで警告されます。ただし、その CA をクライアント ブラウザで信頼できることがポリシーに設定されている場合、ブラウザは証明書が信頼できないことについて警告しません。オリジナルのサーバ証明書が自己署名の場合、システムは証明書全体を置き換えて再署名する CA を信頼しますが、ユーザのブラウザは証明書が自己署名されていることを警告しません。この場合、サーバ証明書の公開キーを交換するだけで、クライアント ブラウザは証明書が自己署名であることを警告します。

[復号 - 再署名（Decrypt - Resign）] アクションをルールに設定すると、ルールによるトラフィックの照合は、設定されている他のルール条件に加えて、参照する内部 CA 証明書の署名アルゴリズム タイプに基づいて実施されます。各 [復号 - 再署名（Decrypt - Resign）] アクションにはそれぞれ 1 つの CA 証明書が関連付けられるので、異なる署名アルゴリズムで暗号化された複数のタイプの発信トラフィックを復号化する TLS/SSL ルールは作成できません。また、ルールに追加する暗号スイートと外部証明書のオブジェクトのすべては、関連する CA 証明書の暗号化アルゴリズム タイプに一致する必要があります。 オプションで、証明書全体ではなく自己署名証明書キーのみを置き換えることができます。この場合、ユーザはブラウザで自己署名証明書キー通知を確認します。

たとえば、楕円曲線暗号（EC）アルゴリズムで暗号化された発信トラフィックが [復号 - 再署名（Decrypt - Resign）] ルールに一致するのは、アクションが EC ベースの CA 証明書を参照している場合だけです。証明書と暗号スイートのルール条件を作成する場合は、EC ベースの外部証明書と暗号スイートをルールに追加する必要があります。同様に、RSA ベースの CA 証明書を参照する [復号 - 再署名（Decrypt - Resign）] ルールは、RSA アルゴリズムで暗号化された発信トラフィックとのみ一致します。EC アルゴリズムで暗号化された発信トラフィックは、設定されている他のルール条件がすべて一致したとしても、このルールには一致しません。

また次の点に注意してください。

匿名の暗号スイートはサポート対象外

匿名の暗号スイートはその性質から、認証には使用されず、キー交換を使用しません。匿名の暗号スイートには限定的な用途があります。詳細については、RFC 5246 のセクション A.5 を参照してください。

匿名の暗号スイートは認証に使用されないため、ルールに [復号-再署名（Decrypt - Resign）] または [復号-既知のキー（Decrypt - Known Key）] アクションは使用できません。

一致しない暗号スイート

証明書と一致しない暗号スイートで TLS/SSL ルールを保存しようとすると、次のエラーが表示されます。この問題を解決するには、TLS/SSL 暗号スイートの確認 を参照してください。

Traffic cannot match this rule; none of your selected cipher suites contain a 
signature algorithm that the resigning CA's signature algorithm

信頼できない認証局

サーバ証明書の再署名に使用する認証局（CA）をクライアントが信頼していない場合、証明書が信頼できないという警告がユーザに出されます。これを防ぐには、クライアントの信頼できる CA ストアに CA 証明書をインポートします。または組織にプライベート PKI がある場合は、組織の全クライアントで自動的に信頼されるルート CA が署名する中間 CA 証明書を発行して、その CA 証明書をデバイスにアップロードすることもできます。

HTTP プロキシの制限

クライアントと管理対象デバイスの間に HTTP プロキシがあって、クライアントとサーバが CONNECT HTTP メソッドを使用してトンネル TLS/SSL 接続を確立する場合、システムはトラフィックを復号化できません。システムによるこのトラフィックの処理法は、ハンドシェイク エラー（Handshake Errors）の復号できないアクションが決定します。

署名済み CA のアップロード

内部 CA オブジェクトを作成して証明書署名要求（CSR）の生成を選択した場合は、オブジェクトに署名付き証明書をアップロードするまで、この CA を [復号 - 再署名（Decrypt - Resign）] アクションに使用できません。

[復号 - 既知のキー（Decrypt - Known Key）] アクションを設定した場合は、1 つまたは複数のサーバ証明書と秘密キー ペアをアクションに関連付けることができます。トラフィックがルールに一致して、トラフィックの暗号化に使用された証明書とアクションに関連付けられた証明書が一致した場合、システムは適切な秘密キーを使用してセッションの暗号化と復号キーを取得します。秘密キーへのアクセスが必要なため、このアクションが最も適しているのは、組織の管理下にあるサーバへの入力トラフィックを復号する場合です。

また次の点に注意してください。

匿名の暗号スイートはサポート対象外

匿名の暗号スイートはその性質から、認証には使用されず、キー交換を使用しません。匿名の暗号スイートには限定的な用途があります。詳細については、RFC 5246 のセクション A.5 を参照してください。

匿名の暗号スイートは認証に使用されないため、ルールに [復号-再署名（Decrypt - Resign）] または [復号-既知のキー（Decrypt - Known Key）] アクションは使用できません。

識別名または証明書が一致しない

[復号 - 既知のキー（Decrypt - Known Key）] アクションを指定して TLS/SSL ルールを作成した場合は、[識別名（Distinguished Name）] や [証明書（Certificate）] 条件による照合はできません。ここでの前提は、このルールがトラフィックと一致する場合、証明書、サブジェクト DN、および発行元 DN は、ルールに関連付けられた証明書とすでに一致済みであることです。

署名アルゴリズムの不一致

[復号 - 再署名（Decrypt - Resign）] アクションをルールに設定し、1 つまたは複数の外部証明書オブジェクトまたは暗号スイートで署名アルゴリズム タイプの不一致が生じた場合、ポリシー エディタでルールの横に情報アイコン（）が表示されます。すべての外部証明書オブジェクトまたはすべての暗号スイートで署名アルゴリズム タイプの不一致が生じた場合、ポリシーのルールの横には警告アイコン（[]）が表示され、SSL ポリシーに関連付けたアクセス コントロール ポリシーは適用できなくなります。

証明書のピン留め

ブラウザが証明書ピニングを使用してサーバ証明書を確認する場合は、サーバ証明書に再署名しても、このトラフィックを復号できません。このトラフィックを許可するには、サーバ証明書の共通名または識別名と一致させるために、[復号しない（Do not decrypt）] アクションを使用して TLS/SSL ルールを設定します。

[インタラクティブ ブロック（Interactive Block）] または [リセット付きインタラクティブ ブロック（Interactive Block with reset）] アクション付きのアクセス コントロール ルールと復号化トラフィックが一致する場合、システムは応答ページを表示します。

ルールでロギングを有効にすると、（[分析（Analysis）] > [イベント（Events）] > [接続（Connections）]で）2 つの接続イベントが表示されます。インタラクティブ ブロックのイベントと、ユーザがサイトの継続を選択したかどうかを示す別のイベントです。

一部のアプリケーションでは、アプリケーション自体に元のサーバ証明書のフィンガープリントを埋め込む、ピニングまたは証明書ピニングと呼ばれる技術が使用されます。TLS/SSL そのため、[復号 - 再署名（Decrypt - Resign）] アクションで TLS/SSL ルールを設定した場合は、アプリケーションが管理対象デバイスから再署名された証明書を受信すると、検証が失敗し、接続が中断されます。

TLS/SSL のピン留めは中間者攻撃を避けるために使用されるため、防止または回避する方法はありません。次の選択肢があります。

• そのアプリケーション用に、[復号-再署名（Decrypt - Resign）] ルールよりも順序が前の、[復号しない（Do Not Decrypt）] ルールを作成します。

• Web ブラウザを使用してアプリケーションにアクセスするようユーザに指示します。

ルールの順序の詳細については、SSL ルールの順序を参照してください。

アプリケーションが TLS/SSL のピン留めを使用しているかどうかを判断するには、TLS/SSL ピニングのトラブルシューティングを参照してください。

一部のアプリケーションでは、RFC6520 で定義されている Transport Layer Security（TLS）および Datagram Transport Layer Security（DTLS）プロトコルに対して、TLS ハートビート エクステンションが使用されます。TLS ハートビートは、接続がまだ有効であることを確認する方法を提供します。クライアントまたはサーバが指定されたバイト数のデータを送信し、応答を返すように相手に要求します。これが成功した場合は、暗号化されたデータが送信されます。

管理対象デバイスが TLS/SSL ハードウェア アクセラレーションをサポートしていない場合、または が無効になっている場合は、ネットワーク分析ポリシー（NAP）で [最大ハートビート長（Max Heartbeat Length）] を設定して TLS ハートビートの処理方法を決定できます。詳細については、SSL プリプロセッサを参照してください。

詳細については、TLS ハートビートについてを参照してください。

匿名の暗号スイートはその性質から、認証には使用されず、キー交換を使用しません。匿名の暗号スイートには限定的な用途があります。詳細については、RFC 5246 のセクション A.5 を参照してください。

匿名の暗号スイートは認証に使用されないため、ルールに [復号-再署名（Decrypt - Resign）] または [復号-既知のキー（Decrypt - Known Key）] アクションは使用できません。

TLS/SSL ルールの [暗号スイート（Cipher Suite）] 条件に匿名の暗号スイートを追加することはできますが、システムは、ClientHello 処理中に自動的に匿名の暗号スイートを削除します。ルールを使用するシステムでは、ClientHello の処理を防止するために TLS/SSL ルールを設定する必要があります。詳細については、SSL ルールの順序を参照してください。

インライン正規化プリプロセッサで [余剰ペイロードの正規化（Normalize Excess Payload）] オプションを有効にすると、プリプロセッサによる復号トラフィックの標準化時に、パケットがドロップされてトリミングされたパケットに置き換えられる場合があります。これで TLS/SSL セッションは終了しません。トラフィックが許可された場合、トリミングされたパケットは TLS/SSL セッションの一部として暗号化されます。

ユーザとグループ

ルールにグループまたはユーザを追加した後、そのグループまたはユーザを除外するようにレルムの設定を変更すると、ルールは適用されなくなります。（レルムを無効にする場合も同様です。）レルムの詳細については、レルムの作成を参照してください。

TLS/SSL ルールのカテゴリ

SSL ポリシーに [復号-再署名（Decrypt - Resign）] アクションがあるにもかかわらず Web サイトが復号されない場合は、そのポリシーに関連付けられているルールの [カテゴリ（Category）] タブ ページを確認します。

場合によっては、認証などの目的で Web サイトが別のサイトにリダイレクトされ、リダイレクト先のサイトの URL カテゴリが復号を試みているサイトとは異なることがあります。たとえば、gmail.com（[Webベース電子メール（Web based email）] カテゴリ）は認証のために accounts.gmail.com（[インターネットポータル（Internet Portals）] カテゴリ）にリダイレクトされます。関連するすべてのカテゴリを必ず SSL ルールに含めます。

ローカル データベースにない URL のクエリ

[復号-再署名（Decrypt - Resign）] ルールを作成し、ローカル データベースにカテゴリとレピュテーションがない Web サイトをユーザが参照すると、データが復号されないことがあります。一部の Web サイトはローカル データベースで分類されません。分類されない場合、その Web サイトのデータはデフォルトでは復号されません。

この動作は [システム（System）] > [統合（Integration）] > の設定を使用し [Cisco CSI]、[不明 URL を Cisco CSI に問い合わせる（Query Cisco CSI for Unknown URLs）] を使用して制御できます。

このオプションの詳細については、シスコ クラウドを参照してください。