瞭解預設情況下的CUCM安全以及ITL運行和故障排除
簡介
本文檔介紹思科統一通訊管理器(CUCM) 8.0版及更高版本的預設安全(SBD)功能。
背景資訊
CUCM版本8.0及更高版本引入了SBD功能，包括身份信任清單(ITL)檔案和信任驗證服務(TVS)。
每個CUCM集群現在自動使用基於ITL的安全性。在安全性和易用性/管理便利性之間有一個權衡，管理員在對8.0版CUCM集群進行某些更改之前必須瞭解這一點。
本文檔是對官方預設安全文檔的補充，提供了操作資訊和故障排除提示，有助於管理員和簡化故障排除過程。
熟悉SBD的核心概念是一個好主意：非對稱金鑰加密維基百科文章和公鑰基礎設施維基百科文章。
SBD概述
本部分簡要概述了SBD的具體功能。有關每個功能的完整技術詳細資料，請參閱SBD詳細資料和故障排除資訊部分。
SBD為支援的IP電話提供以下三種功能：
- 使用簽名金鑰的TFTP下載檔案（配置、區域設定、鈴聲）的預設身份驗證
- 使用簽名金鑰的TFTP配置檔案的可選加密
- 使用CUCM (TVS)上的遠端證書信任庫對電話啟動的HTTPS連線的證書驗證
本文檔概述了這些功能。
TFTP下載驗證
如果存在證書信任清單(CTL)或ITL檔案，則IP電話會從CUCM TFTP伺服器請求已簽名的TFTP配置檔案。
此檔案允許電話驗證配置檔案是否來自受信任的源。如果電話上存在CTL/ITL檔案，則配置檔案必須由受信任的TFTP伺服器簽署。
檔案在傳輸時是網路中的純文字檔案，但帶有特殊的驗證簽名。
電話請求SEP<MAC Address>.cnf.xml.sgn以接收帶有特殊簽名的配置檔案。
此配置檔案由與作業系統(OS)管理證書管理頁面上的CallManager.pem相對應的TFTP私鑰簽名。
簽名檔案在頂部具有簽名以對檔案進行身份驗證，否則為純文字檔案XML。
下圖顯示配置檔案的簽名者是CN=CUCM8-Publisher.bbbburns.lab，後者又由CN=JASBURNS-AD簽署。
這意味著在接受此配置檔案之前，電話需要根據ITL檔案驗證CUCM8-Publisher.bbburns.lab的簽名。
以下圖表顯示私密金鑰如何與訊息摘要演演算法(MD)5或安全雜湊演演算法(SHA)1雜湊函式搭配使用，以便建立簽署的檔案。
簽名驗證透過使用匹配的公鑰來解密雜湊來反轉此過程。如果雜湊匹配，則顯示：
- 此檔案在傳輸過程中未被修改。
- 此檔案來自簽名中列出的參與方，因為使用公鑰成功解密的任何內容都必須使用私鑰進行加密。
TFTP配置檔案加密
如果在關聯的電話安全配置檔案中啟用了可選的TFTP配置加密，則電話會請求加密配置檔案。
此檔案使用TFTP私鑰進行簽名，並使用電話和CUCM之間交換的對稱金鑰進行加密(有關詳細資訊，請參閱Cisco Unified Communications Manager安全指南8.5(1)版)。
除非觀察者具有必要的金鑰，否則無法使用網路嗅探器讀取其內容。
電話請求SEP<MAC Address>.cnf.xml.enc.sgn以獲得經過簽名的加密檔案。
加密的配置檔案在開頭也有簽名，但之後沒有純文字檔案資料，只有加密資料（在此文本編輯器中出現亂碼二進位制字元）。
該圖顯示簽名人與上一個示例中的簽名人相同，因此該簽名人必須存在於國際交易日誌檔案中，電話才能接受該檔案。
此外，解密金鑰必須正確無誤，電話才能讀取檔案的內容。
信任驗證服務（遠端憑證和簽章驗證）
IP電話的記憶體容量有限，而且網路中還可以管理大量電話。
CUCM透過TVS充當遠端信任庫，因此無需在每部IP電話上放置完整的證書信任庫。
每當電話無法通過CTL或ITL檔案驗證簽名或證書時，它就會要求TVS伺服器進行驗證。
與信任儲存存在於所有IP電話上相比，此中心信任儲存更易於管理。
SBD詳細資訊和故障排除資訊
本節詳細介紹SBD流程。
CUCM上的ITL檔案和證書
首先，CUCM伺服器本身必須存在一些檔案。最重要的部分是TFTP證書和TFTP私鑰。
TFTP證書位於OS Administration > Security > Certificate Management > CallManager.pem下。
CUCM伺服器使用CallManager.pem證書私鑰和公鑰進行TFTP服務(以及Cisco Call Manager (CCM)服務)。
下圖顯示，CallManager.pem證書已頒發給CUCM8-publisher.bbbburns.lab，並由JASBURNS-AD簽名。所有TFTP配置檔案均使用以下私鑰進行簽名。
所有電話都可以使用CallManager.pem證書中的TFTP公鑰解密使用TFTP私鑰加密的任何檔案，以及驗證使用TFTP私鑰簽名的任何檔案。
除CallManager.pem證書私鑰外，CUCM伺服器還儲存提供給電話的ITL檔案。
show itl命令透過對CUCM伺服器作業系統CLI的安全外殼(SSH)訪問顯示此ITL檔案的完整內容。
本節逐一分解國際交易日誌檔案，因為它包含電話使用的許多重要元件。
第一部分是簽名資訊。即使是國際交易日誌檔案也是已簽署的檔案。此輸出顯示它透過與先前CallManager.pem證書關聯的TFTP私鑰進行簽名。
admin:show itl
Length of ITL file: 5438
The ITL File was last modified on Wed Jul 27 10:16:24 EDT 2011
Parse ITL File
----------------
Version: 1.2
HeaderLength: 296 (BYTES)
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
3 SIGNERID 2 110
4 SIGNERNAME 76 CN=CUCM8-Publisher.bbbburns.lab;
OU=TAC;O=Cisco;L=RTP;ST=North Carolina;C=US
5 SERIALNUMBER 10 21:00:2D:17:00:00:00:00:00:05
6 CANAME 15 CN=JASBURNS-AD
*Signature omitted for brevity*
接下來的每個部分都包含它們的目的，在一個特殊函式引數中。第一個功能是系統管理員安全性權杖。這是TFTP公鑰的簽名。
ITL Record #:1
----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 1972
2 DNSNAME 2
3 SUBJECTNAME 76 CN=CUCM8-Publisher.bbbburns.lab;
OU=TAC;O=Cisco;L=RTP;ST=North Carolina;C=US
4 FUNCTION 2 System Administrator Security Token
5 ISSUERNAME 15 CN=JASBURNS-AD
6 SERIALNUMBER 10 21:00:2D:17:00:00:00:00:00:05
7 PUBLICKEY 140
8 SIGNATURE 256
9 CERTIFICATE 1442 0E 1E 28 0E 5B 5D CC 7A 20 29 61 F5
8A DE 30 40 51 5B C4 89 (SHA1 Hash HEX)
This etoken was used to sign the ITL file.
下一個功能是CCM+TFTP。這同樣是TFTP公鑰，用於驗證和解密下載的TFTP配置檔案。
ITL Record #:2
----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 1972
2 DNSNAME 2
3 SUBJECTNAME 76 CN=CUCM8-Publisher.bbbburns.lab;
OU=TAC;O=Cisco;L=RTP;ST=North Carolina;C=US
4 FUNCTION 2 CCM+TFTP
5 ISSUERNAME 15 CN=JASBURNS-AD
6 SERIALNUMBER 10 21:00:2D:17:00:00:00:00:00:05
7 PUBLICKEY 140
8 SIGNATURE 256
9 CERTIFICATE 1442 0E 1E 28 0E 5B 5D CC 7A 20 29 61 F5
8A DE 30 40 51 5B C4 89 (SHA1 Hash HEX)
下一個功能是TVS。電話連線的每個TVS伺服器的公鑰都有一個條目。
這允許電話建立到TVS伺服器的安全套接字層(SSL)會話。
ITL Record #:3
----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 743
2 DNSNAME 2
3 SUBJECTNAME 76 CN=CUCM8-Publisher.bbbburns.lab;
OU=TAC;O=Cisco;L=RTP;ST=North Carolina;C=US
4 FUNCTION 2 TVS
5 ISSUERNAME 76 CN=CUCM8-Publisher.bbbburns.lab;
OU=TAC;O=Cisco;L=RTP;ST=North Carolina;C=US
6 SERIALNUMBER 8 2E:3E:1A:7B:DA:A6:4D:84
7 PUBLICKEY 270
8 SIGNATURE 256
11 CERTHASH 20 C7 E1 D9 7A CC B0 2B C2 A8 B2 90 FB
AA FE 66 5B EC 41 42 5D
12 HASH ALGORITHM 1 SHA-1
國際交易日誌檔案中包含的最終功能是證書頒發機構代理功能(CAPF)。
此證書允許電話建立到CUCM伺服器上CAPF服務的安全連線，以便電話可以安裝或更新本地重要證書(LSC)。
ITL Record #:4
----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 455
2 DNSNAME 2
3 SUBJECTNAME 61 CN=CAPF-9c4cba7d;
OU=TAC;O=Cisco;L=RTP;ST=North Carolina;C=US
4 FUNCTION 2 CAPF
5 ISSUERNAME 61 CN=CAPF-9c4cba7d;
OU=TAC;O=Cisco;L=RTP;ST=North Carolina;C=US
6 SERIALNUMBER 8 0A:DC:6E:77:42:91:4A:53
7 PUBLICKEY 140
8 SIGNATURE 128
11 CERTHASH 20 C7 3D EA 77 94 5E 06 14 D2 90 B1
A1 43 7B 69 84 1D 2D 85 2E
12 HASH ALGORITHM 1 SHA-1
The ITL file was verified successfully.
下一節將介紹電話啟動時發生的具體情況。
電話下載ITL和配置檔案
在電話啟動並獲得IP地址和TFTP伺服器地址後，它會首先請求CTL和ITL檔案。
此資料包捕獲顯示了對ITL檔案的電話請求。如果過濾條件為tftp.opcode == 1，您將看到電話發出的每個TFTP讀取請求：
由於電話成功地從TFTP接收了CTL和ITL檔案，因此電話會請求一個已簽名的配置檔案。
可以從電話Web介面獲取顯示此行為的電話控制檯日誌：
首先，電話請求CTL檔案，成功：
837: NOT 09:13:17.561856 SECD: tlRequestFile: Request CTLSEP0011215A1AE3.tlv
846: NOT 09:13:17.670439 TFTP: [27]:Requesting CTLSEP0011215A1AE3.tlv from
14 . 48 . 44 . 80
847: NOT 09:13:17.685264 TFTP: [27]:Finished --> rcvd 4762 bytes
接下來，電話還會請求一個ITL檔案：
868: NOT 09:13:17.860613 TFTP: [28]:Requesting ITLSEP0011215A1AE3.tlv from
14 . 48 . 44 . 80
869: NOT 09:13:17.875059 TFTP: [28]:Finished --> rcvd 5438 bytes
電話驗證ITL和配置檔案
下載完國際交易日誌檔案後，必須對其進行驗證。此時電話可以處於多種狀態，因此本文檔涵蓋所有這些狀態。
- 電話沒有CTL或ITL檔案，或者ITL為空，因為準備集群以回滾到8.0之前的引數。在此狀態下，電話盲目信任下載的下一個CTL或ITL檔案，並隨後使用此簽名。
- 電話已經有CTL，但是沒有ITL。在此狀態下，只有當CTL檔案中的CCM+TFTP功能可以驗證時，電話才信任一個ITL。
- 電話已經有CTL和ITL檔案。在此狀態下，電話會驗證最近下載的檔案是否與CTL、ITL或TVS伺服器中的簽名匹配。
以下流程圖說明了電話如何驗證簽名檔案和HTTPS證書：
在這種情況下，電話能夠驗證ITL和CTL檔案中的簽名。該電話已具有CTL和ITL，因此它只是對照它們進行檢查並找到正確的簽名。
877: NOT 09:13:17.925249 SECD: validate_file_envelope:
File sign verify SUCCESS; header length <296>
由於電話下載了CTL和ITL檔案，因此從此時開始，它只請求已簽名的配置檔案。
這說明，電話邏輯是基於CTL和ITL的存在，確定TFTP伺服器是安全的，然後要求簽署檔案：
917: NOT 09:13:18.433411 tftpClient: tftp request rcv'd from /usr/tmp/tftp,
srcFile = SEP0011215A1AE3.cnf.xml, dstFile = /usr/ram/SEP0011215A1AE3.cnf.xml
max size = 550001
918: NOT 09:13:18.457949 tftpClient: auth server - tftpList[0] = ::ffff:
14 . 48 . 44 . 80
919: NOT 09:13:18.458937 tftpClient: look up server - 0
920: NOT 09:13:18.462479 SECD: lookupCTL: TFTP SRVR secure
921: NOT 09:13:18.466658 tftpClient: secVal = 0x9 922: NOT 09:13:18.467762
tftpClient: ::ffff:14 . 48 . 44 . 80 is a secure server
923: NOT 09:13:18.468614 tftpClient: retval = SRVR_SECURE
924: NOT 09:13:18.469485 tftpClient: Secure file requested
925: NOT 09:13:18.471217 tftpClient: authenticated file approved - add .sgn
-- SEP0011215A1AE3.cnf.xml.sgn
926: NOT 09:13:18.540562 TFTP: [10]:Requesting SEP0011215A1AE3.cnf.xml.sgn
from 14 . 48 . 44 . 80 with size limit of 550001
927: NOT 09:13:18.559326 TFTP: [10]:Finished --> rcvd 7652 bytes
下載簽名配置檔案後，電話必須根據ITL內的CCM+TFTP功能對其進行身份驗證：
937: NOT 09:13:18.656906 SECD: verifyFile: verify SUCCESS
</usr/ram/SEP0011215A1AE3.cnf.xml>
電話連絡TVS以取得未知憑證
ITL檔案提供了一個TVS功能，其中包含在CUCM伺服器TCP埠2445上運行的TVS服務的證書。
TVS在啟用CallManager服務的所有伺服器上運行。CUCM TFTP服務使用配置的CallManager組來構建電話必須在電話配置檔案上聯絡的TVS伺服器清單。
某些實驗僅使用一台CUCM伺服器。在多節點CUCM集群中，一個電話最多可以有三個TVS條目，電話CUCM組中的每個CUCM各一個。
本示例顯示按下IP電話上的Directories 按鈕後會發生的情況。目錄URL配置為HTTPS，因此電話會從目錄伺服器獲得Tomcat Web證書。
此Tomcat Web證書（OS管理中的tomcat.pem）未載入到電話中，因此電話必須聯絡TVS才能對證書進行身份驗證。
如需互動的說明，請參閱先前的TVS概觀圖表。下面是電話控制檯日誌的視角：
首先您會找到目錄URL：
1184: NOT 15:20:55.219275 JVM: Startup Module Loader|cip.dir.TandunDirectories:
? - Directory url https://14 . 48 . 44 . 80:8443/ccmcip/xmldirectory.jsp
這是需要驗證的SSL/傳輸層安全(TLS)安全HTTP會話。
1205: NOT 15:20:59.404971 SECD: clpSetupSsl: Trying to connect to IPV4, IP:
14 . 48 . 44 . 80, Port : 8443
1206: NOT 15:20:59.406896 SECD: clpSetupSsl: TCP connect() waiting,
<14 . 48 . 44 . 80> c:8 s:9 port: 8443
1207: NOT 15:20:59.408136 SECD: clpSetupSsl: TCP connected,
<14 . 48 . 44 . 80> c:8 s:9
1208: NOT 15:20:59.409393 SECD: clpSetupSsl: start SSL/TLS handshake,
<14 . 48 . 44 . 80> c:8 s:9
1209: NOT 15:20:59.423386 SECD: srvr_cert_vfy: Server Certificate
Validation needs to be done
電話首先會驗證SSL/TLS伺服器提供的證書是否在CTL中。然後，電話檢視ITL檔案中的函式，以檢視是否找到匹配。
此錯誤消息顯示「HTTPS證書不在CTL中」，這意味著「在CTL或ITL中找不到該證書」。
1213: NOT 15:20:59.429176 SECD: findByCertAndRoleInTL: Searching TL from CTL file
1214: NOT 15:20:59.430315 SECD: findByCertAndRoleInTL: Searching TL from ITL file
1215: ERR 15:20:59.431314 SECD: EROR:https_cert_vfy: HTTPS cert not in CTL,
<14 . 48 . 44 . 80>
在檢查CTL和ITL檔案的直接內容以獲取證書後，電話檢查的下一件事情是TVS快取。
如果電話最近向TVS伺服器請求了相同的證書，這樣做是為了減少網路流量。
如果在電話快取中找不到HTTPS憑證，您可以建立與TVS伺服器本身的TCP連線。
1220: NOT 15:20:59.444517 SECD: processTvsClntReq: TVS Certificate
Authentication request
1221: NOT 15:20:59.445507 SECD: lookupAuthCertTvsCacheEntry: No matching
entry found at cache
1222: NOT 15:20:59.446518 SECD: processTvsClntReq: No server sock exists,
must be created
1223: NOT 15:20:59.451378 SECD: secReq_initClient: clnt sock fd 11 bound
to </tmp/secClnt_secd>
1224: NOT 15:20:59.457643 SECD: getTvsServerInfo: Phone in IPv4 only mode
1225: NOT 15:20:59.458706 SECD: getTvsServerInfo: Retreiving IPv4 address
1230: NOT 15:20:59.472628 SECD: connectToTvsServer: Successfully started
a TLS connection establishment to the TVS server: IP:14 . 48 . 44 . 80, port:2445
(default); Waiting for it to get connected.
請記住，與TVS本身的連線是SSL/TLS（安全HTTP或HTTPS），因此它也是需要根據CTL到ITL進行驗證的證書。
如果一切正常，可在國際交易日誌檔案的TVS功能中找到TVS伺服器證書。請參閱上一個國際交易日誌檔案範例中的國際交易日誌記錄#3。
1244: NOT 15:20:59.529938 SECD: srvr_cert_vfy: Server Certificate Validation
needs to be done
1245: NOT 15:20:59.533412 SECD: findByIssuerAndSerialAndRoleInTL:
Searching TL from CTL file
1246: NOT 15:20:59.534936 SECD: findByIssuerAndSerialAndRoleInTL:
Searching TL from ITL file
1247: NOT 15:20:59.537359 SECD: verifyCertWithHashFromTL: cert hash and
hash in TL MATCH
1248: NOT 15:20:59.538726 SECD: tvs_cert_vfy: TVS cert verified with hash
from TL, <14 . 48 . 44 . 80>
成功！電話現在可以安全地連線到TVS伺服器。下一步是詢問TVS伺服器「Hello， Do I trust this Directories server certificate？」
此示例顯示對該問題的答案-響應0表示成功（無錯誤）。
1264: NOT 15:20:59.789738 SECD: sendTvsClientReqToSrvr: Authenticate
Certificate : request sent to TVS server - waiting for response
1273: NOT 15:20:59.825648 SECD: processTvsSrvrResponse: Authentication Response
received, status : 0
由於TVS的回應成功，因此該憑證的結果會儲存到快取中。
這意味著，如果在接下來86,400秒內再次按Directories按鈕，則無需聯絡TVS伺服器即可驗證證書。您可以直接存取本機快取。
1279: NOT 15:20:59.837086 SECD: saveCertToTvsCache: Saving certificate
in TVS cache with default time-to-live value: 86400 seconds
1287: ERR 15:20:59.859993 SECD: Authenticated the HTTPS conn via TVS
最後，您確認您與目錄伺服器的連線成功。
1302: ERR 15:21:01.959700 JVM: Startup Module Loader|cip.http.ae:?
- listener.httpSucceed: https://14 . 48 . 44 . 80:8443/ccmcip/
xmldirectoryinput.jsp?name=SEP0011215A1AE3
以下示例說明在運行TVS的CUCM伺服器上所發生的情況。您可以使用思科統一即時監控工具(RTMT)收集TVS日誌。
CUCM TVS日誌顯示您與電話進行SSL握手，電話向TVS詢問Tomcat證書，然後TVS響應以指示證書在TVS證書儲存中匹配。
15:21:01.954 | debug 14 . 48 . 44 . 202: tvsSSLHandShake Session ciphers - AES256-SHA
15:21:01.954 | debug TLS HS Done for ph_conn .
15:21:02.010 | debug MsgType : TVS_MSG_CERT_VERIFICATION_REQ
15:21:02.011 | debug tvsGetIssuerNameFromX509 - issuerName : CN=CUCM8-
Publisher.bbbburns.lab;OU=TAC;O=Cisco;L=RTP;ST=North Carolina;C=US and Length: 75
15:21:02.011 | debug CertificateDBCache::getCertificateInformation -
Certificate compare return =0
15:21:02.011 | debug CertificateDBCache::getCertificateInformation -
Certificate found and equal
15:21:02.011 | debug MsgType : TVS_MSG_CERT_VERIFICATION_RES
TVS證書儲存是OS Administration > Certificate Management 網頁上包含的所有證書的清單。
手動驗證電話ITL是否與CUCM ITL匹配
在故障排除時發現的一個常見誤解涉及刪除國際交易日誌檔案的趨勢，希望它解決檔案驗證問題。
有時需要刪除國際交易日誌檔案，但只有在滿足所有這些條件時才需要刪除國際交易日誌檔案。
- 電話上的ITL檔案簽名與CM TFTP伺服器上的ITL檔案簽名不匹配。
- ITL檔案中的TVS簽名與TVS提供的證書不匹配。
- 電話在嘗試下載國際交易日誌檔案或配置檔案時顯示「驗證失敗」。
- 不存在舊TFTP私鑰的備份。
以下是檢查前兩個條件的方法。
首先，您可以將CUCM上存在的ITL檔案的校驗和與電話的校驗和ITL檔案進行比較。
當前，無法從CUCM本身檢視CUCM上ITL檔案的MD5sum，除非您運行帶有此思科漏洞ID CSCto60209修復程式的版本。
在此期間，使用您最喜愛的GUI或CLI程式運行以下命令：
jasburns@jasburns-gentoo /data/trace/jasburns/certs/SBD $ tftp 14 . 48 . 44 . 80
tftp> get ITLSEP0011215A1AE3.tlv
Received 5438 bytes in 0.0 seconds
tftp> quit
jasburns@jasburns-gentoo /data/trace/jasburns/certs/SBD $ md5sum
ITLSEP0011215A1AE3.tlv
b61910bb01d8d3a1c1b36526cc9f2ddc ITLSEP0011215A1AE3.tlv
這表明CUCM中ITL檔案的MD5總和是b61910bb01d8d3a1c1b36526cc9f2ddc。
現在您可以檢視電話本身，以確定在那裡載入的ITL檔案的雜湊：設定>安全配置>信任清單。
這表明MD5總和匹配。這意味著電話上的ITL檔案與CUCM上的檔案匹配，因此不需要刪除。
如果匹配，您需要繼續下一個操作-確定國際交易日誌中的電視證書是否與電視提供的證書匹配。這個操作有點複雜。
首先，檢視連線到TCP埠2445上的TVS伺服器的電話的資料包捕獲。
在Wireshark中按一下右鍵此流中的任何資料包，按一下解碼為，然後選擇SSL。尋找如下所示的伺服器憑證：
檢視上一個國際交易日誌檔案中包含的TVS證書。然後您會看到序列號為2E3E1A7BDAA64D84的條目。
admin:show itl
ITL Record #:3
----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 743
2 DNSNAME 2
3 SUBJECTNAME 76 CN=CUCM8-Publisher.bbbburns.lab;
OU=TAC;O=Cisco;L=RTP;ST=North Carolina;C=US
4 FUNCTION 2 TVS
5 ISSUERNAME 76 CN=CUCM8-Publisher.bbbburns.lab;
OU=TAC;O=Cisco;L=RTP;ST=North Carolina;C=US
6 SERIALNUMBER 8 2E:3E:1A:7B:DA:A6:4D:84
如果成功，則ITL檔案中的TVS.pem將與網路上顯示的TVS證書匹配。您不需要刪除國際交易日誌，並且TVS提供正確的證書。
如果檔案身份驗證仍然失敗，請檢查上一個流程圖的其餘部分。
限制和互動
重新產生憑證/重建叢集/憑證到期
現在最重要的憑證是CallManager.pem憑證。該證書私鑰用於簽署所有TFTP配置檔案，包括ITL檔案。
如果重新生成CallManager.pem檔案，則會使用新的私鑰生成新的CCM+TFTP證書。此外，現在此ITL檔案已使用新的CCM+TFTP金鑰進行簽名。
重新生成CallManager.pem並重新啟動TVS和TFTP服務後，電話啟動時會發生這種情況。
- 電話嘗試從TFTP伺服器下載新的TIL檔案，該檔案由新的CCM+TFTP簽署。電話目前只有舊的國際交易日誌檔案，而新金鑰不在電話上的國際交易日誌檔案中。
- 由於電話在舊ITL中找不到新的CCM+TFTP簽名，因此它會嘗試聯絡TVS服務。
- 當電話與TVS聯絡時，運行TVS的CUCM伺服器在作業系統證書儲存中擁有新的CallManager.pem證書。
- TVS伺服器返回成功，電話將新的ITL檔案載入到記憶體中。
- 電話現在會嘗試下載已使用新的CallManager.pem金鑰簽名的配置檔案。
- 由於新國際交易日誌已經載入，新簽署的配置檔案由國際交易日誌在記憶體中成功驗證。
重點：
- 切勿同時重新生成CallManager.pem和TVS.pem證書。
- 如果重新生成TVS.pem或CallManager.pem，則必須重新啟動TVS和TFTP並重置電話，以便獲取新的ITL檔案。
- 較新版本的CUCM會自動處理此電話重置，並在證書重新生成時警告使用者。
- 如果存在多個TVS伺服器（CallManager組中有多個伺服器），則其他伺服器可以對新的CallManager.pem證書進行身份驗證。
在集群間行動電話
當您將電話從一個集群移動到另一個集群並部署了國際交易日誌時，必須考慮國際交易日誌和TFTP私鑰。
提供給電話的任何新配置檔案必須與CTL、ITL中的簽名或電話當前TVS服務中的簽名匹配。
本文檔說明如何確保新的集群ITL檔案和配置檔案可受電話上的當前ITL檔案的信任。https://supportforums.cisco.com/docs/DOC-15799。
備份與還原
CallManager.pem證書和私鑰透過災難恢復系統(DRS)進行備份。如果重建TFTP伺服器，則必須從備份中恢復該伺服器，以便可以恢復私鑰。
如果伺服器上沒有CallManager.pem私鑰，則當前ITL使用舊金鑰的電話不信任已簽名的配置檔案。
如果重建群集後未從備份中恢復，則完全與「在群集之間行動電話」文檔一樣。這是因為對於電話而言，具有新金鑰的集群是不同的集群。
備份和還原存在一個嚴重缺陷。如果集群易受思科漏洞ID CSCtn50405的影響，則DRS備份不包含CallManager.pem證書。
這將導致從此備份恢復的任何伺服器生成損壞的ITL檔案，直到生成新的CallManager.pem。
如果沒有其他正常運行的TFTP伺服器未完成備份和還原操作，這可能意味著需要從電話中刪除所有ITL檔案。
要驗證是否需要重新生成CallManager.pem檔案，請輸入show itl命令，後跟：
run sql select c.subjectname, c.serialnumber, c.ipv4address, t.name from
certificate as c, certificatetrustrolemap as r, typetrustrole as t where c.pkid =
r.fkcertificate and t.enum = r.tktrustrole
在國際交易日誌輸出中，需要查詢的主要錯誤有：
This etoken was not used to sign the ITL file.
和
Verification of the ITL file failed.
Error parsing the ITL file!!
先前的「結構化查詢語言(SQL)」查詢會搜尋具有「驗證與授權」角色的憑證。
上一個資料庫查詢中具有「驗證與授權」角色的CallManager.pem憑證也必須存在於「作業系統管理憑證管理」網頁中。
如果遇到上一個缺陷，則查詢中的CallManager.pem證書與作業系統網頁中的CallManager.pem證書不匹配。
更改主機名或域名
如果更改CUCM伺服器的主機名或域名，它將在該伺服器上一次重新生成所有證書。憑證重新產生一節說明，重新產生TVS.pem和CallManager.pem都是「壞事」。
有時，主機名更改會失敗，而有些則不會出現問題。本節涵蓋所有這些資訊，並將其連結回您已從本文檔瞭解的關於電視和國際交易日誌的內容。
僅具有ITL的單節點群集（請小心，此過程會中斷而不作準備）
- 使用Business Edition伺服器或僅發佈者部署，當您更改主機名時，CallManager.pem和TVS.pem都會同時重新生成。
- 如果在單個節點集群上更改主機名而未首先使用此處介紹的回滾企業引數，則電話無法對照其當前ITL檔案驗證新的ITL檔案或配置檔案。
- 電話無法連線到TVS，因為TVS證書不再受信任。
- 電話顯示有關「信任清單驗證失敗」的錯誤，新的配置更改不會生效，並且安全服務URL失敗。
- 如果不首先採取步驟2中的預防措施，唯一的解決辦法是手動刪除每台電話上的國際交易日誌。
具有CTL和ITL的單節點集群（可以暫時中斷，但易於修復）
- 執行完伺服器的重新命名之後，請重新執行CTL使用者端。這會將新的CallManager.pem證書放入電話下載的CTL檔案中。
- 根據CTL檔案中的CCM+TFTP功能，可以信任包括新ITL檔案的新配置檔案。
- 這之所以起作用，是因為更新的CTL檔案基於保持不變的USB eToken私鑰受信任。
僅具有ITL的多節點集群（這通常有效，但如果倉促完成則可能永久中斷）
- 由於多節點叢集有多個TVS伺服器，因此任何單一伺服器都可以順利重新產生其憑證。當電話出現此新的不熟悉的簽名時，它會要求另一台TVS伺服器驗證新的伺服器證書。
- 有兩個主要問題可能導致此操作失敗：
- 如果同時重新命名和重新引導所有伺服器，則當伺服器和電話恢復運行時，無法使用已知證書來訪問TVS伺服器。
- 如果電話在CallManager組中只有一個伺服器，則其他TVS伺服器不會有任何區別。請參閱「單節點集群」方案以解決此問題，或將另一台伺服器增加到電話CallManager組。
具有CTL和ITL的多節點集群（不能永久中斷）
- 執行重新命名之後，TVS服務會驗證新的憑證。
- 即使所有TVS伺服器因某種原因不可用，仍可使用CTL客戶端以新的CallManager.pem CCM+TFTP證書更新電話。
集中式TFTP
啟動帶有ITL的電話時，它會請求以下檔案：CTLSEP<MAC Address>.tlv、ITLSEP<MAC Address>.tlv和SEP<MAC Address>.cnf.xml.sgn。
如果電話找不到這些檔案，它會請求ITLFile.tlv 和CTLFile.tlv，這是中央TFTP伺服器提供給請求此類檔案的電話的。
使用集中式TFTP時，有一個TFTP集群指向許多其他子集群。
通常，這是因為多個CUCM集群上的電話共用相同的DHCP作用域，因此必須具有相同的DHCP Option 150 TFTP伺服器。
所有IP電話都指向中央TFTP集群，即使它們註冊到其他集群也是如此。每當收到找不到檔案的請求時，此中央TFTP伺服器就會查詢遠端TFTP伺服器。
由於這一操作，集中式TFTP只能在ITL同質環境中工作。
所有伺服器都必須運行CUCM 8.x版或更高版本，或者所有伺服器都必須運行8.x版之前的版本。
如果集中TFTP伺服器提供ITLFile.tlv，則電話不信任來自遠端TFTP伺服器的任何檔案，因為簽名不匹配。
這是異質的混合體造成的。在同質混合中，電話會請求ITLSEP<MAC>.tlv，後者是從正確的遠端集群中拉出的。
在混合使用版本8.x前和版本8.x集群的異構環境中，必須在8.x版本集群上啟用「準備集群以便回滾到版本8.0」，如思科漏洞ID CSCto87262中所述。
使用HTTP而不是HTTPS配置「安全電話URL引數」。這可以有效地停用電話上的國際交易日誌功能。
常見問題
我可以關閉SBD嗎？
您只能在SBD和ITL當前工作時關閉SBD。
使用Prepare Cluster for Rollback to pre 8.0」企業引數和使用HTTP而不是HTTPS配置「Secured Phone URL Parameters」可在電話上臨時停用SBD。
當您設定Rollback引數時，它將建立一個帶有空白函式條目的帶簽名的ITL檔案。
「空」的ITL檔案仍然被簽名，因此集群必須處於完全正常運行的安全狀態，才能啟用此引數。
啟用此引數並下載並驗證帶有空白條目的新ITL檔案後，無論誰簽署了該檔案，電話都會接受任何配置檔案。
不建議讓叢集保持此狀態，因為先前輸入的三個功能（驗證組態檔、加密組態檔和HTTPS URL）都無法使用。
CallManager.pem丟失後，能否從所有電話輕鬆刪除ITL檔案？
目前沒有從思科遠端提供的電話中刪除所有ITL的方法。正因如此，本文檔中介紹的過程和互動非常重要，需要加以考慮。
思科漏洞ID CSCto47052當前有一個未解析的增強功能請求此功能，但該功能尚未實現。
在此期間，透過思科漏洞ID CSCts01319增加了一項新功能，該功能可能會允許思科技術支援中心(TAC)恢復到之前受信任的ITL（如果伺服器上仍可使用該功能）。
這僅在某些情況下起作用，當集群使用具有此缺陷修復程式的版本，並且以前的交易日誌存在於儲存在伺服器上的特定位置的備份中。
檢視缺陷，看看您的版本是否有修正程式。請與Cisco TAC聯絡，以運行缺陷中介紹的潛在恢復過程。
如果不能使用以前的程式，則必須手動按電話上的電話按鈕，以便刪除國際交易日誌檔案。這是安全與易於管理之間的權衡。要使國際交易日誌檔案真正安全，就決不能輕易地從遠端將其刪除。
即使使用指令碼按鈕按下簡單對象訪問協定(SOAP) XML對象，也無法遠端刪除國際交易日誌。
這是因為此時無法使用TVS存取（因此也無法使用「安全驗證URL」存取來驗證內送的SOAP XML按鈕按下物件）。
如果驗證URL未配置為安全，則可以編寫用於刪除ITL的按鍵操作指令碼，但思科不提供此指令碼。
其他不使用身份驗證URL來編寫遠端按鍵的指令碼的方法可能由第三方提供，但這些應用程式不由思科提供。
刪除國際交易日誌最常用的方法是向所有電話使用者傳送電子郵件，告訴他們按鍵順序。
如果設定訪問設定為Restricted或Disabled，則電話需要出廠重置，因為使用者無權訪問電話的「設定」選單。
修訂記錄
| 修訂 | 發佈日期 | 意見 |
|---|---|---|
2.0 |
14-Jul-2023 |
重新認證 |
1.0 |
27-May-2013 |
初始版本 |
意見