FTD接続用FMC Sftunnel CA証明書の更新

はじめに

このドキュメントでは、Firepower Threat Defense(FTD)の接続に関連したFirepower Management Center(FMC)sftunnel(CTL)認証局(CA)証明書の更新について説明します。

前提条件

要件

次の項目に関する知識があることが推奨されます。

• Firepower Threat Defense（脅威対策）
• Firepower Management Center
• 公開キー インフラストラクチャ（PKI）

使用するコンポーネント

このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

背景説明

FMCとFTDは、sftunnel（Sourcefireトンネル）を介して相互に通信します。この通信では、証明書を使用して、TLSセッションで通信を安全にします。sftunnelの詳細と、確立方法については、このリンクを参照してください。

パケットキャプチャから、FMC（この例では10.48.79.232）とFTD(10.48.79.23)が互いに証明書を交換していることがわかります。これは、正しいデバイスと通信し、傍受や中間者攻撃(MITM)がないことを検証するためです。これらの証明書を使用して通信が暗号化され、その証明書に関連付けられた秘密キーを持つユーザだけが再度復号化できます。

証明書_exchange_server_cert

証明書_交換_クライアント_証明書

証明書が、FMCシステムで設定されているものと同じ内部CA（発行者）認証局(CA)によって署名されていることがわかります。この設定は、FMCの/etc/sf/sftunnel.confファイルで定義されています。このファイルには、次のものが含まれています。

proxyssl {
  proxy_cert   /etc/sf/keys/sftunnel-cert.pem;                ---> Certificate provided by FMC to FTD for the sftunnel communication (signed by InternalCA)
  proxy_key    /etc/sf/keys/sftunnel-key.pem;
  proxy_cacert /etc/sf/ca_root/cacert.pem;                    ---> CA certificate (InternalCA)
  proxy_crl    /etc/sf/ca_root/crl.pem;
  proxy_cipher 1;
  proxy_tls_version TLSv1.2;
}; 

これは、sftunnelのすべての証明書（FTDとFMCの両方）の署名に使用されるCAと、すべてのFTDに送信するためにFMCによって使用される証明書を示します。この証明書は内部CAによって署名されています。

FTDがFMCに登録されると、FMCは、sftunnelでの以降の通信に使用されるFTDデバイスにプッシュするための証明書も作成します。この証明書は、同じ内部CA証明書でも署名されます。FMCでは、/var/sf/peers/<UUID-FTD-device>の下、場合によってはcerts_pushedフォルダの下に、証明書（および秘密キー）が見つかります。この名前はsftunnel-cert.pem(秘密キーの場合はsftunnel-key.pem)と呼ばれます。FTDでは、/var/sf/peers/<UUID-FMC-device>の下に、同じ命名規則を持つものを見つけることができます。

ただし、セキュリティ上の理由から、各証明書には有効期間も設定されています。内部CA証明書を検査すると、パケットキャプチャから示されているように、FMC内部CAの有効期間（10年）も確認できます。

FMC内部CAの有効性(_V)

問題

FMC内部CA証明書の有効期間は10年です。有効期限が切れると、リモートシステムはこの証明書（および証明書によって署名された証明書）を信頼しなくなり、FTDとFMCデバイス間のsftunnel通信の問題が発生します。これは、接続イベント、マルウェア検索、IDベースのルール、ポリシーの導入など、いくつかの重要な機能が動作していないことを意味します。

sftunnelが接続されていない場合、FMCのUIのDevices > Device Managementタブにデバイスがdisabledと表示されます。この期限切れに関連する問題は、Cisco Bug ID CSCwd08098で追跡されています。不具合の修正済みリリースを実行している場合でも、すべてのシステムが影響を受けることに注意してください。この修正の詳細については、「ソリューション」セクションを参照してください。

無効なデバイス

FMCは、CAを自動的に更新して、証明書をFTDデバイスに再発行しません。また、証明書の有効期限を示すFMCヘルスアラートもありません。Cisco Bug ID CSCwd08448は、将来的にFMC UIのヘルスアラートを提供するためにこの点に関して追跡されています。

