ASA CX および Cisco Prime Security Manager 9.2 ユーザ ガイド
SSL/TLS トラフィック フローの管理
SSL/TLS トラフィック フローの管理
発行日;2014/01/06   |   ドキュメントご利用ガイド   |   ダウンロード ;   この章 pdf   ,   ドキュメント全体 pdf    |   フィードバック

SSL/TLS トラフィック フローの管理

HTTPS など一部のプロトコルは、Secure Sockets Layer(SSL)またはその後継バージョンである Transport Layer Security(TLS)を使用して、セキュアな転送のためにトラフィックを暗号化します。 暗号化されたトラフィックは検査できないため、アクセス判断のために上位層のトラフィック特性を考慮したアクセス ルールを適用する場合は、トラフィックを復号化する必要があります。

ここでは、SSL/TLS トラフィック フロー管理と復号化についてさらに詳しく説明します。

SSL/TLS トラフィック管理の概要

SSL/TLS プロトコルは、暗号化によってトラフィックを保護するために広く使用されています。 トラフィックが暗号化されるため、トラフィック インスペクタはトラフィックの内容を判断できません。 ASA CX では、復号化ポリシーを使用してトラフィック フローを復号化するかどうかが決定されます。

SSL/TLS 暗号化されたトラフィックを処理するには、次の選択肢があります。

トラフィックを復号化し、検査し、再暗号化します
トラフィックを暗号化することを選択した場合、ASA CX は中間者として機能します。
  • 着信トラフィックが復号化されます。
  • トラフィックが検査されます。 アクセス ルールが適用されます。
  • トラフィックが許可されると、そのフローのアクセス ポリシーに定義されているすべてのプロファイルが適用され、フローが再暗号化されて、宛先に送信されます。
  • 復路のトラフィックも復号化され、検査された後、再暗号化されてクライアントに送信されます。

トラフィック フローを復号化することにした場合、ユーザは ASA CX 証明書を信頼できるルート認証局として受け入れる必要があります。 詳細については、SSL/​TLS 証明書のダウンロードとインストールを参照してください。


(注)  


トラフィック フローの復号化を選択した場合でも、復号化は単に検査を行えるようにするため実行されるに過ぎません。 ASA CX はフローを再暗号化してから宛先に送信するため、エンドツーエンドのトラフィック フローは暗号化されます。 復号化された内容は他のホストに送信されません。デバイスから出力されること自体がありません。


潜在的に悪意のあるトラフィックを条件付きで複合化します

宛先に割り当てられた Web レピュテーションに基づいて、トラフィックを条件付きで復号化できます。 ある Web レピュテーションが、定義されている低レピュテーション ゾーンに該当する場合、トラフィックは復号化され、他の復号化されたフローと同様に処理されます。 その Web レピュテーションが、高レピュテーション ゾーンに該当する場合、トラフィックは復号化されず、他の復号化されないフローと同様に処理されます。

トラフィックを復号化しません

トラフィックを復号化しなかった場合、ASA CX はトラフィックを検査しません。 ネットワーク グループ、サービス グループ、またはユーザ ID に基づくアクセス ルールがすでに適用されているため、暗号化されたトラフィック フローは復号化ポリシーによって評価される前に、すでに拒否されている可能性があります。

復号化されない暗号化トラフィックの場合、アクセス ルールが適用され、許可またはドロップの決定は、ネットワーク(IP アドレス)、サービス(ポート、TCP/UDP)、およびユーザ アイデンティティ ポリシー オブジェクトなど、公開されているトラフィック フローの特性に基づいて行われます。 URL オブジェクトの場合はドメイン名のみが照合され、その結果 Web カテゴリ照合が行われる場合もありますが、同じ Web サーバまたはドメインで異なるリソースに対して、別個の振る舞いを指定することはできません。 暗号化されたトラフィック フローは、アプリケーションまたはユーザ エージェントのポリシー オブジェクトが含まれた仕様と照合されることはありません。

また、許可されたトラフィック フローに適用するすべてのプロファイルは、暗号化されたトラフィックに対して無視されます。 たとえば、特定のタイプのアップロードまたはダウンロードを回避するファイル フィルタリング プロフィルや、低レピュテーションの Web サイトからのトラフィックをドロップする Web レピュテーション プロファイルを適用することはできません。 暗号化されたフローのコンテンツは不明であるため、暗号化されたフロー全体が許可されます。

次のトピックで、復号化をさらに詳しく説明します。

トラフィックを復号化する理由


ヒント


ASA CX のアクセス ポリシーの目的は、ネットワークでのユーザの行動を検出、モニタリング、測定、および制御することです。 SSL/TLS セッション内部に隠されたプロトコルに対しては、トラフィック フローの復号化も行わない限り、これらをうまく行うことはできません。


暗号化されたトラフィックを復号化するかどうかを選択できます。また、一部のトラフィック フローは復号化して、他は復号化しないように決定することもできます。 トラフィックを復号化するかどうかを検討する際に、暗号化トラフィックのタイプとして最も注目されるのは HTTPS です。

HTTPS は、HTTP の保護された形式として機能する Web プロトコルです。 HTTPS は HTTP 要求と応答を暗号化してから、ネットワーク経由で送信されます。 一般的に、HTTPS を使用しているサイトへの接続は「安全」であると考えられています。HTTPS 接続は保護されていますが、安全というわけではなく、悪意のあるサーバや信頼できないサーバは識別されません。

HTTPS トラフィックを復号化すると、以下を行うことができます。
  • ネットワーク トラフィックを詳しく調べる:使用されているアプリケーションなど、ネットワーク トラフィックをより詳細に調べることができます。 トラフィックを復号化することで、HTTPS を使用してアクセスされた Web サイトについての詳しい情報をダッシュボードに含めることができます。
  • 低レピュテーションの送信元をブロックする:Web レピュテーション プロファイルを使用して、低レピュテーションの送信元でホストされたコンテンツを選択的にブロックすることで、ユーザは保護されると同時に、許可された Web サイトにアクセスできます。
  • 好ましくないファイル交換をブロックする:ファイルのアップロードとダウンロードを選択的にブロックすることで、セキュリティ ポリシーを実装できます。
  • 調査対象の特性に基づいてアクセスを制御する:アプリケーション、タイプ、および振る舞いなど、一部のトラフィック特性は調査でしか把握できないため、トラフィックを最初に復号化する場合にのみ、これらの特性を使用するアクセス ポリシーを適用できます。

トラフィック フローを復号化する

復号化される暗号化トラフィック フローは、次のプロセスを使用して処理されます。

