对CSCwc69661 / CSCwa25108引入的MRA服务的Expressway流量服务器证书验证进行故障排除

简介

本文档介绍与Cisco Bug ID CSCwc6961或Cisco Bug ID CSCwa25108关联的Expressway版本X14.2.0及更高版本上的行为更改。

先决条件

要求

Cisco 建议您了解以下主题：

• Expressway基本配置
• MRA基本配置

使用的组件

本文档中的信息基于X14.2及更高版本上的Cisco Expressway。

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

背景信息

此行为更改由Cisco Bug ID CSCwc标记69661 或Cisco Bug ID CSCwa25108 ,Expressway平台上的流量服务器对用于移动和远程访问(MRA)服务的Cisco Unified Communication Manager(CUCM)、Cisco Unified Instant Messaging & Presence(IM&P)和Unity服务器节点执行证书验证。在Expressway平台上升级后，此更改可能会导致MRA登录失败。  

安全超文本传输协议(HTTPS)是一种使用传输层安全(TLS)加密通信的安全通信协议。它通过使用在TLS握手过程中交换的TLS证书来创建此安全通道。通过这种方式，它实现了两个目的：身份验证（了解您连接的远程方）和隐私（加密）。身份验证可防止中间人攻击，并且隐私可防止攻击者窃听和篡改通信。

TLS（证书）验证在看到身份验证时执行，并允许您确保已连接到正确的远程方。验证包括两个单独的项目：

1.受信任证书颁发机构(CA)链

2.主题备用名称(SAN)或公用名称(CN)

可信CA链

为了使Expressway-C信任CUCM/IM&P/Unity发送的证书，它需要能够建立从该证书到其信任的顶级（根）证书颁发机构(CA)的链接。此类链接是将实体证书链接到根CA证书的证书层次结构，称为信任链。为了能够验证此类信任链，每个证书包含两个字段：Issuer（或“Issued by”）和Subject（或“Issued To”）。

服务器证书（例如CUCM发送到Expressway-C的那个）在“Subject”字段中通常在CN中具有其完全限定域名(FQDN):

        Issuer: DC=lab, DC=vngtp, CN=vngtp-ACTIVE-DIR-CA
        Subject: C=BE, ST=Flamish-Brabant, L=Diegem, O=Cisco, OU=TAC, CN=cucm.vngtp.lab

CUCM cucm.vngtp.lab的服务器证书示例。它在“主题”(Subject)字段的CN属性中具有FQDN，同时还具有其他属性，例如国家(C)、州(ST)、位置(L)。.我们还可以看到，服务器证书由名为vngtp-ACTIVE-DIR-CA的CA分发（颁发）。

顶级CA（根CA）也可以颁发证书来标识自己。在这样的根CA证书中，我们看到颁发者和使用者具有相同的值：

        Issuer:  DC=lab, DC=vngtp, CN=vngtp-ACTIVE-DIR-CA
        Subject: DC=lab, DC=vngtp, CN=vngtp-ACTIVE-DIR-CA

它是根CA分发的证书，用于标识自身。

在典型情况下，根CA不会直接颁发服务器证书。相反，它们会为其他CA颁发证书。这些其它CA然后称为中间CA。反过来，中间CA可以直接为其他中间CA颁发服务器证书或证书。我们可能会遇到中间的CA 1颁发服务器证书，而中间的CA 1又从中间的CA 2获得证书，以此类推。直到最终中间CA直接从根CA获取其证书：

Server certificate :
        Issuer:  DC=lab, DC=vngtp, CN=vngtp-intermediate-CA-1
        Subject: C=BE, ST=Flamish-Brabant, L=Diegem, O=Cisco, OU=TAC, CN=cucm.vngtp.lab
Intermediate CA 1 certificate :
        Issuer:  DC=lab, DC=vngtp, CN=vngtp-intermediate-CA-2 
        Subject: DC=lab, DC=vngtp, CN=vngtp-intermediate-CA-1 
Intermediate CA 2 certificate :
        Issuer:  DC=lab, DC=vngtp, CN=vngtp-intermediate-CA-3 
        Subject: DC=lab, DC=vngtp, CN=vngtp-intermediate-CA-2 
...
Intermediate CA n certificate :
        Issuer:  DC=lab, DC=vngtp, CN=vngtp-ACTIVE-DIR-CA
        Subject: DC=lab, DC=vngtp, CN=vngtp-intermediate-CA-n 
Root CA certificate :
        Issuer:  DC=lab, DC=vngtp, CN=vngtp-ACTIVE-DIR-CA
        Subject: DC=lab, DC=vngtp, CN=vngtp-ACTIVE-DIR-C

