排除MRA服務的Expressway流量伺服器證書驗證故障

簡介

本文檔介紹與思科漏洞ID CSCwc69661或思科漏洞ID CSCwa25108連結的Expressway版本X14.2.0及更高版本的行為更改。

必要條件

需求

思科建議您瞭解以下主題：

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

採用元件

本文檔中的資訊基於X14.2及更高版本上的Cisco Expressway。

本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路運作中，請確保您瞭解任何指令可能造成的影響。

背景資訊

透過思科漏洞ID CSCwc69661 或思科漏洞ID CSCwa25108 標籤的行為更改，Expressway平台上的流量伺服器可執行對思科統一通訊管理器(CUCM)、思科統一即時消息和線上狀態(IM&P)以及移動和遠端訪問(MRA)服務的Unity伺服器節點的證書驗證。此更改可能會導致Expressway平台升級後的MRA登入失敗。  

超文本傳輸協定安全(HTTPS)是一種使用傳輸層安全(TLS)加密通訊的安全通訊協定。它透過使用TLS握手過程中交換的TLS證書來建立此安全通道。此伺服器有兩個用途：身份驗證（瞭解您連線到的遠端方）和隱私（加密）。身份驗證可防止中間人攻擊，隱私可防止攻擊者竊聽和篡改通訊。

TLS（證書）驗證在看到身份驗證的情況下執行，並且允許您確保您已連線到正確的遠端方。驗證包括兩個單獨的專案：

1. 受信任的證書頒發機構(CA)鏈

2. 主題替代名稱(SAN)或通用名稱(CN)

受信任的CA鏈

要使Expressway-C信任CUCM/IM&P/Unity傳送的證書，它需要能夠建立從該證書到其信任的最頂級（根）證書頒發機構(CA)的連結。此類連結是將實體證書連結到根CA證書的證書層次結構，稱為信任鏈。為了能夠驗證這種信任鏈，每個證書包含兩個欄位：頒發者（或「頒發者」）和主體（或「頒發者」）。

伺服器證書（例如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，以及其他屬性，如Country (C)、State (ST)、Location (L)、...此外，我們還可以看到，伺服器證書由名為vngtp-ACTIVE-DIR-CA的CA分發（頒發）。

頂級CA（根CA）也可以頒發證書來標識自己。在此根CA證書中，我們可以看到Issuer和Subject具有相同值：

        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的伺服器證書，則不存在這種情況）。

注意：雖然頒發者和主題欄位易於以易於閱讀的方式構建信任鏈，但CUCM在證書中不會使用這些欄位。相反，它使用「X509v3授權金鑰識別符號」和「X509v3主題金鑰識別符號」欄位來構建信任鏈。這些金鑰包含比使用Subject/Issuer欄位更準確的證書識別符號：可能有2個證書具有相同的Subject/Issuer欄位，但其中一個證書已過期，還有一個證書仍然有效。它們都有不同的X509v3主題金鑰識別符號，因此CUCM仍可確定正確的信任鏈。

但根據思科漏洞ID CSCwa12905，Expressway不會出現這種情況，並且無法將兩個不同（例如自簽名）證書上傳到具有相同公用名(CN)的Expressway信任庫中。對此進行更正的方法是CA簽名證書或使用不同的通用名稱，或者檢視它是否始終使用相同的證書（可能透過CUCM 14中的重複使用證書功能）。

SAN或CN檢查

第1步將簽出信任庫，但擁有由信任庫中的CA簽名的證書的任何人到那時都是有效的。這顯然不夠。因此，還會進行額外的檢查，以驗證您專門連線的伺服器是否正確。它會根據發出請求的地址來執行此操作。

在瀏覽器中也會發生相同型別的操作，因此讓我們透過一個示例來瞭解這一點。如果瀏覽到https://www.cisco.com，您將在輸入的URL旁邊看到一個鎖圖示，表示它是受信任的連線。這基於CA信任鏈（來自第一部分）以及SAN或CN檢查。如果我們打開證書（透過瀏覽器按一下鎖定圖示），您會看到「公用名」（見「頒發給：」欄位）設定為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配置上，當您需要在Configuration > Unified Communications > Unified CM servers / IM and Presence Service nodes / Unity Connection servers下增加CUCM / IM&P / Unity伺服器時，有一個透過將「TLS驗證模式」配置為「開」進行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 發行版本註釋中所示。簡而言之，您可以從維護>安全>密碼中看到每個密碼清單是否列在「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登入失敗後停止。尚未為其啟用其他調試日誌記錄。

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"

「證書驗證失敗」錯誤表明Expressway-C無法驗證TLS握手。其原因顯示在警告行上，因為它指示自簽名證書。如果深度顯示為0，則其為自簽名證書。當深度高於0時，意味著它具有證書鏈，因此由未知CA簽名（從Expressway-C的角度來看）。

當我們檢視透過文本日誌中提及的時間戳收集的pcap檔案時，您可以看到CUCM將帶有CN的證書顯示為cucm-ms.steven.lab（由steven-DC-CA簽名為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的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轉換(base64)為steven.lab/https/10.48.36.215/8443，這表示它必須連線至10.48.36.215作為連線地址，而不是連線至cucm.steven.lab。如資料包捕獲所示，CUCM tomcat證書不包含SAN中的IP地址，因此會引發錯誤。

如何輕鬆驗證

您可以驗證是否透過後續步驟輕鬆實現此行為更改：

1. 在Expressway E和Expressway C伺服器上啟動診斷日誌記錄（最好啟用TCPDumps），方法是透過維護>診斷>診斷日誌記錄（如果是集群，則僅從主節點啟動即可）

2. 在升級後嘗試MRA登入或測試中斷的功能

3. 等待直到失敗，然後停止Expressway E和Expressway 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消息，則需要相應地更新Expressway-C伺服器上的信任庫。使用簽名此證書的CA鏈（深度> 0）或使用維護>安全>受信任CA證書中的自簽名證書（深度= 0）。請確定在叢集的每個伺服器上執行此動作。另一個選項是透過Expressway-C信任儲存上的已知CA對遠端證書進行簽名。

注意：Expressway不允許將兩個不同的（例如自簽名）證書上傳到Expressway的信任儲存中，這些證書與思科漏洞ID CSCwa12905具有相同公用名(CN)。要更正此問題，請轉到CA簽名的證書或將CUCM升級到版本14，您可以在此為Tomcat和CallManager重複使用相同的（自簽名）證書。

觀察警告： 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

It