有効期限の後に何が起こりますか？

最初は何も起こらず、sftunnel通信チャネルは以前と同様に動作し続けます。ただし、FMCとFTDデバイス間のsftunnel通信が切断され、接続を再確立しようとすると、接続に失敗し、証明書の期限切れを示すメッセージログファイルのログ行で確認できます。

/ngfw/var/log/messagesからのFTDデバイスからのログ行：

Sep 20 04:10:47 FTD-hostname SF-IMS[50792]: [51982] sftunneld:sf_ssl [INFO] Initiating IPv4 connection to 10.10.200.31:8305/tcp
Sep 20 04:10:47 FTD-hostname SF-IMS[50792]: [51982] sftunneld:sf_ssl [INFO] Wait to connect to 8305 (IPv4): 10.10.200.31
Sep 20 04:10:47 FTD-hostname SF-IMS[50792]: [51982] sftunneld:sf_ssl [INFO] Connected to 10.10.200.31 from resolved_ip_list (port 8305) (IPv4)
Sep 20 04:10:47 FTD-hostname SF-IMS[50792]: [51982] sftunneld:sf_ssl [ERROR] -Error with certificate at depth: 1
Sep 20 04:10:47 FTD-hostname SF-IMS[50792]: [51982] sftunneld:sf_ssl [ERROR]   issuer   = /title=InternalCA/OU=Intrusion Management System/CN=06f5f3ca-c77b-11e2-81bf-884d9d11f3ef/O=Sourcefire, Inc.
Sep 20 04:10:47 FTD-hostname SF-IMS[50792]: [51982] sftunneld:sf_ssl [ERROR]   subject  = /title=InternalCA/OU=Intrusion Management System/CN=06f5f3ca-c77b-11e2-81bf-884d9d11f3ef/O=Sourcefire, Inc.
Sep 20 04:10:47 FTD-hostname SF-IMS[50792]: [51982] sftunneld:sf_ssl [ERROR]   err 10:certificate has expired
Sep 20 04:10:47 FTD-hostname SF-IMS[50792]: [51982] sftunneld:sf_ssl [ERROR] SSL_renegotiate error: 1: error:00000001:lib(0):func(0):reason(1)
Sep 20 04:10:47 FTD-hostname SF-IMS[50792]: [51982] sftunneld:sf_ssl [ERROR] Connect:SSL handshake failed
Sep 20 04:10:47 FTD-hostname SF-IMS[50792]: [51982] sftunneld:sf_ssl [WARN] SSL Verification status: certificate has expired

/var/log/messagesからのFMCデバイスからのログ行：

Sep 20 03:14:23 FMC-hostname SF-IMS[1504]: [4171] sftunneld:sf_ssl [INFO] VERIFY ssl_verify_callback_initial ok=1!
Sep 20 03:14:23 FMC-hostname SF-IMS[1504]: [4171] sftunneld:sf_ssl [ERROR] SSL_renegotiate error: 1: error:00000001:lib(0):func(0):reason(1)
Sep 20 03:14:23 FMC-hostname SF-IMS[1504]: [4171] sftunneld:sf_ssl [WARN] establishConnectionUtil: SSL handshake failed
Sep 20 03:14:23 FMC-hostname SF-IMS[1504]: [4171] sftunneld:sf_ssl [WARN] establishConnectionUtil: SSL Verification status: ok
Sep 20 03:14:23 FMC-hostname SF-IMS[1504]: [4171] sftunneld:sf_ssl [WARN] establishConnectionUtil: SSL handshake failed: error:14094415:SSL routines:ssl3_read_bytes:sslv3 alert certificate expired
Sep 20 03:14:23 FMC-hostname SF-IMS[1504]: [4171] sftunneld:sf_ssl [INFO] establishConnectionUtil: Failed to connect using SSL to: '10.10.21.10'
Sep 20 03:14:23 FMC-hostname SF-IMS[1504]: [4171] sftunneld:sf_ssl [ERROR] establishSSLConnection: Unable to connect with both threads:
Sep 20 03:14:23 FMC-hostname SF-IMS[1504]: [4171] sftunneld:sf_ssl [ERROR] establishSSLConnection: ret_accept status : Too many levels of symbolic links
Sep 20 03:14:23 FMC-hostname SF-IMS[1504]: [4171] sftunneld:sf_ssl [ERROR] establishSSLConnection: iret_connect status: Too many levels of symbolic links
Sep 20 03:14:23 FMC-hostname SF-IMS[1504]: [4171] sftunneld:sf_ssl [ERROR] establishSSLConnection: Failed connecting with SSL to using to: '10.10.21.10' rval[40] *CA cert from FMC