现在，为了让Expressway-C信任CUCM发送的服务器证书，它需要能够从该服务器证书构建信任链，直到创建根CA证书。为此，我们需要在Expressway-C的信任存储中上传根CA证书和所有中间CA证书（如果有，如果根CA直接颁发CUCM的服务器证书则不会出现这种情况）。

注意： 虽然Issuer和Subject字段易于以易于阅读的方式构建信任链，但CUCM在证书中不使用这些字段。相反，它使用“X509v3 Authority Key Identifier”和“X509v3 Subject Key Identifier”字段构建信任链。这些密钥包含更准确的证书标识符，然后使用Subject/Issuer字段：可以有2个证书具有相同的Subject/Issuer字段，但其中一个证书已过期，而另一个证书仍然有效。它们都有不同的X509v3主题密钥标识符，因此CUCM仍可确定正确的信任链。

但根据Cisco Bug ID CSCwa12905,Expressway无法这样做，并且无法将两个不同的（例如自签名）证书上传到具有相同公用名(CN)的Expressway信任存储中。对此进行更正的方法是CA签名证书，或者为其使用不同的通用名称，或者查看它始终使用相同的证书（可能通过CUCM 14中的重复使用证书功能）。

SAN或CN检查

第1步检查信任库，但拥有信任库中的CA签名的证书的任何人在此时都是有效的。这显然是不够的。因此，另外会进行检查，以验证您专门连接的服务器是否正确。它根据发出请求的地址执行此操作。

在浏览器中也会发生同样的操作，因此让我们通过一个示例来了解这一点。如果浏览到https://www.cisco.com，您会在输入的URL旁边看到一个锁图标，这意味着该连接是受信任连接。这既基于CA信任链（来自第一部分），也基于SAN或CN检查。如果我们打开证书（通过浏览器单击锁定图标），您会看到“公用名”（在“Issued to：”字段中看到）设置为www.cisco.com，并且与要连接的地址完全一致。这样可以确保我们连接到正确的服务器（因为我们信任签署证书并在分发证书之前执行验证的CA）。

当我们查看证书的详细信息（尤其是SAN条目）时，我们会看到该详细信息与某些其他FQDN一样：

这意味着，例如，当我们请求连接到https://www1.cisco.com时，它也会显示为安全连接，因为它包含在SAN条目中。

但是，如果我们不浏览https://www.cisco.com，而是直接浏览到IP地址(https://72.163.4.161)，则不会显示安全连接，因为它确实信任签名它的CA，但是提供给我们的证书不包含我们用于连接到服务器的地址(72.163.4.161)。

在浏览器中，您可以绕过此设置，但它是可以在TLS连接上启用的设置，不允许绕行。因此，您的证书必须包含远程方计划用于连接它的正确CN或SAN名称。

行为更改

MRA服务严重依赖通过到CUCM/IM&P/Unity服务器的Expressway上的几个HTTPS连接，以便正确进行身份验证并收集特定于登录客户端的正确信息。此通信通常发生在端口8443和6972上。

低于X14.2.0的版本

在低于X14.2.0的版本中，Expressway-C上处理这些安全HTTPS连接的流量服务器不会验证远程端提供的证书。这可能导致中间人攻击。在MRA配置上，当您将任一CUCM / IM&P / Unity服务器添加到Configuration > Unified Communications > Unified CM servers / IM and Presence Service nodes / Unity Connection servers下时，可以通过将“TLS Verify Mode”配置为“On”来进行TLS证书验证。配置选项和相关信息框以示例形式显示，表示它确实验证了SAN中的FQDN或IP，以及证书的有效性以及证书是否由受信任CA签名。

此TLS证书验证检查仅在发现CUCM/IM&P/Unity服务器时完成，而不是在MRA登录期间查询各种服务器时完成。此配置的第一个缺点是，它仅验证您添加的发布者地址。它不会验证订用服务器节点上的证书是否设置正确，因为它从发布服务器节点的数据库中检索订用服务器节点信息（FQDN或IP）。此配置的第二个缺点是，由于连接信息可能不同于Expressway-C配置中的发布方地址，因此通告给MRA客户端的内容可能不同。例如，在CUCM上，在System > Server下，可以使用IP地址（例如10.48.36.215）向外通告服务器，然后由MRA客户端使用（通过代理的Expressway连接），但您可以在Expressway-C上使用FQDN cucm.steven.lab添加CUCM。因此，假设CUCM的tomcat证书包含cucm.steven.lab作为SAN条目而不是IP地址，则将“TLS验证模式”设置为“打开”的发现成功，但来自MRA客户端的实际通信可以针对不同的FQDN或IP，从而无法通过TLS验证。