図 1. トラフィック フローを復号化する



  • 1、2:クライアント hello。 クライアント(A)は、目的の宛先(C)へ hello を送信し、暗号化されたセッションを開始します。 トラフィック フローが CX デバイス(B)に入ると、デバイスは宛先サーバに自分の hello を送信します。

    (注)  


    最初のフローが拒否アクセス ポリシーと(たとえば、クライアントの IP アドレスに基づいて)一致する場合、フローは CX デバイスに入るときにドロップされます。


  • 3:サーバ hello と証明書。 サーバが hello に応答し、証明書を送信します。
  • 4CX デバイスは、サーバ証明書を確認し、復号化ポリシーを適用します。 ここでは、復号化します。
  • 5CX デバイスとサーバ間のハンドシェイク。
  • 6:サーバ hello と証明書。 CX デバイスはクライアントに自分のサーバ hello および証明書を送信します。
  • 7 —クライアントとCXデバイス間のハンドシェイク。
  • 8:クライアントと CX デバイス間の暗号化データ フロー。
  • 9CX デバイスは、フローを復号化し、検査して、アクセス ポリシーを再度適用します。 トラフィックが拒否ポリシーと一致する場合、フローはこの時点でドロップされます。
  • 10:フローがアクセス ポリシーにより許可された場合の、CX デバイスとサーバの間の暗号化データ フロー。

トラフィック フローを復号化しない

復号化されない暗号化されたトラフィック フローは、次のプロセスを使用して処理されます。

図 2. トラフィック フローを復号化しない



  • 1、2:クライアント hello。 クライアント(A)は、目的の宛先(C)へ hello を送信し、暗号化されたセッションを開始します。 トラフィック フローが CX デバイス(B)に入ると、デバイスは宛先サーバに自分の hello を送信します。

    (注)  


    最初のフローが拒否アクセス ポリシーと(たとえば、クライアントの IP アドレスに基づいて)一致する場合、フローは CX デバイスに入るときにドロップされます。


  • 3:サーバ hello と証明書。 サーバが hello に応答し、証明書を送信します。
  • 4CX デバイスは、サーバ証明書を確認し、復号化ポリシーを適用します。 ここでは、復号化しません。
  • 5、6CX デバイスは、クライアントおよびサーバとのトラフィック フローを個別に終了します。
  • 7:クライアントが接続を再試行します。 CX デバイスが、このフローは復号化しないことを記憶し、復号化処理をバイパスし、サーバとの独自の接続を行います。 フローは検査されません。

復号化のヒントと制限

復号化を設定するときは、次の点に注意してください。
  • 強力な暗号化には 3DES/AES(K9)ライセンスが必要です。 3DES/AES(K9)ライセンスがない場合、強力な暗号化が必要なサーバでの復号化処理が失敗します。 アクセス ポリシーに関係なく、デバイスで実行できない復号化を必要とするすべてのフローが拒否されます。 3DES/AES(K9)ライセンスは無料ですが、アベイラビリティは輸出規制によって制限されます。 詳細については、Cisco.com を参照してください。 3DES/AES(K9)ライセンスの使用を許可されていない場合は、これらのサイトの復号化をバイパスする必要があります。 複合化設定で [Deny Transactions to Servers; If the Secure Sessions Handshake Fails: Off] を選択して、これらのトランザクションを許可することもできます。
  • 復号化ポリシーは、フローが SSL/TLS ハンドシェイクで開始している場合のみ、トラフィック フローに適用されます。 SMTP over TLS などの暗号化をネゴシエーションするトラフィック フローが復号化されることはありません。 暗号化をネゴシエーションするトラフィック フローは、暗号化されていないトラフィック フローのように処理されます。
  • 復号化を有効にしたが、復号化ポリシーは作成しない場合、トラフィックは復号化されず、暗号化されたトラフィック フローは設定したアクセス ポリシーに基づいて許可または拒否されます。 [Decrypt Everything] または [Decrypt Potentially Malicious Traffic] アクションが適用される復号化ポリシーを作成して、すべてのフローを復号化する必要があります。
  • 復号化ポリシーで使用する URL オブジェクトを設定する際には、パス情報を含めないでください。 トラフィックが URL オブジェクトと一致するかどうか評価する際に、復号化ポリシーではパス情報を含んだすべての URL を完全に無視します。 オブジェクトに、ドメイン名だけの URL と、パスが含まれる URL が混在している場合、復号化ポリシーはそのオブジェクトを、ドメイン名だけを指定した URL のみが含まれるものとして扱います。
  • 復号化を有効にすると、システムのスループットが下がり、SSL/TLS 暗号化プロトコルを使用するアプリケーションのパフォーマンスに影響が及ぶ可能性があります。
  • 一部のアプリケーションは、クライアントとサーバ間のトラフィックの復号化をサポートしていません。 その理由としては、そのようなアプリケーションで信頼できる証明書ストアに証明書を追加できないか、そのアプリケーションが信頼する証明書のハードコードされたリストが使用されているか、接続中にアプリケーションがクライアント証明書を要求することなどがあります。 たとえば、インターネット メッセージング用アプリケーション、Dropbox、iTunes、および多くの銀行サイトなどです。 これらのアプリケーションについては、サポートされないアプリケーションの復号化のバイパス に記載されているように、復号化をバイパスする必要があります。複合化設定で [Deny Transactions to Servers; If the Secure Sessions Handshake Fails: Off] を選択して、暗号化処理の緩和を試行することもできます。

SSL/TLS 復号化の設定

次の手順では、SSL/TLS トラフィック フローの復号化を設定するプロセスの概要を示します。 この手順を使用して、一般的な設定プロセスを理解し、参照トピックで詳細な手順を確認してください。

