接続性

• ping でデバイスの接続を確認します。ASA から直接 FP 管理 IP アドレスに ping を実行してみてください。ICMP が外部からの通信をブロックする場合、インターネットから FP 管理インターフェイスに対して ping を実行できません。 cUrl または wget を使用すると、設定された IP やポートで FP 管理インターフェイスにアクセスできるかどうかを確認できます。

• ASA/ASDM ソフトウェアバージョンの互換性の確認詳細については、「CDO でサポートされるソフトウェアとハードウェア」を参照してください。

• ASA ログを使用して、CDO トラフィックが ASA によってブロックされているかどうかを判断します。SSH を介して FP HTTP 管理インターフェースへの接続を試みると、/var/log/httpd/httpsd_access_log にログが記録されます。

モジュールの不良構成

• Unsupported configuration. モジュールが特定の要件を満たしていない場合、CDO はデバイス構成をサポートできない場合があります。

HTTP Authentication

• CDO は、オンボーディングプロセス中に ASA デバイスを認証するためにトークンベースの SSO を発行します。マルチコンテキストモードの ASA の場合、管理コンテキスト以外から FP モジュールをオンボードしようとすると、トークンの問題が発生する可能性があります。無効なトークンは、/var/log/mojo/mojo.log a で ASDM SSO ログインとして識別されます。

クラウドサービスの FQDN を解決できない

クラウドサービスの FQDN の解決に失敗したためにデバイスの登録が失敗した場合は、ネットワーク接続または DNS 構成を確認して、デバイスのオンボーディングを再試行してください。

無効な登録キーのために失敗する

無効な登録キーが原因でデバイスの登録に失敗した場合、FDM に間違った登録キーを貼り付けている可能性があります。

同じ登録キーを CDO から再度コピーして、デバイスの登録を試行します。デバイスにすでにスマートライセンスがある場合は、FDM に登録キーを貼り付ける前にスマートライセンスを削除してください。

ライセンス不足のために失敗する

デバイスの接続ステータスに [ライセンスが不足しています（Insufficient License）] と表示される場合は、以下の手順を実行します。

• デバイスがライセンスを取得するまでしばらく待ちます。通常、Cisco Smart Software Manager が新しいライセンスをデバイスに適用するには時間がかかります。

• デバイスのステータスが変わらない場合は、CDO からサインアウトしてから再度サインインすることで CDO ポータルを更新して、ライセンスサーバーとデバイスとの間のネットワーク通信の問題を解決します。

• ポータルを更新してもデバイスのステータスが変更されない場合は、次の手順を実行します。

  1. Cisco Smart Software Manager から新しい登録キーを生成し、コピーします。詳細については、スマートライセンスの生成に関するビデオをご覧ください。

  2. CDO ナビゲーション バーで、[インベントリ（Inventory）] ページをクリックします。

  3. ステータスが [ライセンスが不足しています（Insufficient License）] のデバイスを選択します。

  4. [デバイスの詳細（Device Details）] ペインで、 [ライセンスが不足しています（Insufficient License）] に表示される [ライセンスの管理（Manage Licenses）] をクリックします。[ライセンスの管理（Manage Licenses）] ウィンドウが開きます。

  5. [アクティブ化（Activate）] フィールドで、新しい登録キーを貼り付けて [デバイスの登録（Register Device）] をクリックします。

• 新しい登録キーがデバイスに正常に適用されると、接続状態が [オンライン（Online）] に変わります。

IPS ポリシーのオプションは何ですか?

すべてのオンボーディング済みデバイスは、「デフォルトオーバーライド」と呼ばれる CDO 提供の IPS ポリシーに自動的に関連付けられます。CDO はすべての FTD デバイスに対して新しい IPS ポリシーを生成するため、この名前のポリシーが複数存在する場合があります。デフォルトの IP ポリシーを使用し、署名のオーバーライドオプションを変更する場合は、『Firepower 侵入ポリシーの署名のオーバーライド』を参照してください。デバイスごとに異なる署名オーバーライドを構成すると、デフォルトのオーバーライドポリシーに不整合が発生する可能性があることに注意してください。

すべてのデバイスに異なる IPS ポリシーを構成するにはどうすればよいですか?

CDO はすべての FTD デバイスに対して新しい IPS ポリシーを生成するため、この名前のポリシーが複数存在する場合があります。各デバイスのオンボーディング後に、CDO が提供する IPS ポリシーの名前を変更する必要はありません。ポリシーを拡大すると、それに関連付けられているデバイスが表示されます。また、デバイスまたはポリシーごとに脅威イベントページと署名オーバーライドページをフィルタ処理することもできます。デフォルトのオーバーライドポリシーをカスタマイズするには、デバイスごとに署名のオーバーライドを構成します。これにより、デフォルトのオーバーライド侵入ポリシーに不整合が生じますが、これによって機能が阻害されることはありません。

FDM からオーバーライドが構成されているデバイスをオンボーディングしました。

CDO の外部で構成されたオーバーライドは、デバイスの構成または機能に問題を引き起こしません。

すでにオーバーライドが構成されているデバイスをオンボーディングし、この新しいデバイスがオーバーライドが構成されていないデバイスと IPS ポリシーを共有している場合、IPS ポリシー不整合として表示されます。不整合に対処するには、『Firepower 侵入ポリシーの署名のオーバーライド』のステップ 3 を参照してください。

復号再署名がブラウザでは機能するがアプリでは機能しない Web サイトの処理（SSL または認証局ピニング）