sftunnelの通信は、さまざまな理由で切断される可能性があります。

• ネットワーク接続の喪失による通信損失（一時的な可能性のみ）
• FTDまたはFMCのリブート
  • 予期される問題：手動リブート、アップグレード、FMCまたはFTDでのsftunnelプロセスの手動再起動（pmtool restartbyid sftunnelなどによる）
  • 想定外のもの：トレースバック、停電

sftunnelの通信を切断する可能性は非常に多いため、証明書が期限切れであるにもかかわらず現在すべてのFTDデバイスが正しく接続されている場合でも、状況をできるだけ迅速に修正することを強くお勧めします。

証明書の有効期限が切れているかどうか、または有効期限が切れているかどうかを簡単に確認する方法

最も簡単な方法は、FMCのSSHセッションで次のコマンドを実行することです。

expert
sudo su
cd /etc/sf/ca_root
openssl x509 -dates -noout -in cacert.pem

証明書の有効期間の要素が表示されます。ここで関連する主な部分は「notAfter」であり、この証明書が2034年10月5日まで有効であることを示します。

次の日付以降

証明書がまだ有効な日数を即時に示す単一のコマンドを実行する場合は、次のコマンドを使用できます。

CERT_PATH="/etc/sf/ca_root/cacert.pem"; EXPIRY_DATE=$(openssl x509 -enddate -noout -in "$CERT_PATH" | cut -d= -f2); EXPIRY_DATE_SECONDS=$(date -d "$EXPIRY_DATE" +%s); CURRENT_DATE_SECONDS=$(date +%s); THIRTY_DAYS_SECONDS=$((30*24*60*60)); EXPIRY_THRESHOLD=$((CURRENT_DATE_SECONDS + THIRTY_DAYS_SECONDS)); DAYS_LEFT=$(( (EXPIRY_DATE_SECONDS - CURRENT_DATE_SECONDS) / (24*60*60) )); if [ "$EXPIRY_DATE_SECONDS" -le "$CURRENT_DATE_SECONDS" ]; then DAYS_EXPIRED=$(( (CURRENT_DATE_SECONDS - EXPIRY_DATE_SECONDS) / (24*60*60) )); echo -e "\nThe certificate has expired $DAYS_EXPIRED days ago.\nIn case the sftunnel communication with the FTD is not yet lost, you need to take action immediately in renewing the certificate.\n"; elif [ "$EXPIRY_DATE_SECONDS" -le "$EXPIRY_THRESHOLD" ]; then echo -e "\nThe certificate will expire within the next 30 days!\nIt is ONLY valid for $DAYS_LEFT more days.\nIt is recommended to take action in renewing the certificate as quickly as possible.\n"; else echo -e "\nThe certificate is valid for more than 30 days.\nIt is valid for $DAYS_LEFT more days.\nThere is no immediate need to perform action but this depends on how far the expiry date is in the future.\n"; fi

証明書が複数年有効なセットアップの例を示します。

Certificate_expiry_validation_command（証明書の有効期限の検証コマンド）

証明書の有効期限が近づいていることが将来どのように通知されますか。

最近のVDBアップデート（399以降）では、証明書の有効期限が90日以内に切れると、自動的にアラートが通知されます。そのため、有効期限が近づいたときにアラートが通知されるので、手動で追跡する必要はありません。この結果、FMCのWebページに2つの形式で表示されます。どちらの方法もField Noticeページを参照しています。