X14.2.0及更高版本

从X14.2.0版本开始，Expressway服务器会对通过流量服务器发出的每个单个HTTPS请求执行TLS证书验证。这意味着，在发现CUCM/IM&P/Unity节点期间，当“TLS验证模式”设置为“关闭”时，它也会执行此操作。如果验证失败，则TLS握手不会完成，并且请求失败，这可能导致功能丢失（例如冗余或故障切换问题）或完全登录失败。此外，如果将“TLS验证模式”设置为“开”，则不能保证所有连接都能正常运行（如后面的示例所述）。

Expressway向CUCM/IM&P/Unity节点检查的确切证书如MRA指南部分所示。

除了TLS验证的默认值以外，X14.2中还引入了一个更改，它可能通告密码列表的不同首选项顺序，这取决于您的升级路径。这可能会导致软件升级后出现意外的TLS连接，因为在升级之前，它可能会请求从CUCM（或任何具有用于ECDSA算法的单独证书的其他产品）获得Cisco Tomcat或Cisco CallManager证书，但在升级之后，它请求ECDSA变体（实际上比RSA更安全的密码变体）。Cisco Tomcat-ECDSA或Cisco CallManager-ECDSA证书可以由其他CA签名，也可以仅由自签名证书签名（默认）。

此密码首选项顺序更改并非始终与您相关，因为它取决于Expressway X14.2.1版本说明中所示的升级路径。简而言之，您可以从Maintenance > Security > Ciphers中查看每个密码列表是否预置了“ECDHE-RSA-AES256-GCM-SHA384：”。如果没有，则它首选更新的ECDSA密码而不是RSA密码。如果是，则您有与前面一样的行为，其中RSA具有更高的优先级。

在此场景中，TLS验证有两种可能失败，稍后将详细介绍：

1.签署远程证书的CA不受信任

a.自签证书

b.由未知CA签名的证书

2.证书中不包含连接地址（FQDN或IP）

故障排除场景

接下来的场景显示实验室环境中类似场景，其中Expressway从X14.0.7升级到X14.2后，MRA登录失败。它们在日志中有相似之处，但分辨率不同。日志仅通过MRA登录之前开始并在MRA登录失败之后停止的诊断日志记录(从Maintenance > Diagnostics > Diagnostic logging)收集。未为其启用其他调试日志记录。

1.签署远程证书的CA不受信任

远程证书可以由未包含在Expressway-C的信任存储中的CA进行签名，也可以是未添加到Expressway-C服务器的信任存储中的自签名证书（本质上也是CA）。

在本例中，您会发现，发往CUCM(10.48.36.215 - cucm.steven.lab)的请求在端口8443（200 OK响应）上得到正确处理，但是在TFTP连接的端口6972上引发错误（502响应）。

===Success connection on 8443===

2022-07-11T18:55:25.910+02:00 vcsc traffic_server[18242]: UTCTime="2022-07-11 16:55:25,910" Module="network.http.trafficserver" Level="INFO": Detail="Receive Request" Txn-id="189" TrackingID="6af9a674-9ebc-41ea-868e-90e7309a758c" Src-ip="127.0.0.1" Src-port="35764" Last-via-addr="" Msg="GET http://vcs_control.steven.lab:8443/c3RldmVuLmxhYi9odHRwcy9jdWNtLnN0ZXZlbi5sYWIvODQ0Mw/cucm-uds/user/emusk/devices HTTP/1.1"

2022-07-11T18:55:25.917+02:00 vcsc traffic_server[18242]:  Event="Request Allowed" Detail="Access allowed" Reason="In allow list" Username="emusk" Deployment="1" Method="GET" Request="https://cucm.steven.lab:8443/cucm-uds/user/emusk/devices" Rule="https://cucm.steven.lab:8443/cucm-uds/user/" Match="prefix" Type="Automatically generated rule for CUCM server" UTCTime="2022-07-11 16:55:25,916"
2022-07-11T18:55:25.917+02:00 vcsc traffic_server[18242]: UTCTime="2022-07-11 16:55:25,916" Module="network.http.trafficserver" Level="INFO": Detail="Sending Request" Txn-id="189" TrackingID="6af9a674-9ebc-41ea-868e-90e7309a758c" Dst-ip="10.48.36.215" Dst-port="8443" Msg="GET /cucm-uds/user/emusk/devices HTTP/1.1"
2022-07-11T18:55:25.955+02:00 vcsc traffic_server[18242]: UTCTime="2022-07-11 16:55:25,955" Module="network.http.trafficserver" Level="INFO": Detail="Receive Response" Txn-id="189" TrackingID="" Src-ip="10.48.36.215" Src-port="8443" Msg="HTTP/1.1 200 "
2022-07-11T18:55:25.956+02:00 vcsc traffic_server[18242]: UTCTime="2022-07-11 16:55:25,955" Module="network.http.trafficserver" Level="INFO": Detail="Sending Response" Txn-id="189" TrackingID="" Dst-ip="127.0.0.1" Dst-port="35764" Msg="HTTP/1.1 200 "