スマートフォンおよびその他のデバイス用の一部のアプリケーションでは「SSL（または認証局）ピニング」と呼ばれる手法が使用されます。SSL ピニング手法では、元のサーバー証明書のハッシュがアプリケーション自体の内部に埋め込まれます。その結果、アプリケーションが再署名された証明書を Firepower Threat Defense デバイスから受け取ると、ハッシュ検証に失敗し、接続が中断されます。

Web サイトのアプリケーションを使用してそのサイトに接続することができないにもかかわらず、Web ブラウザを使用する場合は、接続に失敗したアプリケーションを使用したデバイス上のブラウザでも接続できるというのが主な症状です。たとえば、Facebook の iOS または Android アプリケーションを使用すると接続に失敗しますが、Safari または Chrome で https://www.facebook.com/ を指定すると接続に成功します。

SSL ピニングは特に中間者攻撃を回避するために使用されるため、回避策はありません。次のいずれかの選択肢を使用する必要があります。

• アプリケーションのユーザをサポートします。この場合は、サイトへのトラフィックを復号できません。[SSL復号（SSL Decryption）] ルールの [アプリケーション（Application）] タブで、サイトのアプリケーションの [復号しない（Do Not Decrypt）] ルールを作成し、そのルールが、接続に適用される [再署名の復号（Decrypt Re-sign）] ルールの前に適用されることを確認します。

• ユーザにブラウザだけを使用させます。サイトへのトラフィックを復号する必要がある場合は、ネットワーク経由での接続にサイトのアプリケーションを使用できないため、ブラウザのみを使用しなければならないことをユーザーに通知する必要があります。

詳細

サイトがブラウザでは機能するのに同じデバイス上のアプリケーションでは機能しない場合は、ほぼ確実に SSL ピニングによるものと考えられます。ただし、詳しく調べる必要がある場合は、ブラウザのテストに加えて、接続イベントを使用して SSL ピニングを識別できます。

アプリケーションは、次の 2 つの方法でハッシュ検証の失敗に対処する場合があります。

• グループ 1 のアプリケーション（Facebook など）は、サーバから SH、CERT、SHD メッセージを受け取るとすぐに SSL ALERT メッセージを送信します。アラートは、通常、SSL ピニングを示す「Unknown CA (48)」アラートです。アラート メッセージの後に TCP リセットが送信されます。イベントの詳細情報で次のような症状が見られます。

  • SSL フロー フラグには ALERT_SEEN が含まれます。

  • SSL フロー フラグには APP_DATA_C2S または APP_DATA_S2C は含まれません。

  • SSL フロー メッセージは、通常、CLIENT_HELLO、SERVER_HELLO、SERVER_CERTIFICATE、SERVER_KEY_EXCHANGE、SERVER_HELLO_DONE です。

• グループ 2 のアプリケーション（Dropbox など）はアラートを送信しません。代わりに、ハンドシェイクが完了するまで待ってから TCP リセットを送信します。イベントで次のような症状が見られます。

  • SSL フロー フラグには ALERT_SEEN、APP_DATA_C2S または APP_DATA_S2C は含まれません。

  • SSL フロー メッセージは、通常、CLIENT_HELLO、SERVER_HELLO、SERVER_CERTIFICATE、SERVER_KEY_EXCHANGE、SERVER_HELLO_DONE、CLIENT_KEY_EXCHANGE、CLIENT_CHANGE_CIPHER_SPEC、CLIENT_FINISHED、SERVER_CHANGE_CIPHER_SPEC、SERVER_FINISHED です。

CA 証明書のダウンロードボタンが無効になっている

CDO でステージングされているが、まだデバイスに展開されていない証明書（自己署名およびアップロード）のダウンロードボタンが無効になっています。証明書は、デバイスへの展開後のみダウンロードできます。

イベントの説明エラー

CDO で FTD HA ペアをオンボードまたは作成しようとすると、HA ペアの形成に失敗し、次のメッセージとともにエラーが表示される場合があります。

[イベントの説明（Event description）]：CD App Sync エラーは、Cisco Threat Response がアクティブデバイスで有効になっていて、スタンバイでは有効になっていない場合に表示されます（CD App Sync error is Cisco Threat Response is enabled on Active but not on Standb）。

このエラーが表示された場合、HA ペア内の一方または両方のデバイスが、イベントを CDO、Firepower Threat Response、または Cisco Success Network などの Cisco Cloud サーバーに送信できるように設定されていません。

FDM UI から、[Cisco Cloudにイベントを送信（Send Events to the Cisco Cloud）] 機能を有効にする必要があります。詳細については、実行しているバージョンの Firepower Device Manager 設定ガイド [英語] の「Configuring Cloud Services」の章を参照してください。https://www.cisco.com/c/en/us/support/security/firepower-ngfw/products-installation-and-configuration-guides-list.html

HA を作成後、デバイスの 1 つが不良状態になります。

HA の作成中にいずれかのデバイスが異常または障害状態になった場合は、HA ペアを解除してデバイスの状態を解決してから、HA を再作成します。フェールオーバーの履歴は、問題の診断に役立つ場合があります。FTD の高可用性フェールオーバーの履歴

SEC のオンボーディングに失敗しました

症状：SEC のオンボーディングに失敗しました。

修復：SEC を取り外して、再度オンボードします。

このエラーが表示された場合：

1. 仮想マシンコンテナから Secure Event Connector とそのファイルを削除します。

