簡介
本檔案介紹適用於行動及遠端存取的CUCM上的憑證上傳要求。
背景資訊
Cisco Expressway使用Apache Traffic Server(ATS)。流量伺服器是遍歷解決方案中非常重要的元件,主要用於以下功能:
- 證書驗證:它對Cisco Unified Communications Manager(CUCM)、即時消息和線上狀態以及Unity伺服器節點執行MRA服務的證書驗證。
- 代理和快取:它充當HTTP/HTTPS流量的快速、可擴展快取代理伺服器。
Expressway版本14.0.2
流量伺服器(ATS)在MRA調配期間與CUCM協商時,會開始看到「證書驗證」的輕微實施。
要求記錄在CSCvz45074下,其中簽署Expressway核心伺服器證書的根證書必須作為Tomcat-Trust和Callmanager Trust上載到CUCM:https://cdetsng.cisco.com/summary/#/defect/CSCvz45074。
- 流量伺服器實施證書驗證。
- 升級到X14.0.2版本之前,請確保符合此證書要求。
要求 — 必須向CUCM的tomcat-trust和CallManager-trust清單中新增簽署Expressway-C證書的證書頒發機構(CA)鏈(根+中介),即使Unified Communications Manager(UCM)處於非安全模式也是如此。
原因 — 每當伺服器UCM請求證書時,Expressway中的流量伺服器服務都會傳送其證書。這些請求適用於在8443以外的埠(例如埠6971、6972等)上運行的服務。 即使UCM處於非安全模式,這也會強制進行證書驗證。有關詳細資訊,請參閱通過Expressway進行移動和遠端訪問部署指南。
早於14.0.8版本的行為
處理Expressway-C和統一通訊節點之間的安全HTTPS雙向連線的Expressway-C上的流量伺服器未驗證遠端端提供的證書。在MRA配置下,在Configuration > Unified Communications > Unified CM servers/IM and Presence Service nodes/Unity Connection servers下新增CUCM、IM&P或Unity伺服器時,可以選擇將TLS驗證模式配置為「On」,以驗證TLS證書。配置選項顯示在下一個螢幕截圖中,指示它驗證SAN中的FQDN或IP、證書的有效性以及證書是否由受信任的CA簽名。
還存在一個已知問題,即無法將兩個具有相同CN名稱的證書載入到Expressway信任儲存上。此限制導致了兩個問題:
1.如果選擇在Expressway信任儲存上載入呼叫管理器證書,則新增CUCM時,TLS驗證「開啟」將失敗。
2:如果選擇在Expressway信任儲存上載入Tomcat證書,則在5061上安全sip註冊將失敗。
此行為記錄在CSCwa12894中。
此外,此TLS證書驗證檢查僅在發現CUCM/IM&P/Unity伺服器時進行,而不是在MRA客戶端調配期間進行。
此配置的缺點在於它只針對您新增的發佈伺服器地址進行驗證。在從發佈伺服器節點的資料庫中檢索訂閱伺服器節點資訊(FQDN或IP)時,不會驗證訂閱伺服器節點上的證書是否設定正確。


