为FTD连接续订FMC Sftunnel CA证书

简介

本文档介绍与Firepower威胁防御(FTD)连接相关的Firepower管理中心(FMC)sftunnel Certificate Authority(CA)证书的续订。

先决条件

要求

Cisco 建议您了解以下主题：

• Firepower威胁防御
• Firepower 管理中心
• 公用密钥基础结构 (PKI)

使用的组件

本文档不限于特定的软件和硬件版本。

本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始（默认）配置。如果您的网络处于活动状态，请确保您了解所有命令的潜在影响。

背景信息

FMC和FTD通过sftunnel（Sourcefire隧道）相互通信。 此通信使用证书来确保TLS会话中的会话安全。有关sftunnel及其如何建立的详细信息，可在此链接上找到。

通过数据包捕获，您可以看到FMC（本例中为10.48.79.232）和FTD(10.48.79.23)正在相互交换证书。他们这样做是为了验证他们是否与正确的设备通信，以及不存在窃听或中间人(MITM)攻击。使用那些证书对通信进行加密，只有拥有该证书的关联私钥的一方才能再次解密该证书。

Certificate_exchange_server_cert

Certificate_exchange_client_cert

您可以看到证书由FMC系统上设置的相同InternalCA(Issuer)证书颁发机构(CA)签名。在/etc/sf/sftunnel.conf文件上的FMC上定义配置，该文件包含以下内容：

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 one）的所有证书的CA，以及FMC用于发送到所有FTD的证书。此证书由InternalCA签名。

当FTD注册到FMC时，FMC还会创建证书以推送到FTD设备，用于在sftunnel上进行进一步通信。此证书也由同一内部CA证书签名。在FMC上，可以在/var/sf/peers/<UUID-FTD-device>下和可能在certs_pushed文件夹下找到证书（和私钥），该文件夹名为sftunnel-cert.pem(对于私钥，sftunnel-key.pem)。 在FTD上，您可以找到那些在/var/sf/peers/<UUID-FMC-device>下使用相同命名约定的FTD。

但是，出于安全考虑，每个证书也有一个有效期。在检查InternalCA证书时，我们还可以看到数据包捕获所显示的FMC InternalCA的有效期（10年）。

FMC-InternalCA_validity

问题

FMC InternalCA证书有效期仅为10年。到期后，远程系统不再信任此证书（以及由其签名的证书），这将导致FTD和FMC设备之间的sftunnel通信问题。这也意味着连接事件、恶意软件查找、基于身份的规则、策略部署等多项关键功能无法正常工作。

当sftunnel未连接时，设备在FMC UI的Devices > Device Management选项卡下显示为禁用。思科漏洞ID CSCwd08098会跟踪与此到期相关的问题。请注意，即使您运行了缺陷的固定版本，所有系统都会受到影响。有关此修补程序的更多信息，请参阅解决方案部分。

已禁用设备

FMC不会自动刷新CA并将证书重新发布到FTD设备。此外，也没有指示证书到期的FMC运行状况警报。在此方面跟踪思科漏洞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日。

NotAfter

如果您希望运行一个命令，立即向您提供证书仍然有效的天数，则可以使用此命令：

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_expire_validation_command

以后如何获得有关即将到期的证书的通知？

使用最近的VDB更新（399或更高），证书在90天内到期时会自动向您发出警报。因此，您自己无需手动跟踪，因为当您接近到期时间时会收到警报。然后，FMC网页上会显示两种表格。这两种方式均请参阅现场通知页面。

第一种方法是通过Task选项卡。此消息为粘滞消息，除非明确关闭，否则用户可以使用它。通知弹出窗口也会显示，在用户明确关闭之前一直可用。它始终显示为错误。

“任务”选项卡上的到期通知

第二种方法是通过Health Alert。这在Health选项卡中显示，但这不是粘滞的，并在运行运行状况监控器时替换或删除，默认情况下，运行状况监控器每5分钟运行一次。它还显示一个通知弹出窗口，用户需要明确关闭该窗口。这可以同时显示为错误（过期时）和警告（即将过期时）。

“运行状况”(Health)选项卡上的到期通知

弹出运行状况警报时的警告通知

出现运行状况警报弹出时的错误通知

解决方案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. 重新生成InternalCA
2. 重新创建由此新的InternalCA签名的sftunnel证书
3. 将新的sftunnel证书和私钥推送到各自的FTD设备（当sftunnel运行时）

因此，建议（如果可能）：

1. 为您的版本系列安装适用的修补程序
2. 在FMC上进行备份
3. 在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上的到期时间并指示其上的任何故障。例如，它未能将证书推送到设备BSNS-1120-1和EMEA-FPR3110-08设备，这是预期结果，因为这些设备的sftunnel已关闭。

要更正失败连接的sftunnel，请运行以下步骤：

1. 在FMC CLI上，使用cat /var/tmp/certs/1728303362/FAILED_PUSH（number值表示unix时间，因此请检查系统中上一个命令的输出）打开FAILED_PUSH文件，此文件采用以下格式： FTD_UUID FTD_NAME FTD_IP SOURCE_PATH_ON_FMC DESTINATION_PATH_ON_FTD
   
   FAILED_PUSH
   
   