最初の方法は、Task Tabを使用する方法です。このメッセージは固定されているため、明示的に閉じていない限り、ユーザが使用できます。通知ポップアップも表示され、ユーザが明示的に閉じるまで使用できます。これは常にエラーとして表示されます。

「タスク」タブの「期限切れ通知」

2番目の方法は、ヘルスアラートを使用する方法です。これは[正常性]タブに表示されますが、これはスティッキではなく、既定では5分ごとに実行されるヘルスモニタの実行時に置換または削除されます。また、ユーザが明示的に閉じる必要がある通知ポップアップも表示されます。この場合、両方がエラー（期限切れ時）として表示され、警告（期限切れ時）として表示されます。

[正常性]タブの有効期限の通知

ヘルスアラートポップアップに関する警告通知

ヘルスアラートポップアップのエラー通知

解決策1：証明書の有効期限がまだ切れていない（理想的なシナリオ）

証明書の期限切れに応じて、まだ時間がある場合は、これが最善の状況です。FMCバージョンに依存する完全自動アプローチ（推奨）を採用するか、TACの介入を必要とする、より手動のアプローチを採用します。

推奨されるアプローチ

これは、通常の状況ではダウンタイムがなく、手動操作の量が最小限であると予想される状況です。

続行する前に、次に示す特定のバージョンのホットフィックスをインストールする必要があります。このホットフィックスの利点は、これらのホットフィックスではFMCをリブートする必要がないため、証明書がすでに期限切れになっている場合にsftunnel通信が切断される可能性があることです。使用可能なホットフィックスは次のとおりです。

• 7.0.0 ～ 7.0.6：ホットフィックスFK - 7.0.6.99-9
• 7.1.x：ソフトウェアメンテナンス終了による修正済みリリースなし
• 7.2.0 ～ 7.2.9：ホットフィックスFZ - 7.2.9.99-4
• 7.3.x：ホットフィックスAE - 7.3.1.99-4
• 7.4.0 ～ 7.4.2：ホットフィックスAO - 7.4.2.99-5
• 7.6.0：ホットフィックスB - 7.6.0.99-5

ホットフィックスがインストールされると、FMCには次を示すgenerate_certs.plスクリプトが組み込まれます。

1. 内部CAを再生成します
2. この新しい内部CAによって署名されたsftunnel証明書を再作成します
3. 新しいsftunnel証明書と秘密キーをそれぞれのFTDデバイスにプッシュします（sftunnelが動作可能な場合）。

したがって、可能であれば次のことを行うことを推奨します。

1. ご使用のバージョン群に該当するホットフィックスをインストールします
2. FMCでバックアップを作成します。
3. (expertモードで)FMC上でsftunnel_status.plスクリプトを使用して、現在のすべてのsftunnel接続を検証します。
4. generate_certs.plを使用して、エキスパートモードからスクリプトを実行します。
5. 結果を検査して、手動操作が必要かどうかを検証します（デバイスがFMCに接続されていない場合）[詳細は以下で説明]
6. FMCからsftunnel_status.plを実行して、すべてのsftunnel接続が正常に動作していることを確認します

Generate_certs.plスクリプト

この例では、/var/log/sf/sfca_generation.logでログファイルが作成され、sftunnel_status.plの使用が示され、InternalCAの有効期限が示され、そのCAでの障害が示されています。この例では、デバイスBSNS-1120-1およびEMEA-FPR3110-08デバイスに証明書をプッシュできませんでした。これらのデバイスのsftunnelがダウンしていたために、この処理が行われることが予想されます。

失敗した接続のsftunnelを修正するには、次の手順を実行します。

1. FMC CLIで、cat /var/tmp/certs/1728303362/FAILED_PUSH（数値はUNIX時間を表すので、システム内の前のコマンドの出力を確認してください）を使用して、次の形式のFAILED_PUSHファイルを開きます。 FTD_UUID FTD_NAME FTD_IP SOURCE_PATH_ON_FMC DESTINATION_PATH_ON_FTD
   
   失敗_プッシュ
   
   