版本14.0.8及更高版本上的行為
從X14.0.8版本開始,Expressway伺服器對通過流量伺服器發出的每個HTTPS請求執行TLS證書驗證。這意味著,在發現CUCM/IM&P/Unity節點期間,當TLS驗證模式設定為「關閉」時,它也會執行此操作。如果驗證未成功,則TLS握手不會完成,並且請求失敗,這會導致功能丟失(例如,冗餘、故障切換問題或完全登入失敗)。此外,如果將「TLS驗證模式」設定為「開」,則不能保證所有連線都能正常運行(如後面的示例所述)。
Expressway向CUCM/IM&P/Unity節點檢查的確切證書如MRA指南一節所示。
https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X15-0/mra/exwy_b_mra-deployment-guide-x150.pdf
截面
Certificate Requirements > Certificate Exchange Requirements
由於Expressway-Core和CUCM之間的通訊方式發生了這些變化,必須確保:
1.建議對移動和遠端訪問使用CA簽名的證書。
2.每個Unified CM集群必須信任Expressway-C證書。對於每個群集,請確保:
- 如果啟用混合模式 — 必須將Expressway-C證書安裝到Unified CM上的CallManager-trust和Tomcat-trust儲存區。
- 如果禁用混合模式 — 必須將Expressway-C證書的根CA證書安裝到Unified CM上的CallManager-trust和Tomcat-trust儲存區。然後重新啟動以下專案:· Tomcat服務· CallManager服務· HA代理服務(如果在Tomcat上使用TLS)。
在Expressway-Core上,確保採取以下措施:
- Expressway-C必須信任每個Unified CM和IM and Presence Service群集提供的證書。
Expressway-C的信任儲存必須包括根CA證書,該證書用於為所有UC群集簽署Unified CM和IM and Presence Service證書。
附註:確保將所有用於簽署Expressway-C證書的根和中間CA證書或完整CA鏈新增到Cisco Unified Communications Manager(UCM)的Tomcat-trust和CallManager-trust清單中,即使UCM在非安全模式下運行。
原因 — 每當伺服器(UCM)請求證書時,Expressway中的流量伺服器服務都會傳送其證書。這些請求適用於在8443以外的埠(例如埠6971、6972等)上運行的服務。 即使UCM處於非安全模式,這也會強制進行證書驗證。
在System > Server下新增CUCM地址的方式在Configuration > Unified Communications > Unified CM servers/IM and Presence Service nodes下新增Expressway核心上的CUCM/IMP時起著非常重要的作用。
必須始終使用FQDN新增CUCM,而不是使用主機名或IP地址。如果發現CUCM在System > Server下新增為主機名/IP地址
在TLS握手期間,TLS驗證「開啟」將失敗,並且不會在Expressway-Core上新增CUCM集群。
下圖顯示新增為主機名的CUCM:

下圖顯示使用FQDN和TLS驗證模式=ON在Expressway-Core上新增的CUCM:

X14.2中還引入了一個更改,該更改將在TLS握手(客戶端問候)期間以不同的優先順序顯示密碼。這取決於升級路徑,並在軟體升級後導致意外的TLS連線。可能是,在TLS握手期間升級之前,它請求從CUCM獲得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相同的行為,其優先順序別較高。
下一個螢幕截圖顯示在客戶端hello中TLS協商消息期間Expressway核心通告的ECDSA密碼的紅色方框中,#IF TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384由伺服器hello中的遠端響應方(CUCM)選擇,則TLS協商將失敗,如果:
根CA證書或來自Responder的實際ECDSA證書,即在此案例中,CUCM未安裝在Expressway信任儲存上。

或者,您也可以修改Expressway密碼,使ECDSA不優先。
1.通過附加GCM-Sha384開放式SSL字串修改SIP密碼。
"ECDHE-RSA-AES256-GCM-SHA384:EECDH:EDH:HIGH:........:!MD5:!PSK:!eNULL:!aNULL:!aDH"
2.添加+以最後移動密碼,或新增!以永久禁用ECDSA。
密碼:"EECDH:EDH:HIGH:-AES256+SHA:!MEDIUM:!LOW:!3DES:!MD5:!PSK:!eNULL:!aNULL:!aDH:+ECDSA"
3.在CUCM上新增簽署ECDSA證書的根和中間CA證書,或在Expressway信任儲存上新增Tomcat-ECDSA證書(在某些情況下)。
但是,由於密碼優先順序的變更、升級後,MRA部署可能會中斷,因此TAC必須執行前面提到的解決方法,才能使工作重新正常。
隨著TLS 1.3的引入,在Wireshark中檢查交換的證書變得更為困難。
x15.3版本上的行為
僅對於SIP介面,您可以選擇使用RSA或ECDSA密碼。
X15.x TLS 1.3已實施。從欄位上看,RSA演算法大多優於ECDSA。現在升級到x15.2的客戶可以選擇
RSA和ECDSA演算法之間的連線:
xConfiguration SIP Advanced TlsSignatureAlgoPrefRsa:開/關
TlssignatureAlgoPrefRSA僅在SIP介面具有TLS 1.3時有效
xConfiguration SIP Advanced SipTlsVersions:"TLSv1.3"
附註:目前這僅適用於SIP介面。8443上的Traffic Server和Tomcat注意事項保持不變,如前文所述。
選擇RSA後,Expressway向CUCM傳送的「客戶端問候」期間傳送的密碼套餐將顯示如下。
- 簽名演算法:rsa_pss_rsae_sha512(0x0806)
- 簽名演算法:rsa_pss_rsae_sha384(0x0805)
- 簽名演算法:rsa_pss_rsae_sha256(0x0804)
- 簽名演算法:ecdsa_secp521r1_sha512(0x0603)
- 簽名演算法:ecdsa_secp384r1_sha384(0x0503)
- 簽名演算法:ecdsa_secp256r1_sha256(0x0403)
在Enterprise Parameters > Security Parameters下,早期的配置將在您在CUCM到TLS密碼上選擇的配置上協同工作。

