對CSCwc69661 / CSCwa25108引入的MRA服務的Expressway流量伺服器證書驗證進行故障排除

簡介

本檔案介紹連結到Cisco錯誤ID CSCwc6961或Cisco錯誤ID CSCwa25108的Expressway版本X14.2.0和更高版本上的行為變更。

必要條件

需求

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

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

採用元件

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

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

背景資訊

此行為更改由Cisco錯誤ID CSCwc69661標籤 或思科錯誤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證書的證書分層結構，稱為信任鏈。為了能夠驗證這種信任鏈，每個證書包含兩個欄位：頒發者（或「頒發者」）和主體（或「頒發者」）。

伺服器證書（例如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:  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授權金鑰識別符號」和「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檢查。如果我們開啟證書（通過瀏覽器按一下鎖定圖示），您會看到公用名（在「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服務嚴重依賴於Expressway上指向CUCM/IM&P/Unity伺服器的多個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）時，不會驗證訂閱伺服器節點上的證書是否設定正確。此配置的第二個缺點是，由於連線資訊而通告給MRA客戶端的內容可能與在Expressway-C配置中放入的發佈者地址不同。例如，在CUCM上，在System > Server下，可以使用IP地址（例如10.48.36.215）將伺服器通告出去，然後由MRA客戶端使用（通過代理的Expressway連線），但是您可以使用FQDN cucm.steven.lab在Expressway-C上新增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獲得Cisco Tomcat或Cisco CallManager證書（或任何其他具有單獨的ECDSA演算法證書的產品），但在升級之後，它請求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"

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

當我們檢視在文本日誌中提及的時間戳處收集的pcap檔案時，可以看到CUCM將帶有CN的證書顯示為cucm-ms.steven.lab(由steven-DC-CA簽名為cucm-ms.steven.lab(SAN))，並顯示Expressway-C的埠8443。

但是，當我們檢查埠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 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消息，然後您需要相應地更新Expressway-C伺服器上的信任儲存。使用簽署此證書的CA鏈（深度> 0）或使用Maintenance > Security > Trusted CA Certificate中的自簽名證書（深度= 0）。確保在群集中的每個伺服器上執行此操作。另一種方法是，由Expressway-C信任儲存上的已知CA對遠端證書進行簽名。

附註： Expressway不允許將兩個不同的（例如自簽名）證書上傳到Expressway的信任儲存中，這些證書根據思科錯誤ID CSCwa12905具有相同的公用名(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