2. これらの新しい証明書(cacert.pem / sftunnel-key.pem / sftunnel-cert.pem)をFMCからFTDデバイスに転送します。
   ===自動アプローチ===
   
   ホットフィックスのインストールでは、copy_sftunnel_certs.pyおよびcopy_sftunnel_certs_jumpserver.pyスクリプトも提供されます。これらのスクリプトは、証明書の再生中にsftunnelがアップ状態ではなかったシステムへの各種証明書の転送を自動化します。これは、証明書がすでに期限切れになったためにsftunnel接続が切断されたシステムでも使用できます。
   
   copy_sftunnel_certs.py スクリプトは、FMC自体がさまざまなFTDシステムにSSHアクセスできる場合に使用できます。アクセスできない場合は、FMCから、FMCとFTDの両方のデバイスにSSHアクセスできるジャンプサーバにスクリプト(/usr/local/sf/bin/copy_sftunnel_certs_jumpserver.py)をダウンロードし、そこからPythonスクリプトを実行できます。それも不可能な場合は、次に示す手動アプローチを実行することを推奨します。次の例では、使用されているcopy_sftunnel_certs.pyスクリプトを示していますが、手順はcopy_sftunnel_certs_jumpserver.pyスクリプトと同じです。
   
   A. SSH接続の確立に使用されるデバイス情報(device_name、IP address、admin_username、admin_password)を含むCSVファイルをFMC（またはジャンプサーバ）に作成します。
   
   プライマリFMCのジャンプサーバのようにリモートサーバからこのコマンドを実行する場合は、プライマリFMCの詳細を最初のエントリとして追加し、その後にすべての管理対象FTDとセカンダリFMCを追加してください。セカンダリFMCのジャンプサーバのようにリモートサーバからこのコマンドを実行する場合は、セカンダリFMCの詳細を、最初のエントリとして追加し、その後にすべての管理対象FTDを追加してください。
   
   i. vi devices.csvを使用してファイルを作成します。viデバイス.csv
   
   ii.これにより、空のファイル（図には表示されていません）が開き、キーボードでi文字を使用してインタラクティブモード（画面の下部に表示されます）に入った後、図に示すように詳細を入力します。
   devices.csvの例
   
   iii.完了したら、Escキーを押した後に:wqを押してファイルを閉じ、Enterキーを押します。
   devices.csvを保存します。
   
   B. copy_sftunnel_certs.py devices.csvを使用して(sudoを使用してrootから)スクリプトを実行すると、結果が表示されます。ここでは、FTDvへの証明書が正しくプッシュされたこと、およびBSNS-1120-1でデバイスへのSSH接続を確立できなかったことを示しています。
   
   copy_sftunnel_certs.pyデバイス.csv
   
   ===手動によるアプローチ===
   
   
   1. 前の出力（FAILED_PUSHファイル）からファイルの場所をコピーして、FMC CLIに影響を受ける各FTDの各ファイル(cacert.pem / sftunnel-key.pem（セキュリティ目的で完全には表示されていません） / sftunnel-cert.pem)を出力(cat)します。
      
      cacert.pem（推奨）
      sftunnel-key.pem（トンネルキー.pem）
      sftunnel-cert.pem（推奨）
   2. sudo suでルート権限を使用して、expertモードで各FTDのFTD CLIを開き、次の手順で証明書を書き換えます。
      1. FAILED_PUSHの出力の水色の強調表示で示されている場所を参照します(たとえば、cd /var/sf/peers/cdb123c8-4347-11ef-aca1-f3aa241412a1。ただし、これはFTDごとに異なります)。
      2. 既存のファイルのバックアップを作成します。
         

         cp cacert.pem cacert.pem.backup
         cp sftunnel-cert.pem sftunnel-cert.pem.backup
         cp sftunnel-key.pem sftunnel-key.pem.backup​

         
         現在の証明書のバックアップを作成する
      3. ファイルを空にして、新しいコンテンツを書き込めるようにします。
         

         > cacert.pem
         > sftunnel-cert.pem
         > sftunnel-key.pem​

         
         既存の証明書ファイルの内容が空です
      4. vi cacert.pem / vi sftunnel-cert.pem / vi sftunnel-key.pem（ファイルごとに個別のコマンド：スクリーンショットではcacert.pemについてのみこれが表示されますが、sftunnel-cert.pemとsftunnel-key.pemについては繰り返す必要があります）を使用して、新しいコンテンツ（FMCの出力から）を各ファイルに個別に書き込みます。vi cacert.pem
         1. iを押して、インタラクティブモードに入ります（viコマンドを入力すると、空のファイルが表示されます）。
         2. コピーして、ファイルの内容全体(-----BEGIN CERTIFICATE-----と-----END CERTIFICATE-----を含む)を貼り付けます。
            vi （挿入モード）でコンテンツをコピー
         3. Escキーを押した後に:wqを押してファイルを閉じ、ファイルに書き込んでから、を入力します。
            ESCの後に：wqを入力してファイルに書き込む
      5. ls -halを使用して、各ファイルに正しいアクセス許可(chmod 644)と所有者(chown root:root)が設定されていることを検証します。これは、既存のファイルを更新するときに正しく設定されます。
         権利の所有者とアクセス許可で更新されたすべての証明書ファイル
         
         
   3. sftunnelが動作していなかった各FTDでsftunnelを再起動し、証明書の変更をコマンドを使用して有効にします pmtool restartbyid sftunnel
      
      pmtool restartbyid sftunnel
      
      