2. Secure Device Connector の更新。通常、SDC は自動的に更新されるためこの手順を行う必要はありませんが、トラブルシューティングではこの手順が役立ちます。

3. SDC 仮想マシンへの Secure Event Connector のインストール。

ヒント	SEC をオンボードするときは、常にコピーリンクを使用してブートストラップデータをコピーします。

（注）	この手順で問題が解決しない場合は、トラブルシューティングログを収集し、マネージド サービス プロバイダーまたは Cisco Technical Assistance Center に連絡してください。

SEC ブートストラップデータが指定されていません

メッセージ：ERROR cannot bootstrap Secure Event Connector, bootstrap data not provided, exiting.

 [sdc@localhost ~]$ /usr/local/cdo/toolkit/sec.sh setup 
Please input the bootstrap data from Setup Secure Event Connector page of CDO: 
[2020-06-10 04:37:26] ERROR cannot bootstrap Secure Event Connector, bootstrap data not provided, exiting. 

診断：プロンプトが表示されたときに、ブートストラップデータがセットアップスクリプトに入力されませんでした。

修復：オンボーディング時にブートストラップデータの入力を求められたら、CDO UI で生成された SEC ブートストラップデータを指定します。

ブートストラップ構成ファイルが存在しません

メッセージ：ERROR Cannot bootstrap Secure Event Connector for tenant: <tenant_name>, bootstrap config file ("/usr/local/cdo/es_bootstrapdata") does not exist, exiting.

診断：SEC ブートストラップ データ ファイル（"/usr/local/cdo/es_bootstrapdata"）が存在しません。

修復：CDO UI で生成された SEC ブートストラップデータをファイル /usr/local/cdo/es_bootstrapdata に配置し、オンボーディングを再試行します。

1. オンボーディング手順を繰り返します。

2. ブートストラップデータをコピーします。

3. 「sdc」ユーザーとして SEC VM にログインします。

4. CDO UI で生成された SEC ブートストラップデータをファイル /usr/local/cdo/es_bootstrapdata に配置し、オンボーディングを再試行します。

ブートストラップデータのデコードに失敗しました

メッセージ：ERROR cannot bootstrap Secure Event Connector for tenant: <tenant_name>, faile to decode SEC boostrap data, exiting.

[sdc@localhost ~]$ /usr/local/cdo/toolkit/sec.sh setup
base64: invalid input
[2020-06-10 04:37:26] ERROR cannot bootstrap Secure Event Connector for tenant: tenant_XYZ, failed to decode SEC bootstrap data, exiting. 

診断：ブートストラップデータのデコードに失敗しました

修復：SEC ブートストラップデータを再生成し、オンボーディングを再試行します。

ブートストラップデータに SEC をオンボードするために必要な情報がありません

メッセージ：

• ERROR cannot bootstrap Secure Event Connector container for tenant: <tenant_name>, SSE_FQDN not set, exiting.

• ERROR cannot bootstrap Secure Event Connector container for tenant: <tenant_name>, SSE_OTP not set, exiting.

 [sdc@localhost ~]$ /usr/local/cdo/toolkit/sec.sh setup 
[2020-06-10 04:37:26] ERROR cannot bootstrap Secure Event Connector for tenant: tenant_XYZ, SSE_FQDN not set, exiting. 

[sdc@localhost ~]$ /usr/local/cdo/toolkit/sec.sh setup 
[2020-06-10 04:37:26] ERROR cannot bootstrap Secure Event Connector for tenant: tenant_XYZ, SSE_FQDN not set, exiting. 

診断：ブートストラップデータに SEC をオンボードするために必要な情報がありません。

修復：ブートストラップデータを再生成し、オンボーディングを再試行します。

ツールキット cron が現在実行中

メッセージ：ERROR SEC toolkit already running, exiting.

 [sdc@localhost ~]$ /usr/local/cdo/toolkit/sec.sh setup
 [2020-06-10 04:37:26] ERROR SEC toolkit already running.

診断：ツールキット cron が現在実行中です。

修復：オンボーディングコマンドを再試行します。

十分な CPU とメモリがない

メッセージ：ERROR unable to setup Secure Event Connector, minimum 4 cpus and 8 GB ram required, exiting.

 [sdc@localhost ~]$ /usr/local/cdo/toolkit/sec.sh setup 
[2020-06-10 04:37:26] ERROR unable to setup Secure Event Connector, minimum 4 cpus and 8 GB ram required, exiting. 

診断：十分な CPU とメモリがありません。

修復：VM の SEC 専用に最低 4 つの CPU と 8 GB の RAM がプロビジョニングされていることを確認し、オンボーディングを再試行します。

SEC がすでに実行中

メッセージ：ERROR Secure Event Connector already running, execute 'cleanup' before onboarding a new Secure Event Connector, exiting.

[sdc@localhost ~]$ /usr/local/cdo/toolkit/sec.sh setup 
[2020-06-10 04:37:26] ERROR Secure Event Connector already running, execute 'cleanup' before onboarding a new Secure Event Connector, exiting. 

診断：SEC がすでに実行中です。

修復：新しい SEC をオンボードする前に、SEC cleanup コマンドを実行します。

SEC ドメインに到達不能

メッセージ：

• Failed connect to api-sse.cisco.com:443; Connection refused

• ERROR unable to setup Secure Event Connector, domain api-sse.cisco.com unreachable, exiting.

 [sdc@localhost ~]$ /usr/local/cdo/toolkit/sec.sh setup 