此外,必須注意的是,在Expressway-C和CUCM之間通過TLS 1.3進行斷開的TLS握手期間,診斷日誌或PCAP中列印的錯誤不會非常有用。在使用TAC時啟用這些調試是值得的,以便元件可以列印清楚的錯誤以進行故障排除。
xConfiguration Logger Developer developer.trafficserver.http級別:"調試"
xConfiguration Logger Developer developer.trafficserver.http_trans級別:"調試"
xConfiguration Logger Developer .trafficserver.iocore級別:"調試"
xConfiguration Logger Developer developer.trafficserver.ssl級別:"調試"
當Callmanager與多個服務共用一個證書時的期望值
在CUCM上重複使用證書後,情況略有變化。
從CUCM 14.0開始,您可以重複使用Tomcat和Tomcat ECDSA證書作為Call manager和Call manager ECDSA。
Tomcat證書可以作為Callmanager證書重新使用。
Tomcat-ECDSA證書可以重用為Callmanager-ECDSA證書。
這讓生活變得輕鬆。
1. CUCM上的多個服務現在使用一個證書,從而降低了證書的成本。
2.證書管理減少。
3.如果您需要在Expressway-Core信任儲存上上傳Tomcat/Callmanager或Tomcat-ECDSA/Callmanager-ECDSA證書(出於任何原因),則只需上傳一個證書。不存在相同的CN名稱問題(本文檔前面已討論)。
附註:只有當Tomcat和Tomcat-ECDSA是多SAN證書時,才會重複使用證書。
Post Reuse、Callmanager和Callmanager ECDSA伺服器證書在CUCM信任儲存上不可見。您可以通過運行以下命令從CLI驗證證書重複使用:
show cert own CallManager
show cert own tomcat
重新使用證書的步驟
正在生成Tomcat CSR pub add。

上傳CA證書,該證書將作為Tomcat-trust在CUCM上簽署Tomcat證書。

簽署Tomcat證書後,即可上傳到發佈伺服器上。根據提示重新啟動相關服務。

簽署Tomcat證書後,即可上傳到發佈伺服器上。根據提示重新啟動相關服務。
|
成功:證書已上載。執行災難恢復備份,以便最新備份包含上傳的證書。
|
|
在所有群集節點(UCM/IMP)上使用CLI「utils service restart Cisco Tomcat」重新啟動Cisco Tomcat Web服務。 在所有UCM群集節點上使用CLI「utils service restart Cisco UDS Tomcat and utils service restart Cisco AXL Tomcat」重新啟動Cisco UDS Tomcat和Cisco AXL Tomcat Web服務。此外,在發佈器節點上重新啟動Cisco DRF Master和Cisco DRF Local服務。僅重啟使用者節點上的Cisco DRF本地服務。
|
Tomcat證書現在由CA簽名。

以便立即將Tomcat證書重新用作Callmanager證書。
按一下「Reuse Certificate」。

在下拉選單中選擇Tomcat並檢查Callmanager證書。

按一下「Finish」(結束)。

Tomcat證書現在被重用為Callmanager證書。這可通過CLI進行驗證。
Callmanager證書序列號(SN):56:ff:6c:71:00:00:00:00:00:00:0d

Tomcat certificate SN:56:ff:6c:71:00:00:00:00:00:00:0d