===Failed connection on 6972===

2022-07-11T18:55:26.000+02:00 vcsc traffic_server[18242]: UTCTime="2022-07-11 16:55:26,000" Module="network.http.trafficserver" Level="INFO": Detail="Receive Request" Txn-id="191" TrackingID="bb0c8492-8c15-4537-a7d1-082dde781dbd" Src-ip="127.0.0.1" Src-port="35766" Last-via-addr="" Msg="GET http://vcs_control.steven.lab:8443/c3RldmVuLmxhYi9odHRwcy9jdWNtLnN0ZXZlbi5sYWIvNjk3Mg/CSFemusk.cnf.xml HTTP/1.1"

2022-07-11T18:55:26.006+02:00 vcsc traffic_server[18242]: UTCTime="2022-07-11 16:55:26,006" Module="network.http.trafficserver" Level="INFO": Detail="Sending Request" Txn-id="191" TrackingID="bb0c8492-8c15-4537-a7d1-082dde781dbd" Dst-ip="10.48.36.215" Dst-port="6972" Msg="GET /CSFemusk.cnf.xml HTTP/1.1"
2022-07-11T18:55:26.016+02:00 vcsc traffic_server[18242]: UTCTime="2022-07-11 16:55:26,016" Module="network.http.trafficserver" Level="INFO": Detail="Sending Request" Txn-id="191" TrackingID="bb0c8492-8c15-4537-a7d1-082dde781dbd" Dst-ip="10.48.36.215" Dst-port="6972" Msg="GET /CSFemusk.cnf.xml HTTP/1.1"
2022-07-11T18:55:26.016+02:00 vcsc traffic_server[18242]: [ET_NET 0] WARNING: Core server certificate verification failed for (cucm.steven.lab). Action=Terminate Error=self signed certificate server=cucm.steven.lab(10.48.36.215) depth=0
2022-07-11T18:55:26.016+02:00 vcsc traffic_server[18242]: [ET_NET 0] ERROR: SSL connection failed for 'cucm.steven.lab': error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
2022-07-11T18:55:26.024+02:00 vcsc traffic_server[18242]: UTCTime="2022-07-11 16:55:26,024" Module="network.http.trafficserver" Level="INFO": Detail="Sending Response" Txn-id="191" TrackingID="" Dst-ip="127.0.0.1" Dst-port="35766" Msg="HTTP/1.1 502 connect failed"

“certificate verify failed”错误表示Expressway-C无法验证TLS握手的事实。原因显示在警告行上，因为它表示自签名证书。如果深度显示为0，则为自签名证书。当深度大于0时，这意味着它有一个证书链，因此由未知CA签名（从Expressway-C的角度而言）。

当我们查看在文本日志中提及的时间戳处收集的pcap文件时，您可以看到CUCM将带有CN的证书显示为cucm-ms.steven.lab（和cucm.steven.lab作为SAN），由steven-DC-CA签署，并发送到端口8443上的Expressway-C。

但是，当我们检查端口6972上提供的证书时，您可以看到它是自签证书（颁发者自身），其CN设置为cucm-EC.steven.lab。-EC扩展指明这是CUCM上设置的ECDSA证书。

在Cisco Unified OS Administration下的CUCM上，您可以查看Security > Certificate Management下的现有证书，如下例所示。它显示不同的tomcat和tomcat-ECDSA证书，其中tomcat是CA签名的（并受Expressway-C信任），而tomcat-ECDSA证书是自签名的，不受Expressway-C信任。

2.证书中不包含连接地址（FQDN或IP）

除了信任存储之外，流量服务器还验证MRA客户端向哪个连接地址发出请求。例如，当您在CUCM上的System > Server下设置CUCM时，您的CUCM的IP地址(10.48.36.215)，则Expressway-C会将此情况通告给客户端，并且来自客户端（通过Expressway-C代理）的后续请求会指向此地址。

当该特定连接地址未包含在服务器证书中时，TLS验证也会失败，并引发502错误，从而导致MRA登录失败。