curl: (7) Failed connect to api-sse.cisco.com:443; Connection refused 
[2020-06-10 04:37:26] ERROR unable to setup Secure Event Connector, domain api-sse.cisco.com unreachable, exiting. 

診断：SEC ドメインに到達できません。

修復：オンプレミス SDC にインターネット接続があることを確認し、オンボーディングを再試行します。

オンボーディング SEC コマンドはエラーなしで成功しましたが、SEC Docker コンテナが起動していません

症状：オンボーディング SEC コマンドはエラーなしで成功しましたが、SEC Docker コンテナが起動していません

診断：オンボーディング SEC コマンドはエラーなしで成功しましたが、SEC docker コンテナが起動していません

修復：

1. 「sdc」ユーザーとして SEC にログインします。

2. SEC Docker コンテナの起動ログ（/usr/local/cdo/data/<tenantDir>/event_streamer/logs/startup.log）でエラーがないか確認してください。

3. エラーがある場合は、SEC cleanup コマンドを実行して、オンボーディングを再試行してください。

CDO サポートに連絡する

いずれのシナリオにも当てはまらない場合は、Cisco Technical Assistance Center でケースを開いてください。

IPS ポリシーのオプションは何ですか?

すべてのオンボーディング済みデバイスは、「デフォルトオーバーライド」と呼ばれる CDO 提供の IPS ポリシーに自動的に関連付けられます。CDO はすべての FTD デバイスに対して新しい IPS ポリシーを生成するため、この名前のポリシーが複数存在する場合があります。デフォルトの IP ポリシーを使用し、署名のオーバーライドオプションを変更する場合は、『Firepower 侵入ポリシーの署名のオーバーライド』を参照してください。デバイスごとに異なる署名オーバーライドを構成すると、デフォルトのオーバーライドポリシーに不整合が発生する可能性があることに注意してください。

すべてのデバイスに異なる IPS ポリシーを構成するにはどうすればよいですか?

CDO はすべての FTD デバイスに対して新しい IPS ポリシーを生成するため、この名前のポリシーが複数存在する場合があります。各デバイスのオンボーディング後に、CDO が提供する IPS ポリシーの名前を変更する必要はありません。ポリシーを拡大すると、それに関連付けられているデバイスが表示されます。また、デバイスまたはポリシーごとに脅威イベントページと署名オーバーライドページをフィルタ処理することもできます。デフォルトのオーバーライドポリシーをカスタマイズするには、デバイスごとに署名のオーバーライドを構成します。これにより、デフォルトのオーバーライド侵入ポリシーに不整合が生じますが、これによって機能が阻害されることはありません。

FDM からオーバーライドが構成されているデバイスをオンボーディングしました。

CDO の外部で構成されたオーバーライドは、デバイスの構成または機能に問題を引き起こしません。

すでにオーバーライドが構成されているデバイスをオンボーディングし、この新しいデバイスがオーバーライドが構成されていないデバイスと IPS ポリシーを共有している場合、IPS ポリシー不整合として表示されます。不整合に対処するには、『Firepower 侵入ポリシーの署名のオーバーライド』のステップ 3 を参照してください。

CDO での証明書の使用

CDO は、デバイスに接続するときに証明書の有効性をチェックします。具体的には、CDO は次のことを要求します。

1. デバイスで TLS バージョン 1.0 以降を使用している。

2. デバイスにより提示される証明書が有効期限内であり、発効日が過去の日付である（すなわち、すでに有効になっており、後日に有効化されるようにスケジュールされていない）。

3. 証明書は、SHA-256 証明書であること。SHA-1 証明書は受け入れられません。

4. 次のいずれかが該当すること。

   • デバイスは自己署名証明書を使用し、その証明書は認可されたユーザーにより信頼された最新の証明書と同じである。

   • デバイスは、信頼できる認証局（CA）が署名した証明書を使用し、提示されたリーフ証明書から関連 CA にリンクしている証明書チェーンを形成している。

これらは、ブラウザとは異なる CDO の証明書の使用方法です。

• 自己署名証明書の場合、CDO は、デバイスのオンボーディングまたは再接続時に、ドメイン名チェックを無効にして、代わりに、その証明書が承認ユーザーによって信頼された証明書と完全に一致することをチェックします。

• CDOは、まだ内部 CA をサポートしていません。現時点では、内部 CA によって署名された証明書をチェックする方法はありません。

  ASA デバイスの証明書チェックを、デバイスごとに無効にすることができます。ASA の証明書を CDO が信頼できない場合、そのデバイスの証明書チェックを無効にするオプションがあります。デバイスの証明書チェックの無効化を試みても依然としてデバイスをオンボードできない場合は、デバイスに関して指定した IP アドレスおよびポートが正しくないか到達可能ではない可能性があります。証明書チェックをグローバルに無効にする方法、またはサポートされている証明書を持つデバイスの証明書チェックを無効にする方法はありません。非 ASA デバイスの証明書チェックを無効にする方法はありません。

  デバイスの証明書チェックを無効にしても、CDO は、引き続き TLS を使用してデバイスに接続しますが、接続の確立に使用される証明書を検証しません。つまり、パッシブ中間者攻撃者は接続を盗聴できませんが、アクティブ中間攻撃者は、無効な証明書を CDO に提供することによって、接続を傍受する可能性があります。

証明書の問題の特定

いくつかの理由で CDO がデバイスをオンボードできない場合があります。UI に「CDO cannot connect to the device using the certificate presented」というメッセージが表示される場合は、証明書に問題があります。このメッセージが UI に表示されない場合は、問題が接続の問題 (デバイスに到達できない) またはその他のネットワークエラーに関連している可能性が高くなります。