手順
    ステップ 1   強力な暗号化をサポートする CX 3DES/AES(K9)ライセンスを取得してインストールします。

    強力な暗号化には 3DES/AES(K9)ライセンスが必要です。 3DES/AES(K9)ライセンスがない場合、強力な暗号化が必要なサーバでの復号化処理が失敗します。 アクセス ポリシーに関係なく、デバイスで実行できない復号化を必要とするすべてのフローが拒否されます。 3DES/AES(K9)ライセンスは無料ですが、アベイラビリティは輸出規制によって制限されます。

    3DES/AES(K9)ライセンスを使用できない場合は、実稼働ネットワーク上で復号化を有効にする前に、要件を満たしていることを確認するために制御環境で復号化処理をテストする必要があります。 3DES/AES(K9)ライセンスなしで適切なトラフィックがブロックされないようにするには、復号化ポリシーを注意深くテストし、調整する必要があります。

    ステップ 2   復号化設定の指定の説明に従って、復号化を有効にして、使用する CA 証明書を選択します。

    復号化をイネーブルにする必要があります。 イネーブルにしなかった場合、トラフィック フローは復号化されず、復号化ポリシーは使用されません。

    ユーザからのトラフィック フローの復号化には、CA 証明書が使用されます。 目的の宛先からの証明書を使用してトラフィック フローを再暗号化した後、それを宛先に送信します。

    ステップ 3   復号化ポリシーの設定の説明に従って、復号化ポリシーを設定します。

    復号化ポリシーによって、さまざまなトラフィック フローをどのように処理するかが定義されます。 それらを復号化して調査し、Web レピュテーションに基づいてそれらを条件付きで復号化するか、単に復号化しないことを選択できます。 デフォルトではトラフィックは復号化されないため、何らかのタイプの復号化を実装するポリシーを作成して、すべてのトラフィック フローを復号化する必要があります。

    ステップ 4   サポートされないアプリケーションの復号化のバイパスの説明に従って、信頼されているサイト、および復号化をサポートしていないサイトの復号化はバイパスします。

    安全と思われるフローの不要な復号化プロセスを防止するため、金融など、よく知られている URL カテゴリへのトラフィックは復号化しないようにすることを検討してください。 また、ネットワーク上で使用されているアプリケーションの中で、インスタント メッセージ アプリケーションのように、クライアントとサーバの間でトラフィックが復号化されると機能しなくなるアプリケーションは復号化しないでください。

    ステップ 5   信頼できるルート CA 証明書として復号化で使用される CA 証明書を認識するように、クライアント アプリケーションを設定します。

    ユーザは、TLS/SSL を使用するアプリケーションで、信頼できるルート認証局として定義された暗号化プロセスで使用される、CA 証明書を持っている必要があります。 SSL/​TLS 証明書のダウンロードとインストールの説明に従って、CA 証明書をダウンロードし、ユーザが使用できるようにブラウザにインストールします。 ソフトウェア管理メソッドを使用して、ブラウザに証明書を事前インストールすることで、ユーザの操作を回避できます。 一部のブラウザ以外のアプリケーションでは、証明書を追加できない場合があります。この場合、それらのアプリケーション用に復号化のバイパスが必要になることがあります。

    ステップ 6   Event Viewer を使用して、復号化イベントを表示および分析します。

    [Events] > [Events] を選択して Event Viewer を開きます。


    復号化設定の指定

    ASA CX に復号化ポリシーを実装するには、それらをイネーブルにし、ASA CX が管理対象の復号化されたトラフィック フローに使用する認証局(CA)の証明書を特定する必要があります。

    この CA 証明書は、クライアント アプリケーションがアクセスするサイトごとに、一時的な代替証明書を発行するために使用されます。 一時証明書は、クライアントと ASA CX の間の保護された(SSL または TLS)セッションで、実サーバの証明書の代わりに使用されます。 一方、実サーバの証明書は、ASA CX とサーバの間の保護されたセッションで使用されます。 この手法によって、ASA CX は両側からデバイスに着信するコンテンツを復号化し、再暗号化してから、リレーすることができます。

    手順
      ステップ 1   Configurations > Policies/Settings を選択し、[Decryption Settings] タブを開きます。

      (マルチ デバイス モードのみ)。 デバイス ビューで選択した特定のデバイスのタブを開くか、またはリポジトリ ビューでデバイスとは無関係にポリシーを開くことができます。

      ステップ 2   TLS/SSL 復号化をイネーブルにし、ポリシーを復号化するには、[Enable Decryption Policies: On] を選択します。

      復号化ポリシーをイネーブルにすると、追加設定が表示され、復号化されたフローの管理に使用する CA 証明書を選択できます。

      ステップ 3   必要に応じて、[Deny Transactions to Servers] オプションを変更して証明書処理要件を緩和し、失敗 TLS/SSL トランザクションの数を減らします。
      • [Using an Untrusted Certificate: On/Off]:証明書が信頼されていないサーバとのセッションはとにかく許可するかどうか。 これには、期限切れの証明書、未知の発行元、不一致のホスト名などを含めることができます。
      • [If the Secure Sessions Handshake Fails: On/Off]:TLS/SSL ハンドシェイクに失敗した場合にセッションをドロップするかどうか。 復号化ポリシーがある場合、Do Not Decrypt ポリシーに一致するセッションでさえ、ハンドシェイク障害がある場合はドロップできます。 このオプションは、信頼できない証明書によるのではない、TLS ハンドシェイクのエラーに適用され、SSLv3 アラート ハンドシェイク エラーが発生します。

      いずれかのオプションに対して [Off] を選択すると、関連する問題があるセッションは復号化なしで許可されます。 したがって、復号化を必要とするアクセス ポリシーは、これらのトランザクションには適用されません。

      ステップ 4   使用する [Certificate Initialization Method] を [Generate] または [Import] のいずれかから選択し、フィールドに入力します。

      復号化をすでにイネーブルにしている場合は、現在設定されている証明書に関する要約情報が、[Certificate Initialization Method] フィールドではなく、ページに表示されます。 証明書の [Export] または [Replace] のリンクがあります。

      [Replace] をクリックすると、[Certificate Initialization Method] フィールドが表示され、証明書の置き換え方法を選択できます。

      証明書の設定の詳細については、復号化証明書の設定を参照してください。

      ヒント   

      [Export] をクリックして、ブラウザにアップロードできるファイルで証明書をエクスポートできます。これにより、ユーザは復号化トラフィック フローの中での要求に従って、証明書を保存する必要がなくなります。

      ステップ 5   [Save] をクリックして変更を保存します。

      次の作業

      復号化をイネーブルにすると、復号化ポリシーを設定できるようになります。

      復号化証明書の設定

      ASA CX は、クライアントが最初に接続要求を送信した TLS サーバを模倣します。 要求先サーバのように振舞うクライアントとの間に保護された接続を構築するには、アプリケーションがそのクライアントに、アプライアンスで設定された認証局で署名済みのサーバ証明書を送信する必要があります。

      復号化ポリシーを設定するときは、アプライアンスがそのサーバ証明書への署名に使用する CA 証明書を設定する必要があります。 この CA 証明書は、宛先サーバから提示される証明書の代わりになる、新しい一時的な証明書の発行に使用されます。

      次の証明書初期化方式を使用して、証明書情報を入力できます。

      Generate

      いくつかの基本構成情報を入力して、システムに新しい認証局(CA)証明書を自動的に生成させることができます。 この証明書は、自己署名のルート CA 証明書になります。 中間 CA を発行するために使用できる独自の認証局が組織にない場合、証明書を生成できます。

      Import

      システムの外部で作成された CA 証明書と、それと一致する秘密キー ファイルをインポート(アップロード)できます。 ネットワーク上のクライアントが、証明書または証明書を発行した CA を信頼するよう設定済みの場合、証明書とキー ファイルをアップロードできます。

      認証局によって署名されたルート証明書または中間証明書のいずれかをアップロードできます。 ASA CX がサーバ証明書を模倣すると、アップロードされた証明書とともに模倣された証明書がクライアント アプリケーションに送信されます。 このように、クライアント アプリケーションが信頼する認証局によって中間証明書が署名される限り、アプリケーションは模倣されたサーバ証明書も信頼します。 組織が独自の認証局を使用する場合、中間証明書をアップロードすることもできますが、セキュリティ上の理由から、ルート証明書は ASA CX にアップロードしないでください。

      CA から新しい証明書を要求する場合、それ自体が認証局となる証明書を要求するようにしてください。 つまり、追加の「子」証明書を発行できる証明書が必要です。

      アップロードする証明書とキー ファイルは PEM 形式にする必要があります。 DER 形式はサポートされていません。 DER 形式の証明書またはキーを PEM 形式に変換する方法の詳細については、証明書およびキー形式の変換を参照してください。


      (注)  


      アップロードする証明書は、Mozilla Firefox ブラウザを使用して機能するための、基本制約拡張が行われている必要があります。 この制約により、Firefox は証明書を信頼された CA として認識できるようになります。 一般的に、証明書には基本制約拡張が含まれている必要があり、証明書は CA 証明書となっている必要があります。


      生成またはアップロードする証明書は、クライアント アプリケーション(通常はブラウザ)から認識される必要があります。認識されない場合、信頼されていない証明書に関する警告がユーザに表示されることがあります。 また、SSL/​TLS 証明書のダウンロードとインストール で説明されているように、証明書を認識するようにユーザのアプリケーションを設定する必要もあります。

      次に、復号化ポリシーに必要な証明書を生成またはアップロードする手順を説明します。

      手順
        ステップ 1   Configurations > Policies/Settings を選択し、[Decryption Settings][Decryption Settings]タブを開きます。

        [Enable Decryption Policies: On] が選択されていることを確認します。

        (マルチ デバイス モードのみ)。 デバイス ビューで選択した特定のデバイスのタブを開くか、またはリポジトリ ビューでデバイスとは無関係にポリシーを開くことができます。

        ステップ 2   次のいずれかを実行します。
        • [Certificate Initialization Method: Generate] を選択して、新しい証明書を作成します。
        • [Certificate Initialization Method: Import] を選択して、すでに存在する証明書と秘密キー ファイルをアップロードします。
        • 設定済みの復号化証明書がすでにあり、それを置き換える場合は、[Current Certificate Information: Replace] をクリックした後、いずれかの初期化方法を選択します。
        ステップ 3   [Generate] を選択した場合、次の情報を入力します。
        • [Common Name]:(CN)。証明書に含める共通名。 これは、デバイスの名前、Web サイト、または他の文字列にすることができます。
        • [Organization]:(O)。証明書に含める組織または会社の名前。
        • [Organizational Unit]:(OU)。証明書に含める組織単位の名前(部門名など)。
        • [Country]:(C)。証明書に含める 2 文字の ISO 3166 国番号。 たとえば、米国の国番号は US です。
        • [Months to Expiration]:証明書の月単位の有効期間。 デフォルトは 12 ヵ月間です。
        • [Set Basic Constraints Extension to Critical: On/Off]:基本制約拡張をクリティカルに設定するかどうか。 基本制約拡張は、証明書が CA 証明書であり、他の証明書の署名にもそれを使用できることを示すものです。 この拡張をクリティカルとして設定すると、この拡張は証明書の意味に対して非常に重要であり、クライアント アプリケーションはこの拡張が意味することを理解していない場合、証明書を受け入れるべきではないということを示します。 大部分の TLS クライアントは、この拡張を認識します。 ただし、[Off] を選択して、拡張が意味することを理解しないクライアント アプリケーションに対処することができます。

        これらの証明書フィールドに含めた情報は、エンド ユーザが Web ブラウザで証明書の詳細を調べると、エンド ユーザに表示されます。 [Common Name and Organization] フィールドを使用して、エンド ユーザに証明書の所有権に関する情報をわかりやすく示します。

        ステップ 4   [Import] を選択した場合、次の情報を入力します。
        • [Certificate]:[Browse] をクリックし、使用する CA 証明書ファイルを選択して、それをデバイスにアップロードします。
        • [Key]:[Browse] をクリックし、使用する秘密キー ファイルを選択して、それをデバイスにアップロードします。
        • [Private Key Phrase]:パス フレーズで保護されている場合は、秘密キー ファイルのパス フレーズを入力します。
        ステップ 5   [Save] をクリックします。

        証明書が生成またはインポートされます。 証明書の概要がページに表示されます。 [Export] をクリックすると、証明書をエクスポートできます。


        証明書およびキー形式の変換

        アップロードするルート証明書と秘密キー ファイルは PEM 形式にする必要があります。 DER 形式はサポートされていません。 ただし、DER 形式の証明書とキーを PEM 形式に変換してから、アップロードすることはできます。 たとえば、OpenSSL を使用して形式を変換できます。

        次の OpenSSL コマンドを使用して、DER 形式の証明書ファイルを PEM 形式の証明書ファイルに変換します。

        openssl x509 -inform DER -in cert_in_DER -outform PEM -out out_file_name
        
        

        また、同様の OpenSSL コマンドを実行して、DER 形式のキー ファイルを PEM 形式に変換することもできます。

        RSA キーの場合は、次のコマンドを使用します。

        openssl rsa -inform DER -in key_in_DER -outform PEM -out out_file_name
        
        

        DSA キーの場合は、次のコマンドを使用します。

        openssl dsa -inform DER -in key_in_DER -outform PEM -out out_file_name
        
        

        OpenSSL の使用の詳細については、OpenSSL のマニュアルを参照するか、http://openssl.org にアクセスしてください。

        SSL/TLS 証明書のダウンロードとインストール

        トラフィックを暗号化する場合、ユーザは TLS/SSL を使用するアプリケーションで、信頼できるルート認証局として定義された暗号化プロセスで使用される、ASA CX CA 証明書を持っている必要があります。 通常、証明書を生成した場合や、証明書をインポートした場合であっても、これらのアプリケーションで証明書がすでに信頼されているものとして定義されることはありません。 大部分の Web ブラウザはデフォルトで、ユーザが HTTPS 要求を送信すると、Web サイトのセキュリティ証明書に問題があることを知らせる警告メッセージがクライアント アプリケーションから表示されます。 通常、このエラー メッセージでは、Web サイトのセキュリティ証明書が信頼された認証局から発行されたものではないこと、または Web サイトが不明な認証局で証明されたものであることが示されますが、警告によって処理中に中間者攻撃の可能性があることが示唆される場合もあります。 クライアント アプリケーションによっては、この警告メッセージがユーザに示されず、ユーザは承認されない証明書を受け入れることができません。

        以下のいくつかの方法で、ユーザに必要な証明書を提供できます。

        ルート証明書を受け入れるようにユーザに通知します

        組織内のユーザに、企業の新しいポリシーについて通知し、組織が提供したルート証明書を、信頼できる認証局として受け入れるように指示できます。 ユーザは証明書を受け入れ、信頼されたルート認証局のストレージ エリアにそれを保存して、次にサイトにアクセスしたときにプロンプトが再度表示されないようにする必要があります。


        (注)  


        ユーザは、代替証明書を作成した CA 証明書を受け入れて、信頼する必要があります。 そうではなく、単に代替サーバ証明書を信頼した場合は、異なる HTTPS サイトを訪問するたびに、警告が表示される状況が続きます。


        クライアント マシンにルート証明書を追加します

        ネットワーク上のすべてのクライアント マシンに、信頼できるルート認証局としてルート証明書を追加できます。 そうすれば、クライアント アプリケーションは自動的にルート証明書を持つトランザクションを受け入れるようになります。 アプリケーションが使用しているルート証明書を配布したことを確認するには、復号化設定からルート証明書をダウンロードします。 [Export] リンクをクリックして、ファイルを保存します。

        証明書を電子メールで送信するか、共有サイトに置くことで、ユーザが証明書を入手できるようにします。または、会社のワークステーション イメージに証明書を組み込み、アプリケーションの更新機能を使用して、ユーザに証明書を自動的に配布することもできます。


        ヒント


        クライアント マシンで証明書エラーが発生する可能性を下げるには、証明書をエクスポートしてクライアント アプリケーションに追加するまで、証明書に変更を加えないでください。


        次に、CA 証明書をダウンロードして、ブラウザにインストールする方法を説明します。

        手順
          ステップ 1   必要に応じて、ASA CX から証明書をダウンロードします。
          1. Configurations > Policies/Settings を選択し、[Decryption Settings][Decryption Settings]タブを開きます。

            (マルチ デバイス モードのみ)。 デバイス ビューで選択した特定のデバイスのタブを開くか、またはリポジトリ ビューでデバイスとは無関係にポリシーを開くことができます。

          2. [Current Certificate Information] という見出しの横にある [Export] リンクをクリックします。

            ブラウザの設定によっては、ファイルを開くか、保存するかの問い合わせが表示されます。 都合のよい場所に保存します。

          ステップ 2   クライアント システムの Web ブラウザにある信頼されたルート認証局のストレージ エリアに証明書をインストールするか、クライアント自体が証明書をインストールできるようにします。

          手順は、ブラウザのタイプによって異なります。また、ブラウザのバージョンによって異なる場合もあります。 たとえば、Firefox 11 での手順は以下のとおりです。

          1. Firefox で、[Tools] > [Options] を選択します。
          2. [Advanced] を選択してから [Encryption] タブを選択します。
          3. [View Certificates] をクリックして、証明書マネージャを開きます。
          4. [Authorities] タブを選択します。
          5. [Import] をクリックし、ダウンロード ファイル(ca.crt.pem)を選択してダウンロードし、[OK] をクリックします。

            [Downloading Certificate] ダイアログ ボックスが開きます。

          6. [Trust this CA to identify web sites] を選択し、[OK] をクリックします。

            [Authorities] タブの [Certificate Names] のリストに、その CA 名が表示されます。 これで、すべての証明書ダイアログ ボックスを閉じて、ブラウザ ウィンドウに戻ることができます。


          補足的な信頼できる証明書の管理

          ASA CX が TLS サーバの接続要求を受け取ると、サーバ証明書を署名したルート認証局によって検証された宛先サーバの信頼性を検証します。 ASA CX で、サーバ証明書に署名したルート証明書が認識されない場合、そのサーバ証明書は信頼されません。 これは、ASA CX に付属する信頼できる認証局のセットにリストされていない認証局を、TLS サーバが使用している場合に発生します。 組織が内部認証局を使用して、内部ネットワーク上のサーバの証明書に署名する場合に発生する可能性があります。


          ヒント


          この問題の主な症状として、Event Viewer の [Deny Reason] カラムに「The server presented an untrusted or invalid certificate」が表示されるフロー拒否イベントがあります。復号化設定で [Deny Transactions to Servers; Using an Untrusted Certificate: Off] を選択することによって、この制限を緩和し、これらのトランザクションを許可することができます。


          ASA CX が、認識されないルート認証局を使用するサーバへのアクセスをブロックしないようにするには、組織が信頼するアプライアンス ルート証明書をアップロードします。 たとえば、ネットワーク上のサーバによって使用されているルート証明書をアップロードできます。 これらの補足的な証明書は、組み込まれた信頼できる証明書と組み合わせて使用されます。

          複数の証明書ファイルをアップロードできます。また、アップロードする各ファイルには複数の証明書を格納することができます。 ルート CA 証明書、中間 CA 証明書、または個々のサーバ証明書でもアップロードできます。 ただし、アップロードする各証明書は PEM 形式にする必要があります。


          (注)  


          システムには、有名な信頼できる CA 証明書の組み込みリストが含まれています。 これらの証明書は、[Configurations] > [Certificates] ページには表示されません。


          手順
            ステップ 1   [Configurations] > [Certificates] を選択します。

            証明書リストにはインポートしたすべての証明書が表示され、証明書に定義されている場合は、共通名、組織、組織単位、およびそれぞれの国なども表示されます。

            (注)     

            証明書が不要になった場合、証明書リストで対象の証明書にマウスを合わせ、[Delete Certificate] をクリックします。

            ステップ 2   [I Want To] > [Import New Certificate] を選択します。
            ステップ 3   [Browse] をクリックし、証明書ファイルを選択します。
            ステップ 4   [Save] をクリックします。

            その証明書がルート証明書のリストに追加されます。


            復号化ポリシーの設定

            コンテキスト対応復号化ポリシーを ASA CX で使用して、SSL/TLS 暗号化トラフィック フローの処理方法を判別します。 トラフィック フローの復号化により、検査されたトラフィック フローの内容、たとえば、アプリケーション、URL カテゴリ、Web レピュテーションなどに基づいてアクセス ポリシーを適用することが可能になります。


            ヒント


            デフォルトでは、暗号化されたトラフィックは復号化されません。 このため、[Decrypt Everything] または [Decrypt Potentially Malicious Traffic] アクションが適用されるポリシーを作成することに焦点を当てます。 [Do Not Decrypt] を使用しているポリシーは、一定のレベルの復号化が適用されるポリシーと別の方法で照合するトラフィックのサブセットを指定している場合にのみ必要です。


            手順
              ステップ 1   Configurations > Policies/Settings を選択して、[Decryption Policies][Decryption Policies]タブを開きます。

              (マルチ デバイス モードのみ)。 デバイス ビューで選択した特定のデバイスのタブを開くか、またはリポジトリ ビューでデバイスとは無関係にポリシーを開くことができます。

              ステップ 2   次のいずれかを実行します。
              • 新しいポリシーを追加するには、[Add Policy] ボタンの 1 つを使用します。 ポリシー セットを選択した場合、セットの上部または下部にポリシーを追加できます。 ポリシーを選択した場合、その上または下に新しいポリシーを追加できます。
              • 既存のポリシーを編集するには、ポリシーを選択し、[Edit Policy] ボタンをクリックします。
              • 類似した既存のポリシーを基に新規ポリシーを作成するには、ポリシーを選択し、[Duplicate Policy] ボタンをクリックします。

              ポリシーのプロパティとともに、フォームが開きます。

              ステップ 3   [Source]、[Destination]、および [Service] フィールドを使用して、トラフィックの一致基準を定義します。

              基準に基づいてポリシーを制限しない場合は、フィールドをブランクのままにします。 非常に複雑な送信元または宛先基準を作成する必要がある場合は、送信元および宛先グループ ポリシー オブジェクトを使用します。 これらのオブジェクトを使用して、複雑な組み合わせの他のオブジェクトでトラフィック フローを正確に定義できます。 各フィールドについての詳細情報の関連トピックを参照してください。

              ステップ 4   一致するトラフィックに適用するアクションを定義します。
              • [Decrypt Everything]:一致するトラフィックを復号化し、追加のアクセス コントロール ポリシーに従うようにするには、[Decrypt Everything] を選択します。 このオプションは、セキュリティと脅威の特性が不明なトラフィック クラスに使用するのが最も適しています。
              • [Decrypt Potentially Malicious Traffic]:Web レピュテーションに基づいて条件付きでトラフィックを複合化するときに、[Decrypt Potentially Malicious Traffic] を選択します。 低レピュテーション ゾーンに該当する、一致するトラフィックは復号化されますが、高レピュテーション トラフィックは復号化されません。 このオプションを選択する場合は、[Web Reputation] フィールドに低レピュテーション ゾーンを定義する Web レピュテーション プロファイル オブジェクトも選択する必要があります。
              • [Do Not Decrypt]:よく知られた銀行または他の金融機関など、受け入れ可能なことが明らかなトラフィックについては、[Do Not Decrypt] を選択して、トラフィックが自由に渡され、トラフィックの復号化に処理パワーが使用されないようにすることができます。
              ステップ 5   親デバイスの特定のインターフェイス上のトラフィックにのみポリシーを制限する場合は、そのインターフェイスを特定する [Source Interface Role] または [Destination Interface Role] あるいはその両方を選択します。

              デフォルトでは、デバイスの任意のインターフェイス間のトラフィックにポリシーが適用されます。 デバイスに存在しないインターフェイスを選択した場合、ポリシーはトラフィックに適用されません。

              ステップ 6   [Save Policy] をクリックします。
              ステップ 7   優先順位に収まるように、必要に応じてポリシーを移動します。

              ポリシーは、最初に一致したものから順に適用されるため、限定的なトラフィック一致基準を持つポリシーは、同じトラフィックに適用され、汎用的な基準を持つポリシーよりも上に置く必要があります。

              ポリシー セットまたはルールを移動するには、[Move] アイコン(左端の垂直な両方向矢印)をクリックしたまま、挿入位置のすぐ前のポリシーまでドラッグします。 単にシーケンス番号を編集し、目的の値に変更することもできます。


              復号化ポリシーのプロパティ

              コンテキスト対応復号化ポリシーを ASA CX で使用して、SSL/TLS 暗号化トラフィック フローの処理方法を判別します。 トラフィック フローの復号化により、検査されたトラフィック フローの内容、たとえば、アプリケーション、URL カテゴリ、Web レピュテーションなどに基づいてアクセス ポリシーを適用することが可能になります。

              復号化ポリシーには、次のプロパティがあります。

              Policy Name

              ポリシーの名前。 この名前は、このポリシーと一致するトラフィックによって生成された復号化イベントの Event Viewer に表示されます。したがって、イベント データの分析に役立つ名前を選択してください。

              Enable Policy:On/Off

              ポリシーがイネーブルかどうかを示します。 ポリシーをオフにすると、ポリシーを削除せずに一時的にディセーブルにできます。 ディセーブルに設定されたポリシーはトラフィックに適用されません。

              Traffic Matching Criteria

              ポリシーが適用されるトラフィックを特定するトラフィックの一致基準。 ポリシーと一致するためには、フローは指定したすべてのプロパティと一致する必要があります。つまり、プロパティの間には AND 関係があります。 条件に基づいてポリシーを制限しない場合は、デフォルトの [Any] を選択します。 考えられるすべてのトラフィック フローを照合するには、すべてのフィールドをデフォルトの [Any] のままにします。

              以下のすべての基準が使用されて、ポリシーが適用されるトラフィックが判別されます。
              • [Source]:ネットワーク グループ(IP アドレス)、ID(ユーザまたはユーザ グループ名)、または Secure Mobility(リモート アクセス VPN クライアントのタイプ)の各タイプのポリシー オブジェクトのリスト。 選択したいずれかのオブジェクトとパケットが一致すると、送信元条件を満たしていると見なされます。
              • [Destination]:URL(URL または Web カテゴリ)、または宛先オブジェクト グループ(ポリシーでは直接定義できない複雑な AND/OR 関係のネットワーク グループまたは URL オブジェクトの集合体)の各タイプのポリシー オブジェクトのリスト。 選択したいずれかのオブジェクトとパケットが一致すると、宛先条件を満たしていると見なされます。 URL フィルタリング機能を無効にするか、有効な Web Security Essentials ライセンスを持っていない場合、このフィールドや宛先オブジェクト グループで URL オブジェクトを使用することはできません。

                ヒント


                復号化ポリシーで使用する URL オブジェクトを設定する際には、パス情報を含めないでください。 トラフィックが URL オブジェクトと一致するかどうか評価する際に、復号化ポリシーではパス情報を含んだすべての URL を完全に無視します。 オブジェクトに、ドメイン名だけの URL と、パスが含まれる URL が混在している場合、復号化ポリシーはそのオブジェクトを、ドメイン名だけを指定した URL のみが含まれるものとして扱います。


              • [Service]:プロトコルとポートの組み合わせを定義するサービス グループのリスト。 選択したいずれかのオブジェクトとパケットが一致すると、サービス条件を満たしていると見なされます。

              (注)  


              マルチ デバイス モード)。PRSMマルチ デバイス モード で使用する際には、送信元基準または宛先基準には、CX デバイスを含むデバイスで定義されているネットワーク オブジェクトまたはグループを使用し、サービス基準には、ASA サービス オブジェクトを使用することもできます。 ネットワーク グループ オブジェクトには 2 つのタイプがあります。1 つは ASA と CX デバイスの両方で使用できます。もう 1 つは CX デバイスでのみ使用でき、特に CX ネットワーク グループと呼ばれます。


              項目の追加、編集、削除方法などの項目の選択方法、選択リストのフィルタリング方法、オブジェクトの作成または編集方法、オブジェクト内容の表示方法については、項目の選択を参照してください。

              Action
              [Action] セクションによって、一致するトラフィック フローが復号化されるかどうかが決定します。 次のオプションがあります。
              • [Decrypt Everything]:トラフィックを復号化して、検査します。 アクセス ポリシーによってトラフィック フローが許可された場合、フローは再暗号化され、宛先に送信されます。

                (注)  


                たとえば、デバイスがリモート サーバの証明書を信頼できないなどが原因で、リモート サーバへの保護されたセッションを構築できない場合は、トラフィック フローが拒否されることがあります。 また、サーバによって強力な暗号化が要求される場合、ASA CX の 3DES/AES(K9)ライセンスを持っている必要があります。これがない場合、フローは拒否されます。


              • [Decrypt Potentially Malicious Traffic]:Web レピュテーションに基づいて、条件付きでトラフィックを復号化します。 低レピュテーション ゾーンに該当する、一致するトラフィックは復号化されますが、高レピュテーション トラフィックは復号化されません。 このオプションを選択する場合は、[Web Reputation] フィールドに低レピュテーション ゾーンを定義する Web レピュテーション プロファイル オブジェクトも選択する必要があります。 低レピュテーションの Web サイトへのトラフィックを拒否するには、アクセス ポリシーと同じ Web レピュテーション プロフィルを使用する必要があります。
              • [Do Not Decrypt]:(デフォルト)。トラフィックを復号化しません。 このトラフィック フローは検査されません。 ただし、十分な情報が HTTP ヘッダーと宛先サーバ証明書から収集され、宛先基準に沿って URL オブジェクトの照合を行えます。 URL の照合は、宛先のドメイン名に基づきます。これは、URL カテゴリと照合することもできます。

                (注)  


                どの宛先ポリシーとも一致しない暗号化されたフローのデフォルト アクションは、[Do Not Decrypt] です。


              Interface Roles

              ポリシーの適用先とする親デバイスのインターフェイスを特定する条件です。 ポリシーと一致するには、トラフィックが送信元インターフェイス上のデバイスに入り、宛先インターフェイス上のデバイスを離れる必要があります。 デフォルトは、送信元と宛先の両方のすべてのインターフェイスで、ポリシーは特定のインターフェイスに限定されません。

              特定のインターフェイスにポリシーを制限するには、[Source Interface Role] か [Destination Interface Role] フィールド、またはその両方で適切なインターフェイス ロール オブジェクトを選択します。 インターフェイス ロール オブジェクトは、インターフェイスのインターフェイス名または命名パターンを定義します。


              ヒント


              インターフェイス ロールを指定していて、デバイス上のインターフェイスがロールで定義されたインターフェイスの名前と一致しない場合、ポリシーはデバイス上のトラフィックには適用されません。


              Tags

              この項目の識別に役立つ語とフレーズ。 たとえば、同じタグを複数の項目に割り当てると、検索での表示が容易になります。 タグでは、ユーザが選択した使用例、目的、またはその他の特性を識別できます。 これらのタグは、ユーザの目的にのみ対応しています。システムやポリシーの機能には影響しません。 複数のタグを入力(または選択)できます。

              Ticket ID

              ご使用のサポート システム(Remedy など)からのケース ID またはチケット ID。 ネットワーク サポート ケースに関連する変更を行う場合、トラッキング用にここにチケット ID を入力できます。 新しい ID を入力するか、保留中の変更に使用されている既存の ID から選択することができます。必要なだけの ID を指定します。 (すでにコミットされている変更で使用した ID は、このリストに表示されません)

              サポートされないアプリケーションの復号化のバイパス

              Dropbox や、AOL Instant Messenger(AIM)などの大部分のインスタント メッセージ アプリケーションは、信頼できるルート証明書ストアに証明書を追加できません。 これらのアプリケーションでは、復号化に使用されている証明書が、あらかじめ信頼されたものになっている必要があります。 ASA CX によって、信頼されていない証明書を使用してトラフィックが復号化されると、これらのアプリケーションは機能しません。 復号化設定で適切な証明書をアップロードしなかった、またはアップロードできなかった場合は、復号化ポリシーによってトラフィックを識別する必要があります。また、これらのアプリケーションを許可する場合は、[Do Not Decrypt] アクションを適用します。

              ASA CX のようなプロキシ サーバによって HTTPS サーバへのトラフィックが復号化されると、一部の HTTPS サーバは期待どおりに機能しなくなります。 たとえば、セキュリティの高い銀行のサイトなど、一部の Web サイトとそれらに関連する Web アプリケーションおよびアプレットは、オペレーティング システムの証明書ストアを使用するのではなく、信頼できる証明書のハードコードされたリストを維持します。

              最後に、iTunes などの一部のアプリケーションは、接続中にクライアント認証を要求します。 これらのサイトに復号化を適用すると、接続は失敗します。 これらのサイトでの復号化をバイパスする必要があります。

              アプリケーションが ASA CX の復号化をサポートできない現象として、以下を考えます。
              • Event Viewer で、「不明な CA」または「不適切な証明書」アラートが [Error Details] カラムに含まれ、証明書に指定されている認証局が不明であるか、それに関して他の容認できない問題があることを示している TLS の完了イベントを探します。 これは、自己署名証明書を生成した場合に発生する可能性の高いエラーです。
              • Event Viewer で、[Deny Reason] カラムが「The server presented an untrusted or invalid certificate」になっているフロー拒否イベントを探します。このような場合、信頼できない CA またはサーバから補足的な証明書をアップロードすることで、問題が解決する場合があります([Configurations] > [Certificates] を選択)。 複合化設定で [Deny Transactions to Servers; Using an Untrusted Certificate: Off] を選択して、この制限を緩和し、これらのトランザクションを許可することもできます。
              • Event Viewer で、拒否の理由がサーバのセキュリティ保護されたセッションの確立失敗で、復号化エラーの詳細がハンドシェイク失敗を示しているフロー拒否イベントを探します。 これは、サーバが 3DES/AES(K9)ライセンスを必要とする強力な暗号化を使用していることを示す場合があります。 (イベントの [K9 License Missing] 列が [Yes] と表示される場合、ライセンスはインストールされていません)デバイスの 3DES/AES(K9)ライセンスを取得できる場合は、ファイルをアップロードすれば、問題は解決するはずです。 3DES/AES(K9)ライセンスの使用を許可されていない場合は、サイトの復号化をバイパスする必要があります。
              • AIM の場合、ユーザはログインできません。 他のアプリケーションでも同様の問題が生じることがあります。
              • Dropbox の場合、ユーザに「Unable to make a secure connection」というメッセージが表示される可能性があります。 他のアプリケーションでも同様の問題が生じることがあります。
              すべてのユーザがこれらのタイプのサイトにアクセスできるようにするには、次のアプリケーションで使用されるサーバへのトラフィックの復号化をバイパスします。 復号化をバイパスするには、次の手順を実行します。
              1. トラフィックの宛先を識別するオブジェクトを作成します。 HTTPS の場合は URL オブジェクトを使用できます。その他のタイプの TLS トラフィックでは、ネットワーク オブジェクトを使用します。
              2. 宛先としてオブジェクトを使用する復号化ポリシーを作成し、[Do Not Decrypt] アクションを適用します。 同じトラフィックに復号化処理を適用するどのポリシーよりも、ポリシー セット内でそのポリシーが上にあることを確認します。

              ヒント


              別のオプションは、複合化設定で [Deny Transactions to Servers; If the Secure Sessions Handshake Fails: Off] を選択することです。 これは、ハンドシェイクが失敗するすべてのサイト(これには、復号化をサポートしない場合に強力な復号化を要求するサイトが含まれます)、および iTunes などの接続中にクライアント証明書を要求するサイトの複合化をバイパスします。 一方、バイパス ルールを作成すると、識別された特定のサイトの復号化が免除されます。このオプションは、セッション確立問題によって復号化をサポートできないすべてのサイトに対してまったく複合化しない免除を作成します。


              次に、AIM の復号化のバイパス ルールを作成する方法の例を示します。

              手順
                ステップ 1   Configurations > Policies/Settings を選択し、[Decryption Policies][Decryption Policies]タブを開きます。

                (マルチ デバイス モードのみ)。 デバイス ビューで選択した特定のデバイスのタブを開くか、またはリポジトリ ビューでデバイスとは無関係にポリシーを開くことができます。

                ステップ 2   新しいポリシーを追加するには、[Add Policy] ボタンの 1 つを使用します。

                ポリシー セットを選択した場合、セットの上部または下部にポリシーを追加できます。 ポリシーを選択した場合、その上または下に新しいポリシーを追加できます。

                ステップ 3   ポリシーの名前(Bypass AIM など)を入力します。
                ステップ 4   オブジェクトを作成し、選択します。
                1. [Destination] フィールドをクリックし、ドロップダウン リストの下部にある [Create New Object] を選択します。
                2. オブジェクト名(AIM など)を入力します。
                3. オブジェクト タイプとして [URL Object] を選択します。
                4. [Include] リストで [Instant Messaging] URL カテゴリを選択するか、オプションで、[URL] フィールドに次の項目を入力します。
                  • aimpro.premiumservices.aol.com
                  • bos.oscar.aol.com
                  • kdc.uas.aol.com
                  • buddyart-d03c-sr1.blue.aol.com
                  • 205.188.8.207
                  • 205.188.248.133
                  • 205.188.13.36
                  • 64.12.29.131
                  ヒント   

                  両方を行うと、オブジェクトがカテゴリとサーバ リストを指定するようになります。 サーバをリストする場合、AIM で使用されるサーバの実際のリストは時間の経過に伴って変わる可能性があるため、リストの調整が必要になる可能性があることに注意してください。

                5. [Save Object] をクリックします。

                  オブジェクトが作成され、[Destination] フィールドに追加されます。

                ステップ 5   [Action] フィールドで [Do Not Decrypt] を選択します。
                ステップ 6   [Save Policy] をクリックします。

                TLS/SSL 復号化のトラブルシューティング

                一般に、サイトの復号化をオンにした後に、ユーザに TLS/SSL サーバへの接続の問題が発生している場合は、次のオプションがあります。

                • 証明書が信頼できない場合は、補足的な証明書ストアに追加します。複合化設定で [Deny Transactions to Servers; Using an Untrusted Certificate: Off] を選択して、この制限を緩和し、これらのトランザクションを許可することもできます。
                • 証明書が無効で、ターゲット サーバを制御している場合、サーバの時刻設定を調べ、それらが CX の時刻設定と一致していることを確認します。 NTP を使用することをお勧めします。 無効な証明書はまだ有効になっていないか、期限切れになった可能性があります。 (期限切れの証明書を交換します)。
                • 多くのサイトでは、単に man-in-the-middle 復号化をサポートしていません。 これらのサイトの場合、それらをバイパスする Do Not Decrypt アクションを適用する復号ポリシーを作成します。接続の開始時に証明書を要求するサイトの場合も、時刻設定で [Deny Transactions to Servers; If the secure session handshake fails: Off] を選択して、接続を許可できます。

                一般的な問題点と解決の推奨事項は次のとおりです。

                ユーザのクライアントまたはブラウザからの情報

                失敗したアクセスの試行時に発生するユーザ アプリケーションまたはブラウザから警告またはエラーを探します。

                クライアントがローカル認証局(CA)証明書を信頼しない

                Web ブラウザは通常、証明書を信頼しないときに警告を表示します。 ただし、インスタント メッセージ クライアントのような他のクライアントは、警告を表示せずに失敗することがあります。

                ASA CX が復号化に使用する証明書がクライアントにインストールされていることを確認します。 インストール手順はブラウザによって異なります。

                ASA CX がサーバ証明書を信頼しない

                ユーザのアクセスの試行に対する Event Viewer のフロー拒否イベントを探します。 [Deny Reason] カラムに、フローが拒否された理由が示されます。

                フローがポリシーによって拒否された場合、フローはその拒否しているアクセス ポリシーと一致しています。 フローを許可する必要がある場合は、アクセス ポリシーを調整します。

                拒否理由が「The server presented an untrusted or invalid certificate」の場合は、次の可能性を探索します。

                • 時刻設定がサーバと CX デバイス間で一致していない場合に、無効な証明書が発生する可能性があります。 無効な証明書はまだ有効になっていないか、期限切れになった可能性があります。 サーバを制御している場合は、時刻設定を確認し、必要に応じて修正するか、期限切れの証明書を交換します。
                • 信頼できない証明書の場合、[Certificates] ページに証明書をアップロードすることによって問題を解決できます([Configurations] > [Certificates] を選択します)。 認証局から発行された証明書の場合は、証明書の階層を調べ、ルート証明書または中間証明書をダウンロードして [Certificates] ページに追加し、CA からの証明書を使用する他のサイトが信頼されるようにする必要があるかどうかを判別します。 複合化設定で [Deny Transactions to Servers; Using an Untrusted Certificate: Off] を選択して、この制限を緩和し、これらのトランザクションを許可することもできます。

                ヒント


                すべての自己署名証明書は、[Certificates] ページに追加するまで非信頼です。


                ASA CX がサーバとの TLS セッションを確立しない

                ユーザのアクセスの試行に対する Event Viewer のフロー拒否イベントを探します。 [Deny Reason] カラムに、フローが拒否された理由が示されます。

                拒否の原因がサーバとのセキュリティ保護されたセッションの確立失敗で、復号化エラーがハンドシェイク失敗を示している場合、これは、サーバが 3DES/AES(K9)ライセンスを必要とする強力な暗号化を使用していることを示す場合があります。 (イベントの [K9 License Missing] 列が [Yes] と表示される場合、ライセンスはインストールされていません)デバイスの 3DES/AES(K9)ライセンスを取得できる場合は、ファイルをアップロードすれば、問題は解決するはずです。 3DES/AES(K9)ライセンスの使用を許可されていない場合は、サイトの復号化をバイパスする必要があります。 複合化設定で [Deny Transactions to Servers; If the Secure Sessions Handshake Fails: Off] を選択して、この制限を緩和し、これらのトランザクションを許可することもできます。

                iTunes など、接続中にクライアント証明書を要求するアプリケーションも、ハンドシェイクが失敗することがあります。

                また、[Error Details] フィールドに未処理の OpenSSL エラーが表示されているフローの TLS の完了イベントを調べます。


                ヒント


                ほとんどの金融系 Web サイトを含む多くの TLS/SSL アプリケーションは、man-in-the-middle 復号化では機能しないことに注意してください。 このタイプの復号化で機能しないすべての TLS/SSL サイトの復号化を許可したい場合、それをバイパスするように復号化ポリシーを設定する必要があります。この制限を緩和しようとする場合は、複合化設定で [Deny Transactions to Servers; If the Secure Sessions Handshake Fails: Off] を選択すると、これらの問題の一部が解決する場合もあります。


                クライアントが ASA CX との TLS セッションを確立しない

                この問題はまれです。 複合化設定でアップロードまたは生成した復号化証明書が、復号化するユーザのクライアントによって認識されることを確認します。