2. 通过这些新证书(cacert.pem / sftunnel-key.pem / sftunnel-cert.pem)从FMC传输到FTD设备
   ===自动方法===
   
   修补程序安装还提供了copy_sftunnel_certs.py和copy_sftunnel_certs_jumpserver.py脚本，这些脚本可自动将各种证书传输到证书重新生成时未启动sftunnel的系统。这也可用于由于证书已过期而导致sftunnel连接中断的系统。
   
   当FMC本身拥有对各种FTD系统的SSH访问权时，可以使用copy_sftunnel_certs.py脚本。如果情况并非如此，您可以将脚本(/usr/local/sf/bin/copy_sftunnel_certs_jumpserver.py)从FMC下载到具有SSH访问FMC和FTD设备的跳转服务器，并从那里运行Python脚本。如果也不可能这样做，则建议运行下面所示的手动方法。下面的示例显示正在使用的copy_sftunnel_certs.py脚本，但对于copy_sftunnel_certs_jumpserver.py脚本的步骤是相同的。
   
   A.在FMC（或跳转服务器）上创建包含用于建立SSH连接的设备信息（device_name、IP地址、admin_username、admin_password）的CSV文件。
   
   当您从远程服务器（如主FMC的跳转服务器）运行此时，请确保在主FMC详细信息中添加作为第一个条目，后跟所有托管FTD和辅助FMC。当您从远程服务器（如辅助FMC的跳转服务器）运行此时，请确保在辅助FMC详细信息中添加作为第一个条目，后跟所有托管FTD。
   
   i.使用vi devices.csv创建文件。vi devices.csv
   
   二、这将打开空文件（未显示），当您使用键盘上的i letter进入INTERACTIVE模式（在屏幕底部看到）后，您可以填写详细信息，如下所示。
   devices.csv示例
   
   三。完全完成后，使用ESC并按:wq然后按Enter键关闭并保存文件。
   保存设备.csv
   
   B.使用copy_sftunnel_certs.py devices.csv运行脚本(使用sudo从根运行)，并显示结果。此处显示已正确推送到FTDv的证书，并且对于BSNS-1120-1，无法建立到设备的SSH连接。
   
   copy_sftunnel_certs.py devices.csv
   
   ===手动方法===
   
   
   1. 通过复制之前输出（FAILED_PUSH文件）中的文件位置，在FMC CLI上为每个受影响的FTD(cacert.pem / sftunnel-key.pem（出于安全目的未完全显示）/ sftunnel-cert.pem)打印输出(cat)。
      
      cacert.pem
      sftunnel-key.pem
      sftunnel-cert.pem
   2. 通过sudo su在expert模式下打开各个FTD的FTD CLI，并使用root权限更新证书，执行下一个过程。
      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中复制内容（INSERT模式）
         3. 关闭并使用ESC后跟：wq写入文件，然后输入。
            ESC后跟：wq以写入文件
      5. 使用ls -hal验证是否为每个文件设置了正确的权限(chmod 644)和所有者(chown root:root)。这实际上是在更新现有文件时设置的。
         使用正确的所有者和权限更新所有证书文件
         
         
   3. 在每个FTD上（其中sftunnel未运行）重新启动sftunnel，使证书中的更改通过命令生效 pmtool restartbyid sftunnel
      
      pmtool restartbyid sftunnel
      
      
3. 使用sftunnel_status.pl输出验证所有FTD现在是否已正确连接

解决方案2 — 证书已过期

在这种情况下，我们有两种不同的场景。所有sftunnel连接仍可运行，或者不再运行（或部分运行）。

FTD仍通过sftunnel连接

我们可以应用“证书尚未过期(理想情景) — 推荐方法”部分中所示的相同步骤。

但是，在这种情况下，请勿升级或重新启动FMC（或任何FTD），因为它会断开所有sftunnel连接，并且我们需要手动运行每个FTD上的所有证书更新。唯一例外是列出的修补程序版本，因为它们不需要重新启动FMC。

隧道保持连接，证书在每个FTD上被替换。如果某些证书无法填充，则会提示您填写失败的证书，您需要采取上节前面所提到的手动方法。

FTD不再通过sftunnel连接

推荐的方法

我们可以应用“证书尚未过期(理想情景) — 推荐方法”部分中所示的相同步骤。在此场景中，新证书将在FMC上生成，但无法复制到设备，因为隧道已关闭。可以使用copy_sftunnel_certs.py / copy_sftunnel_certs_jumpserver.py脚本自动执行此过程

如果所有FTD设备都与FMC断开连接，我们可以在此情况下升级FMC，因为它对sftunnel连接没有影响。如果仍有一些设备通过sftunnel连接，则请注意FMC的升级会关闭所有sftunnel连接，并且由于证书过期，它们不会再次出现。此处的升级的好处是，它确实可以针对需要传输到每个FTD的证书文件提供良好的指导。

手动方法

在这种情况下，您可以从FMC运行generate_certs.pl脚本，该脚本会生成新证书，但您仍需要手动将其推送到每个FTD设备。根据设备数量，这是可行或繁琐的任务。但是，使用copy_sftunnel_certs.py / copy_sftunnel_certs_jumpserver.py脚本时，此过程高度自动化。