CDO が特定の証明書を拒否する理由を判断するには、SDC ホスト、または関連デバイスに到達できる別のホストで、openssl コマンドラインツールを使用します。次のコマンドを使用して、デバイスによって提示された証明書を示すファイルを作成します。

openssl s_client -showcerts -connect <host>:<port> &> <filename>.txt

このコマンドでは、対話型セッションが開始されるため、数秒後に Ctrl+C キーを押して終了する必要があります。

次のような出力を含むファイルが作成されます。

depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA 
verify return:1
depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2 
verify return:1 
depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = *.google.com 
verify return:1 CONNECTED(00000003)
---
Certificate chain
0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com 
  i:/C=US/O=Google Inc/CN=Google Internet Authority G2
-----BEGIN CERTIFICATE----- 
MIIH0DCCBrigAwIBAgIIUOMfH+8ftN8wDQYJKoZIhvcNAQELBQAwSTELMAkGA1UE 
....lots of base64... 
tzw9TylimhJpZcl4qihFVTgFM7rMU2VHulpJgA59gdbaO/Bf
-----END CERTIFICATE-----
1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2 
  i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA 
-----BEGIN CERTIFICATE----- 
MIID8DCCAtigAwIBAgIDAjqSMA0GCSqGSIb3DQEBCwUAMEIxCzAJBgNVBAYTAlVT 
....lots of base64... 
tzw9TylimhJpZcl4qihFVTgFM7rMU2VHulpJgA59gdbaO/Bf 
-----END CERTIFICATE----- 
2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA 
  i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority 
-----BEGIN CERTIFICATE----- 
MIIDfTCCAuagAwIBAgIDErvmMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVT 
....lots of base64... 
b8ravHNjkOR/ez4iyz0H7V84dJzjA1BOoa+Y7mHyhD8S 
-----END CERTIFICATE-----
--- 
Server certificate 
subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com 
issuer=/C=US/O=Google Inc/CN=Google Internet Authority G2 
---
No client certificate CA names sent 
Peer signing digest: SHA512 
Server Temp Key: ECDH, P-256, 256 bits