3. sftunnel_status.plの出力を使用して、すべてのFTDが正しく接続されていることを確認します

解決策2 – 証明書はすでに期限切れです

この状況では、2つの異なるシナリオがあります。sftunnel接続のすべてが引き続き動作しているか、または部分的に動作していません。

FTDはsftunnel経由で接続されたままです。

「証明書はまだ期限切れになっていない（理想的なシナリオ） – 推奨されるアプローチ」セクションで示したのと同じ手順を適用できます。

ただし、この状況ではFMC（または任意のFTD）のアップグレードやリブートは行わないでください。すべてのsftunnel接続が切断されるため、各FTDですべての証明書の更新を手動で実行する必要があります。唯一の例外は、リストされているホットフィックスリリースです。これは、FMCをリブートする必要がないためです。

トンネルは接続されたままになり、証明書は各FTDで置き換えられます。一部の証明書の入力に失敗した場合は、失敗した証明書を使用するように求められます。そのため、前のセクションで前述したように、手動によるアプローチを使用する必要があります。

FTDがsftunnel経由で接続されなくなりました。

推奨されるアプローチ

「証明書はまだ期限切れになっていない（理想的なシナリオ） – 推奨されるアプローチ」セクションで示したのと同じ手順を適用できます。このシナリオでは、新しい証明書がFMCで生成されますが、トンネルがすでにダウンしているため、デバイスにコピーできません。このプロセスは、copy_sftunnel_certs.py / copy_sftunnel_certs_jumpserver.pyスクリプトで自動化できます

すべてのFTDデバイスがFMCから切断されている場合は、sftunnel接続に影響しないため、この状況でFMCをアップグレードできます。sftunnelを介して接続されているデバイスがまだある場合は、FMCのアップグレードによってsftunnel接続がすべて閉じられ、証明書の期限切れが原因で接続が再開されないことに注意してください。ここでのアップグレードの利点は、各FTDに転送する必要がある証明書ファイルに関する優れたガイダンスを提供することです。

手動アプローチ

この場合、新しい証明書を生成するFMCからgenerate_certs.pl スクリプトを実行できますが、これらの証明書をそれぞれのFTDデバイス(手動)にプッシュする必要があります。デバイスの量によっては、これは可能であるか、面倒な作業になる可能性があります。ただし、copy_sftunnel_certs.py / copy_sftunnel_certs_jumpserver.pyスクリプトを使用すると、高度に自動化されます。