2022-07-11T19:49:01.472+02:00 vcsc traffic_server[3916]: UTCTime="2022-07-11 17:49:01,472" Module="network.http.trafficserver" Level="DEBUG": Detail="Receive Request" Txn-id="144" TrackingID="0a334fa8-41e9-4b97-adf4-e165372c38cb" Src-ip="127.0.0.1" Src-port="30044" Last-via-addr=""
HTTPMSG:
|GET http://vcs_control.steven.lab:8443/c3RldmVuLmxhYi9odHRwcy8xMC40OC4zNi4yMTUvODQ0Mw/cucm-uds/user/emusk/devices?max=100 HTTP/1.1
...

2022-07-11T19:49:01.478+02:00 vcsc traffic_server[3916]: UTCTime="2022-07-11 17:49:01,478" Module="network.http.trafficserver" Level="INFO": Detail="Sending Request" Txn-id="144" TrackingID="0a334fa8-41e9-4b97-adf4-e165372c38cb" Dst-ip="10.48.36.215" Dst-port="8443" Msg="GET /cucm-uds/user/emusk/devices?max=100 HTTP/1.1"
2022-07-11T19:49:01.478+02:00 vcsc traffic_server[3916]: UTCTime="2022-07-11 17:49:01,478" Module="network.http.trafficserver" Level="DEBUG": Detail="Sending Request" Txn-id="144" TrackingID="0a334fa8-41e9-4b97-adf4-e165372c38cb" Dst-ip="10.48.36.215" Dst-port="8443"
HTTPMSG:
|GET /cucm-uds/user/emusk/devices?max=100 HTTP/1.1
...

2022-07-11T19:49:01.491+02:00 vcsc traffic_server[3916]: [ET_NET 2] WARNING: SNI (10.48.36.215) not in certificate. Action=Terminate server=10.48.36.215(10.48.36.215)
2022-07-11T19:49:01.491+02:00 vcsc traffic_server[3916]: [ET_NET 2] ERROR: SSL connection failed for '10.48.36.215': error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed

其中c3RldmVuLmxhYi9odHRwcy8xMC40OC4zNi4yMTUvODQ0Mw translate(base64 - https://www.base64decode.org/)到steven.lab/https/10.48.36.215/8443，表明它必须建立到10.48.36.215的连接作为连接地址，而不是到cucm.steven.lab。如数据包捕获所示，CUCM tomcat证书不包含SAN中的IP地址，因此引发错误。

如何轻松验证

您可以通过以下步骤验证您是否容易遇到此行为更改：

1.在Expressway-E和C服务器上启动诊断日志记录（最好启用TCPDumps），从Maintenance > Diagnostics > Diagnostic Logging（如果是集群，从主节点启动就足够了）

2.尝试MRA登录或在升级后测试中断的功能

3.等待失败，然后停止Expressway-E和C服务器上的诊断日志记录（如果是集群，请确保分别从集群的每个节点收集日志）

4.上传并分析协作解决方案分析器工具上的日志

5.如果遇到问题，它会为每个受影响的服务器选取与此更改相关的最新警告和错误行

CA诊断签名

SNI诊断签名

解决方案

长期的解决方案是确保TLS验证正常工作。要执行的操作取决于显示的警告消息。

当您看到WARNING: Core server certificate verification failed for(<server-FQDN-or-IP>)时。Action=Terminate Error=self signed certificate server=cucm.steven.lab(10.48.36.215)depth=x message，然后您需要相应地更新Expressway-C服务器上的信任存储。使用签署此证书的CA链（深度> 0）或使用Maintenance > Security > Trusted CA Certificate中的自签名证书（深度= 0）。确保在群集中的每台服务器上执行此操作。另一种方法是，通过Expressway-C信任存储上的已知CA对远程证书进行签名。

注意： Expressway不允许根据Cisco Bug ID CSCwa12905将两个不同（例如自签名）证书上传到Expressway的信任存储区，这些证书的公用名(CN)相同。要更正此问题，请转到CA签名的证书，或者将CUCM升级到版本14，在该版本中，您可以对Tomcat和CallManager重复使用相同的（自签名）证书。

当您看到WARNING: SNI(<server-FQDN-or-IP>)not in certificate消息时，表明此服务器FQDN或IP未包含在提供的证书中。您可以调整证书以包含此信息，或者可以修改配置（例如在System > Server上的CUCM上，修改为服务器证书中包含的内容），然后刷新Expressway-C服务器上的配置以将其考虑在内。

短期解决方案是应用所记录的解决方法，以回退到X14.2.0之前的先前行为。您可以使用新引入的命令，通过Expressway-C服务器节点上的CLI对此执行：

xConfiguration EdgeConfigServer VerifyOriginServer: Off