--- 
SSL handshake has read 4575 bytes and written 434 bytes 
--- 
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256 
Server public key is 2048 bit Secure Renegotiation IS supported 
Compression: NONE 
Expansion: NONE 
No ALPN negotiated 
SSL-Session:    
    Protocol : TLSv1.2 
    Cipher : ECDHE-RSA-AES128-GCM-SHA256 
    Session-ID: 48F046F3360225D51BE3362B50CE4FE8DB6D6B80B871C2A6DD5461850C4CF5AB 
    Session-ID-ctx: 
    Master-Key: 9A9CCBAA4F5A25B95C37EF7C6870F8C5DD3755A9A7B4CCE4535190B793DEFF53F94203AB0A62F9F70B9099FBFEBAB1B6 
    Key-Arg : None 
    PSK identity: None 
    PSK identity hint: None 
    SRP username: None 
    TLS session ticket lifetime hint: 100800 (seconds) 
    TLS session ticket: 
    0000 - 7a eb 54 dd ac 48 7e 76-30 73 b2 97 95 40 5b de z.T..H~v0s...@[. 
    0010 - f3 53 bf c8 41 36 66 3e-5b 35 a3 03 85 6f 7d 0c .S..A6f>[5...o}. 
    0020 - 4b a6 90 6f 95 e2 ec 03-31 5b 08 ca 65 6f 8f a6 K..o....1[..eo.. 
    0030 - 71 3d c1 53 b1 29 41 fc-d3 cb 03 bc a4 a9 33 28 q=.S.)A.......3( 
    0040 - f8 c8 6e 0a dc b3 e1 63-0e 8f f2 63 e6 64 0a 36 ..n....c...c.d.6 
    0050 - 22 cb 00 3a 59 1d 8d b2-5c 21 be 02 52 28 45 9d "..:Y...\!..R(E. 
    0060 - 72 e3 84 23 b6 f0 e2 7c-8a a3 e8 00 2b fd 42 1d r..#...|....+.B. 
    0070 - 23 35 6d f7 7d 85 39 1c-ad cd 49 f1 fd dd 15 de #5m.}.9...I..... 
    0080 - f6 9c ff 5e 45 9c 7c eb-6b 85 78 b5 49 ea c4 45 ...^E.|.k.x.I..E 
    0090 - 6e 02 24 1b 45 fc 41 a2-87 dd 17 4a 04 36 e6 63 n.$.E.A....J.6.c 
    00a0 - 72 a4 ad 
    00a4 - <SPACES/NULS> Start Time: 1476476711 Timeout : 300 (sec)
Verify return code: 0 (ok)
---  

この出力では、最初に、確認リターン（verify return）コードが示されている最後の行に注目してください。証明書に関する問題が存在する場合、このリターンコードはゼロ以外になり、エラーの説明が表示されます。

この証明書エラーコードのリストを展開して、一般的なエラーとその修正方法を確認してください。

0 X509_V_OK：操作が成功しました。

2 X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT：信頼できない証明書の発行者証明書が見つかりませんでした。

3 X509_V_ERR_UNABLE_TO_GET_CRL 証明書の CRL が見つかりませんでした。

4 X509_V_ERR_UNABLE_TO_DECRYPT_CERT_SIGNATURE 証明書の署名を復号化できませんでした。これは、実際の署名値が、期待値と一致しないのではなく、判別できなかったことを意味します。これは、RSA キーに対してのみ意味があります。

5 X509_V_ERR_UNABLE_TO_DECRYPT_CRL_SIGNATURE CRL 署名を復号化できませんでした。これは、実際の署名値が、期待値と一致しないのではなく、判別できなかったことを意味します。未使用。

6 X509_V_ERR_UNABLE_TO_DECODE_ISSUER_PUBLIC_KEY：証明書 SubjectPublicKeyInfo の公開キーを読み取れませんでした。

7 X509_V_ERR_CERT_SIGNATURE_FAILURE：証明書の署名が無効です。

8 X509_V_ERR_CRL_SIGNATURE_FAILURE：証明書の署名が無効です。

9 X509_V_ERR_CERT_NOT_YET_VALID：証明書がまだ有効ではありません（notBefore の日付が現在時刻より後です）。詳細については、この後の「確認リターンコード：9（証明書がまだ有効ではありません）」を参照してください。

10 X509_V_ERR_CERT_HAS_EXPIRED：証明書の有効期限が切れています（notAfter の日付が現在時刻より前です）。詳細については、この後の「確認リターンコード：10（証明書の有効期限が切れています）」を参照してください。

11 X509_V_ERR_CRL_NOT_YET_VALID：CRL がまだ有効ではありません。

12 X509_V_ERR_CRL_HAS_EXPIRED：CRL の有効期限が切れています。

13 X509_V_ERR_ERROR_IN_CERT_NOT_BEFORE_FIELD：証明書の notBefore フィールドに無効な時刻が含まれています。

14 X509_V_ERR_ERROR_IN_CERT_NOT_AFTER_FIELD：証明書の notAfter フィールドに無効な時刻が含まれています。

15 X509_V_ERR_ERROR_IN_CRL_LAST_UPDATE_FIELD：CRL の lastUpdate フィールドに無効な時刻が含まれています。

16 X509_V_ERR_ERROR_IN_CRL_NEXT_UPDATE_FIELD：CRL の nextUpdate フィールドに無効な時刻が含まれています。

17 X509_V_ERR_OUT_OF_MEM：メモリを割り当てようとしてエラーが発生しました。これは決して発生しないはずの問題です。

18 X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT：渡された証明書は自己署名済みであり、信頼できる証明書のリストに同じ証明書が見つかりません。

19 X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN：信頼できない証明書を使用して証明書チェーンを構築できましたが、ルートがローカルで見つかりませんでした。

20 X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY：ローカルでルックアップされた証明書の発行者証明書が見つかりませんでした。これは、通常、信頼できる証明書のリストが完全ではないことを意味します。

21 X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE：チェーンに証明書が 1 つしか含まれておらず、それが自己署名済みでないため、署名を検証できませんでした。詳細については、この後の「確認リターンコード：21（最初の証明書を検証できません）」を参照してください。詳細については、この後の「確認リターンコード：21（最初の証明書を検証できません）」を参照してください。

22 X509_V_ERR_CERT_CHAIN_TOO_LONG：証明書チェーンの長さが、指定された最大深度を超えています。未使用。

23 X509_V_ERR_CERT_REVOKED：証明書が失効しています。

24 X509_V_ERR_INVALID_CA：CA 証明書が無効です。CA ではないか、その拡張領域が、提供された目的と一致していません。

25 X509_V_ERR_PATH_LENGTH_EXCEEDED：basicConstraints の pathlength パラメータを超えています。

26 X509_V_ERR_INVALID_PURPOSE：提供された証明書を、指定された目的に使用できません。

27 X509_V_ERR_CERT_UNTRUSTED：ルート CA が、指定された目的に関して信頼できるものとしてマークされていません。

28 X509_V_ERR_CERT_REJECTED：ルート CA が、指定された目的を拒否するようにマークされています。

29 X509_V_ERR_SUBJECT_ISSUER_MISMATCH：件名が現在の証明書の発行者名と一致しないため、現在の候補発行者証明書が拒否されました。-issuer_checks オプションが設定されている場合にのみ表示されます。

30 X509_V_ERR_AKID_SKID_MISMATCH：件名キー識別子が存在し、現在の証明書の認証局キー識別子と一致しないため、現在の候補発行者証明書が拒否されました。-issuer_checks オプションが設定されている場合にのみ表示されます。

31 X509_V_ERR_AKID_ISSUER_SERIAL_MISMATCH：発行者名とシリアル番号が存在し、現在の証明書の認証局キー識別子と一致しないため、現在の候補発行者証明書が拒否されました。-issuer_checks オプションが設定されている場合にのみ表示されます。

32 X509_V_ERR_KEYUSAGE_NO_CERTSIGN：keyUsage 拡張領域が証明書の署名を許可していないため、現在の候補発行者証明書が拒否されました。

50 X509_V_ERR_APPLICATION_VERIFICATION：アプリケーション固有のエラーです。未使用。

新しい証明書が検出されました

自己署名証明書を持つデバイスをアップグレードして、アップグレードプロセス後に新しい証明書が生成された場合、CDO は、設定（Configuration）] ステータスおよび [接続（Connectivity）] の両方のステータスとして、「新しい証明書が検出されました（New Certificate Detected）」メッセージを生成する場合があります。このデバイスを CDO から管理する前に、この問題を手動で確認して解決する必要があります。証明書が同期されて、デバイスの状態が正常になったら、このデバイスを管理できます。

（注）	複数の管理対象デバイスを CDO に同時に一括再接続すると、CDO は、デバイス上の新しい証明書を自動的に確認して受け入れ、それらとの再接続を続行します。

新しい証明書を解決するには、次の手順を使用します。

1. [デバイスとサービス（Device & Services）] ページに移動します。

2. フィルタを使用して、接続ステータスまたは設定ステータスが [新しい証明書が検出されました（New Certificate Detected）] であるデバイスを表示し、必要なデバイスを選択します。

3. [アクション（Action）] ペインで、[証明書の確認（Review Certificate）] をクリックします。CDO では、確認のために証明書をダウンロードし、新しい証明書を受け入れることができます。

4. [デバイス同期（Device Sync）] ウィンドウで [承認（Accept）] をクリックするか、[デバイスへの再接続（Reconnecting to Device）] ウィンドウで [続行（Continue）] をクリックします。

   CDO は、デバイスを新しい自己署名証明書と自動的に同期します。 同期されたデバイスを表示するには、[デバイスとサービス（Devices & Services）] ページを手動で更新する必要がある場合があります。

証明書エラーコード

確認リターンコード：0（OK）（ただし、CDO は証明書エラーを返します）

CDO は、証明書を取得すると、「https://<device_ip>:<port>」への GET コールを実行することにより、デバイスの URL への接続を試みます。これが機能しない場合、CDO は証明書エラーを表示します。証明書が有効である（openssl が 0 つまり OK を返します）ことがわかった場合、接続しようとしているポートで別のサービスがリッスンしている可能性があります。この場合、次のコマンドを使用できます。

 curl -k -u <username>:<password> https://<device_id>:<device_port>/admin/exec/show%20version

これにより、次のように、ASA と確実に通信しているかどうかを確認することができ、HTTPS サーバーが ASA の正しいポートで動作しているかどうかをチェックすることもできます。

 # show asp table socket
Protocol         Socket         State         Local Address             Foreign Address 
SSL             00019b98         LISTEN        192.168.1.5:443             0.0.0.0:* 
SSL             00029e18         LISTEN        192.168.2.5:443             0.0.0.0:* 
TCP             00032208         LISTEN        192.168.1.5:22              0.0.0.0:* 

確認リターンコード：9（証明書がまだ有効ではありません）

このエラーは、提供された証明書の発行日が将来の日付であるため、クライアントがそれを有効なものとして扱わないことを意味します。これは、証明書の不完全な作成が原因である可能性があります。また、自己署名証明書の場合は、証明書生成時のデバイスの時刻が間違っていたことが原因である可能性があります。

エラーには、証明書の notBefore の日付が含まれた行があります。

depth=0 CN = ASA Temporary Self Signed Certificate 
verify error:num=18:self signed certificate 
verify return:1 
depth=0 CN = ASA Temporary Self Signed Certificate 
verify error:num=9:certificate is not yet valid
notBefore=Oct 21 19:43:15 2016 GMT 
verify return:1 
depth=0 CN = ASA Temporary Self Signed Certificate 
notBefore=Oct 21 19:43:15 2016 GMT 

このエラーから、証明書がいつ有効になるかを判別できます。

修復

証明書の notBefore の日付は過去の日付である必要があります。notBefore の日付をより早い日付にして証明書を再発行できます。この問題は、クライアントまたは発行デバイスのいずれかで時刻が正しく設定されていない場合にも発生する可能性があります。

確認リターンコード：10（証明書の有効期限が切れています）

このエラーは、提供された証明書の少なくとも 1 つが期限切れであることを意味します。エラーには、証明書の notBefore の日付が含まれた行があります。

 error 10 at 0 depth lookup:certificate has expired 

この有効期限は、証明書の本文に含まれています。

修復

証明書が本当に期限切れの場合、唯一の修復方法は、別の証明書を取得することです。証明書の有効期限が将来の日付であるのに、openssl が期限切れであると主張する場合は、コンピュータの日付と時刻をチェックしてください。たとえば、証明書が 2020 年に期限切れになるように設定されているのに、コンピュータの日付が 2021 年になっている場合、そのコンピュータは証明書を期限切れとして扱います。

確認リターンコード：21（最初の証明書を検証できません）

このエラーは、証明書チェーンに問題があり、デバイスによって提示された証明書が信頼できるものであることを openssl が検証できないことを示しています。ここで、上記の例の証明書チェーンを調べて、証明書チェーンがどのように機能するのかを見てみましょう。

--- 
Certificate chain 
0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com 
i:/C=US/O=Google Inc/CN=Google Internet Authority G2

-----BEGIN CERTIFICATE----- 
MIIH0DCCBrigAwIBAgIIUOMfH+8ftN8wDQYJKoZIhvcNAQELBQAwSTELMAkGA1UE 
....lots of base64... 
tzw9TylimhJpZcl4qihFVTgFM7rMU2VHulpJgA59gdbaO/Bf 
-----END CERTIFICATE----- 

1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2 
i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA 

-----BEGIN CERTIFICATE----- 
MIID8DCCAtigAwIBAgIDAjqSMA0GCSqGSIb3DQEBCwUAMEIxCzAJBgNVBAYTAlVT 
....lots of base64... 
tzw9TylimhJpZcl4qihFVTgFM7rMU2VHulpJgA59gdbaO/Bf 
-----END CERTIFICATE----- 

2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA 
i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority 

-----BEGIN CERTIFICATE----- 
MIIDfTCCAuagAwIBAgIDErvmMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVT 
....lots of base64... 
b8ravHNjkOR/ez4iyz0H7V84dJzjA1BOoa+Y7mHyhD8S 
-----END CERTIFICATE----- --- 

証明書チェーンとは、サーバーによって提示される証明書のリストです。このリストは、サーバー自体の証明書から始まり、そのサーバーの証明書を認証局の最上位の証明書に結び付ける、段階的により上位の中間証明書が含まれます。各証明書には、その件名（「s:」で始まる行）とその発行者（「i」で始まる行）のリストが示されています。

件名は、証明書によって識別されるエンティティです。これには、組織名が含まれており、場合によっては証明書の発行先エンティティの共通名も含まれます。

発行者は、証明書を発行したエンティティです。これには、組織フィールドも含まれており、場合によっては共通名も含まれます。

サーバーは、信頼できる認証局によって直接発行された証明書を持っている場合、証明書チェーンに他の証明書を含める必要がありません。次のような 1 つの証明書が表示されます。

--- Certificate chain 0 s:/C=US/ST=California/L=Anytown/O=ExampleCo/CN=*.example.com i:/C=US/O=Trusted Authority/CN=Trusted Authority 
-----BEGIN CERTIFICATE----- 
MIIH0DCCBrigAwIBAgIIUOMfH+8ftN8wDQYJKoZIhvcNAQELBQAwSTELMAkGA1UE 
....lots of base64... 
tzw9TylimhJpZcl4qihFVTgFM7rMU2VHulpJgA59gdbaO/Bf 
-----END CERTIFICATE----- --- 

この証明書を提供すると、openssl は、*.example.com の ExampleCo 証明書が、openssl の組み込み信頼ストアに存在する信頼できる認証局の証明書によって正しく署名されていることを検証します。その検証の後に、openssl は、デバイスに正常に接続します。

ただし、ほとんどのサーバーには、信頼できる CA によって直接署名された証明書がありません。代わりに、最初の例のように、サーバーの証明書は 1 つ以上の中間証明書によって署名されており、最上位の中間証明書が、信頼できる CA によって署名された証明書を持ちます。OpenSSL は、デフォルトでは、これらの中間 CA を信頼せず、信頼できる CA で終わる完全な証明書チェーンが提供されている場合にのみ、それらを検証できます。

中間認証局によって署名された証明書を持つサーバーが、信頼できる CA にリンクするすべての証明書 (すべての中間証明書を含む) を提供することが非常に重要です。このチェーン全体を提供しない場合、openssl からの出力は次のようになります。

depth=0 OU = Example Unit, CN = example.com 
verify error:num=20:unable to get local issuer certificate 
verify return:1 

depth=0 OU = Example Unit, CN = example.com 
verify error:num=27:certificate not trusted 
verify return:1 

depth=0 OU = Example Unit, CN = example.com 
verify error:num=21:unable to verify the first certificate 
verify return:1

CONNECTED(00000003)

--- 
Certificate chain 
0 s:/OU=Example Unit/CN=example.com 
i:/C=US/ST=Massachusetts/L=Cambridge/O=Intermediate Authority/OU=http://certificates.intermediateauth...N=Intermediate Certification Authority/sn=675637734 
-----BEGIN CERTIFICATE-----
...lots of b64...
-----END CERTIFICATE-----
--- 
Server certificate 
subject=/OU=Example Unit/CN=example.com 
issuer=/C=US/ST=Massachusetts/L=Cambridge/O=Intermediate Authority/OU=http://certificates.intermediateauth...N=Intermediate Certification Authority/sn=675637734 
--- 
No client certificate CA names sent 
--- 
SSL handshake has read 1509 bytes and written 573 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA 
Server public key is 2048 bit 
Secure Renegotiation IS NOT supported 
Compression: NONE 
Expansion: NONE 
SSL-Session: 
Protocol : TLSv1 
Cipher : AES256-SHA 
Session-ID: 24B45B2D5492A6C5D2D5AC470E42896F9D2DDDD54EF6E3363B7FDA28AB32414B 
Session-ID-ctx: 
Master-Key: 21BAF9D2E1525A5B935BF107DA3CAF691C1E499286CBEA987F64AE5F603AAF8E65999BD21B06B116FE9968FB7C62EF7C 
Key-Arg : None 
Krb5 Principal: None 
PSK identity: None 
PSK identity hint: None 
Start Time: 1476711760 
Timeout : 300 (sec) 
Verify return code: 21 (unable to verify the first certificate) 
--- 

この出力は、サーバーが 1 つの証明書のみを提供しており、提供された証明書が信頼されたルート認証局ではなく中間認証局によって署名されていることを示しています。出力には、特性検証エラーも表示されます。

修復

この問題は、デバイスによって提示された証明書の設定が間違っているために発生します。この問題を修正して CDO またはその他のプログラムがデバイスに安全に接続できるようにする唯一の方法は、正しい証明書チェーンをデバイスにロードして、接続しているクライアントに完全な証明書チェーンを提示することです。

中間 CA をトラストポイントに含めるには、次のいずれか（CSR が ASA で生成されたかどうかに応じて）のリンク先に記載されている手順に従ってください。

• https://www.cisco.com/c/en/us/support/docs/security-vpn/public-key-infrastructure-pki/200339-Configure-ASA-SSL-Digital-Certificate-I.html#anc13

• https://www.cisco.com/c/en/us/support/docs/security-vpn/public-key-infrastructure-pki/200339-Configure-ASA-SSL-Digital-Certificate-I.html#anc15