對訂閱伺服器執行相同步驟。
允許立即對ECDSA證書簽名,以便它可以作為Callmanager-ECDSA重複使用。
當前的Tomcat-ECDSA證書是自簽名的。

為Tomcat-ECDSA證書簽署多san CSR。

使用CSR簽署憑證並上傳。


上傳成功。根據提示重新啟動相關服務。

由CA簽名的Tomcat和Tomcat-ECDSA。

現在將Tomcat-ECDSA重用為Callmanager-ECDSA證書。

上傳成功。根據提示重新啟動相關服務。

從CLI驗證憑證。
Callmanager-ECDSA證書SN:2f:00:00:00:38:80:be:cc:a8:a1:8e:8f:23:00:00:00:00:00:38

Tomcat-ECDSA證書SN:2f:00:00:00:38:80:be:cc:a8:a1:8e:8f:23:00:00:00:00:38。

由於您現在對兩個服務使用了一個證書,即,用於Tomcat和Callmanager服務的Tomcat證書,以及用於Tomcat-ECDSA和Callmanager-ECDSA服務的Tomcat-ECDSA,因此在Expressway信任儲存上上傳證書變得不那麼麻煩(如果需要上傳)。
在用於MRA的expressway-core上新增UCM時,讓TLS驗證「開啟」比以往任何時候都更加容易。只需新增一個Tomcat證書CA或伺服器證書即可完成該作業(因為證書現在在Callmanager和Tomcat服務之間共用)。

如果升級到x14.2或更高版本導致了移動遠端訪問的中斷,則還可以參考本綜合文檔來排查問題。
Apache流量伺服器版本歷史記錄
若要檢查伺服器上的版本,請登入到root並運行~ # /apache2/bin/httpd -v。
Expressway x8.11.4
伺服器版本:Apache/2.4.34(Unix)
已構建伺服器:2018年11月12日19:04:23
Expressway x12.6
伺服器版本:Apache/2.4.43(Unix)
已構建伺服器:2020年5月26日18:27:21
Expressway x14.0.8
伺服器版本:Apache/2.4.53(Unix)
已構建伺服器:2022年5月4日08:52:57
Expressway x15.3
伺服器版本:Apache/2.4.62(Unix)
已構建伺服器:2025年7月16日12:10:19
這是因為Expressway中的流量伺服器服務有一些改進。
要求 — 必須將對簽署Expressway-C證書的證書頒發機構(CA)新增到Cisco Unified Communications Manager(UCM)的tomcat-trust和CallManager-trust清單中,即使UCM處於非安全模式。
原因 — 每當伺服器(UCM)請求證書時,Expressway中的流量伺服器服務都會傳送其證書。這些請求針對的是在8443以外的埠(例如,埠6971、6972、...)上運行的服務。 即使UCM處於非安全模式,也可以實施證書驗證。有關詳細資訊,請參閱通過Expressway進行移動和遠端訪問部署指南。
這是因為Expressway中的流量伺服器服務有一些改進。
要求 — 必須將對簽署Expressway-C證書的證書頒發機構(CA)新增到Cisco Unified Communications Manager(UCM)的tomcat-trust和CallManager-trust清單中,即使UCM處於非安全模式。
原因 — 每當伺服器(UCM)請求證書時,Expressway中的流量伺服器服務都會傳送其證書。這些請求針對的是在8443以外的埠(例如,埠6971、6972、...)上運行的服務。 即使UCM處於非安全模式,也可以實施證書驗證。有關詳細資訊,請參閱通過Expressway進行移動和遠端訪問部署指南。
這是因為Expressway中的流量伺服器服務有一些改進。
要求 — 必須將對簽署Expressway-C證書的證書頒發機構(CA)新增到Cisco Unified Communications Manager(UCM)的tomcat-trust和CallManager-trust清單中,即使UCM處於非安全模式。
原因 — 每當伺服器(UCM)請求證書時,Expressway中的流量伺服器服務都會傳送其證書。這些請求針對的是在8443以外的埠(例如,埠6971、6972、...)上運行的服務。 即使UCM處於非安全模式,也可以實施證書驗證。有關詳細資訊,請參閱通過Expressway進行移動和遠端訪問部署指南。