簡介
本檔案介紹連結到Cisco錯誤ID CSCwc6961或Cisco錯誤ID CSCwa25108的Expressway版本X14.2.0和更高版本上的行為變更。
必要條件
需求
思科建議您瞭解以下主題:
採用元件
本文檔中的資訊基於Cisco Expressway版本X14.2及更高版本。
本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除(預設)的組態來啟動。如果您的網路運作中,請確保您瞭解任何指令可能造成的影響。
背景資訊
此行為更改由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 Authority Key Identifier和X509v3 Subject Key Identifier欄位構建信任鏈。這些金鑰包含更準確的證書識別符號,然後使用Subject/Issuer欄位:可以有2個證書具有相同的Subject/Issuer欄位,但其中一個證書已過期,而且一個證書仍然有效。它們都有不同的X509v3主題金鑰識別符號,因此CUCM仍可確定正確的信任鏈。
雖然根據思科錯誤ID CSCwa12905,Expressway不會出現這種情況,且無法將兩個不同的(例如自簽名)憑證上傳到具有相同公用名稱(CN)的Expressway信任儲存區。 對此進行更正的方法是CA簽名的證書或使用不同的通用名稱,或者檢視它始終使用相同的證書(可能通過CUCM 14中的重複使用證書功能)。
SAN或CN檢查
第1步將簽出信任庫,但是,具有信任庫中的CA簽名的證書的任何人都將有效。這顯然是不夠的。因此,還會進行其他檢查,以驗證您專門連線的伺服器是否確是正確的伺服器。它基於發出請求的地址執行此操作。
在瀏覽器中也會發生同樣的操作,因此您可以在示例中看到這一點。如果您瀏覽到Cisco.com,會在您輸入的URL旁看到一個鎖定圖示,表示這是受信任連線。這既基於CA信任鏈(來自第一部分),也基於SAN或CN檢查。如果您開啟證書(通過瀏覽器按一下鎖定圖示),您將看到公用名(在「頒發給:欄位)設定為Cisco.com,且此欄位完全對應於您要連線的地址。通過這種方式,您可以確保連線到正確的伺服器(因為您信任簽署證書並在分發證書之前執行驗證的CA)。

當您檢視證書的詳細資訊(尤其是SAN條目)時,您會看到該詳細資訊與某些其他FQDN一樣重複:

這表示當您請求連線到Cisco.com時,它會顯示為安全連線,因為它包含在SAN條目中。

但是,如果您不瀏覽到Cisco.com,而是直接瀏覽到IP地址(編號的網址),則不會顯示安全連線,因為它不信任簽署它的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配置中,有一個選項用於TLS證書驗證,方法是將TLS驗證模式配置為「開」,此時您將在Configuration > Unified Communications > Unified CM servers / IM and Presence Service nodes / Unity Connection servers下新增CUCM / IM&P / Unity伺服器。配置選項和相關資訊框顯示為示例,指示其確實驗證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連線),但是,您可以在Expressway-C的CUCM中新增其FQDN為cucm.steven.lab。因此,假設CUCM的tomcat證書包含cucm.steven.lab作為SAN條目而不是IP地址,則將TLS驗證模式設定為On的發現成功,但來自MRA客戶端的實際通訊可能以不同的FQDN或IP為目標,因此未通過TLS驗證。
X14.2.0及更高版本
從X14.2.0版本開始,Expressway伺服器會對通過流量伺服器發出的每個HTTPS請求執行TLS證書驗證。這意味著,在發現CUCM/IM&P/Unity節點期間,當TLS驗證模式設定為Off時,它也會執行此功能。如果驗證不成功,則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簽名的cucm.steven.lab為SAN),並傳送到埠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 translate(base64)到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驗證正常工作。要執行的操作取決於顯示的警告消息。
當您看到「警告:無法驗證(<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不允許您將兩個不同的(例如自簽名)證書上傳到Expressway的信任儲存中,這些證書根據思科錯誤ID CSCwa12905具有相同的公用名(CN)。若要更正此問題,請轉到CA簽名的證書或將您的CUCM升級到版本14,您可以在該版本中為Tomcat和CallManager重複使用相同的(自簽名)證書。
當您看到「警告:SNI(<server-FQDN-or-IP>)not in certificate"消息,則表示此伺服器FQDN或IP未包含在提供的證書中。您可以調整證書以包含該資訊,或者可以修改配置(例如使用CUCM System > Server來修改伺服器證書中包含的配置),然後在Expressway-C伺服器上刷新配置以將其考慮在內。
相關資訊
短期解決方案是應用所記錄的解決方法,以回退到X14.2.0之前的先前行為。您可以通過Expressway-C伺服器節點上的CLI使用新引入的命令來執行此操作:
xConfiguration EdgeConfigServer VerifyOriginServer: Off