在使用CUCM的IP電話上配置LSC

簡介

本文說明如何在Cisco Internet Protocol電話（Cisco IP電話）上安裝本地重要證書(LSC)。

必要條件

需求

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

• 思科統一通訊管理器(CUCM)集群安全模式選項
• X.509憑證
• 製造安裝的證書(MIC)
• LSC
• 證書頒發機構代理功能(CAPF)證書操作
• 預設安全性(SBD)
• 初始信任清單(ITL)檔案

採用元件

本文檔中的資訊基於支援SBD的CUCM版本，即CUCM 8.0(1)及更高版本。

註：它僅適用於預設情況下支援安全性(SBD)的電話。例如，7940和7960電話不支援SBD，7935、7936和7937會議電話也不支援SBD。有關您的CUCM版本中支援SBD的裝置清單，請導航到思科統一報告>系統報告> Unified CM電話功能清單，並運行關於功能：預設安全的報告。

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

背景資訊

Cisco Authority Proxy Function (CAPF)服務僅在發佈伺服器節點上運行。發佈者充當證書頒發機構(CA)或LSC的簽名者。

MIC與LSC

如果您對802.1X或AnyConnect電話VPN使用基於證書的身份驗證，瞭解MIC和LSC之間的區別非常重要。

每部思科電話出廠時都預裝了麥克風。此證書由思科製造CA、思科製造CA SHA2、CAP-RTP-001或CAP-RTP-002證書中的一種思科製造CA證書簽署。當電話提供此證書時，將證明它是有效的思科電話，但無法驗證電話是否屬於特定客戶或CUCM集群。它可能是在公開市場上購買或從其他站點引入的流氓電話。

另一方面，LSC是由管理員有意安裝在電話上，並由CUCM發佈者的CAPF證書簽名。您可以將802.1X或AnyConnect VPN配置為僅信任由已知CAPF證書頒發機構頒發的LSC。基於LSC而非MIC進行證書身份驗證可以更精細地控制哪些電話裝置受信任。

設定

網路拓撲

本文檔使用了以下CUCM實驗伺服器：

• CUCM發佈伺服器和TFTP伺服器
• CUCM使用者和TFTP伺服器 

驗證CAPF證書是否尚未過期，也不打算在不久的將來過期。導覽至Cisco Unified OS Administration > Security > Certificate Management，然後導覽至Find Certificate List where Certificate is exactly CAPF，如下圖所示。

按一下公用名以打開「證書詳細資料」頁。檢查Certificate File Data 窗格中的「Validity From：」和「To：」日期，以確定證書何時過期，如下圖所示。

如果CAPF證書已過期或即將過期，請重新生成該證書。請勿在CAPF證書過期或即將過期時繼續執行LSC安裝過程。這避免了由於CAPF證書到期而在近期內重新發佈LSC的需要。有關如何重新生成CAPF證書的資訊，請參閱CUCM證書重新生成/續訂流程文章。

同樣，如果您需要由第三方證書頒發機構簽署CAPF證書，則可以在此階段進行選擇。請立即完成證書簽名請求(CSR)檔案的生成並導入簽名的CAPF證書，或者繼續使用自簽名LSC進行配置以進行初步測試。 如果您需要第三方簽署的CAPF證書，通常最好先使用自簽名CAPF證書配置此功能，然後測試和驗證，然後重新部署由第三方簽署的CAPF證書簽名的LSC。如果與第三方簽署的CAPF證書的測試失敗，這將簡化以後的故障排除。

警告：如果在CAPF服務啟用和啟動時重新生成CAPF證書或導入第三方簽名的CAPF證書，CUCM將自動重置電話。如果可以重置電話，請在維護窗口中完成以下步驟。有關詳情，請參閱Cisco bug ID CSCue55353 -在重新生成電話重置的TVS/CCM/CAPF證書時增加警告

註：如果您的CUCM版本支援SBD，則無論CUCM集群是否設定為混合模式，此LSC安裝過程均適用。SBD是CUCM 8.0(1)及更高版本的一部分。在這些版本的CUCM中，ITL檔案包含CUCM發佈器上CAPF服務的證書。這允許電話連線到CAPF服務以支援證書操作，如安裝/升級和故障排除。

在CUCM的早期版本中，必須配置混合模式的集群以支援證書操作。由於不再需要此功能，因此可以減少LSC作為802.1X身份驗證或AnyConnect VPN客戶端身份驗證的電話身份證書使用的障礙。

在CUCM集群的所有TFTP伺服器上運行show itl命令。請注意，ITL檔案確實包含CAPF證書。

例如，以下內容摘自實驗CUCM使用者ao115sub的show itl輸出。

註：此檔案中有一個ITL記錄條目，其功能為CAPF。

註：如果您的ITL檔案沒有CAPF條目，請登入CUCM發佈者並確認已啟用CAPF服務。要進行確認，請導航到Cisco Unified Serviceability > Tools > Service Activation > CUCM Publisher > Security，然後啟用Cisco Certificate Authority Proxy Function Service。如果服務已取消啟用而您剛剛將其啟用，請導航到Cisco Unified Serviceability > Tools > Control Center - Feature Services > Server > CM Services，然後重新啟動CUCM集群中所有TFTP伺服器上的Cisco TFTP服務以重新生成ITL檔案。另外，請確保您未命中思科漏洞ID CSCuj78330。

注意：完成後，在CUCM集群的所有TFTP伺服器上運行show itl命令，以驗證當前CUCM發佈方CAPF證書是否已包含在該檔案中。

 ITL Record #:1
 ----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 727
2 DNSNAME 2
3 SUBJECTNAME 64 CN=CAPF-7f0ae8d7;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
4 FUNCTION 2 CAPF
5 ISSUERNAME 64 CN=CAPF-7f0ae8d7;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
6 SERIALNUMBER 16 64:F2:FE:61:3B:79:C5:D3:62:E2:6D:AB:4A:8B:76:1B
7 PUBLICKEY 270
8 SIGNATURE 256
11 CERTHASH 20 C3 E6 97 D0 8A E1 0B F2 31 EC ED 20 EC C5 BC 0F 83 BC BC 5E
12 HASH ALGORITHM 1 null

 ITL Record #:2
 ----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 717
2 DNSNAME 2
3 SUBJECTNAME 59 CN=ao115pub;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
4 FUNCTION 2 TVS
5 ISSUERNAME 59 CN=ao115pub;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
6 SERIALNUMBER 16 6B:99:31:15:D1:55:5E:75:9C:42:8A:CE:F2:7E:EA:E8
7 PUBLICKEY 270
8 SIGNATURE 256
11 CERTHASH 20 05 9A DE 20 14 55 23 2D 08 20 31 4E B5 9C E9 FE BD 2D 55 87
12 HASH ALGORITHM 1 null

 ITL Record #:3
 ----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 1680
2 DNSNAME 2
3 SUBJECTNAME 71 CN=ITLRECOVERY_ao115pub;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
4 FUNCTION 2 System Administrator Security Token
5 ISSUERNAME 71 CN=ITLRECOVERY_ao115pub;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
6 SERIALNUMBER 16 51:BB:2F:1C:EE:80:02:16:62:69:51:9A:14:F6:03:7E
7 PUBLICKEY 270
8 SIGNATURE 256
9 CERTIFICATE 963 DF 98 C1 DB E0 61 02 1C 10 18 D8 BA F7 1B 2C AB 4C F8 C9 D5 (SHA1 Hash HEX)
This etoken was not used to sign the ITL file.

 ITL Record #:4
 ----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 717
2 DNSNAME 2
3 SUBJECTNAME 59 CN=ao115sub;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
4 FUNCTION 2 TVS
5 ISSUERNAME 59 CN=ao115sub;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
6 SERIALNUMBER 16 65:E5:10:72:E7:F8:77:DA:F1:34:D5:E3:5A:E0:17:41
7 PUBLICKEY 270
8 SIGNATURE 256
11 CERTHASH 20 00 44 54 42 B4 8B 26 24 F3 64 3E 57 8D 0E 5F B0 8B 79 3B BF
12 HASH ALGORITHM 1 null

 ITL Record #:5
 ----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 1652
2 DNSNAME 2
3 SUBJECTNAME 59 CN=ao115sub;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
4 FUNCTION 2 System Administrator Security Token
5 ISSUERNAME 59 CN=ao115sub;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
6 SERIALNUMBER 16 48:F7:D2:F3:A2:66:37:F2:DD:DF:C4:7C:E6:B9:CD:44
7 PUBLICKEY 270
8 SIGNATURE 256
9 CERTIFICATE 959 20 BD 40 75 51 C0 61 5C 14 0D 6C DB 79 E5 9E 5A DF DC 6D 8B (SHA1 Hash HEX)
This etoken was used to sign the ITL file.

 ITL Record #:6
 ----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 1652
2 DNSNAME 2
3 SUBJECTNAME 59 CN=ao115sub;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
4 FUNCTION 2 TFTP
5 ISSUERNAME 59 CN=ao115sub;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
6 SERIALNUMBER 16 48:F7:D2:F3:A2:66:37:F2:DD:DF:C4:7C:E6:B9:CD:44
7 PUBLICKEY 270
8 SIGNATURE 256
9 CERTIFICATE 959 20 BD 40 75 51 C0 61 5C 14 0D 6C DB 79 E5 9E 5A DF DC 6D 8B (SHA1 Hash HEX)

 ITL Record #:7
 ----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 1031
2 DNSNAME 9 ao115sub
3 SUBJECTNAME 62 CN=ao115sub-EC;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
4 FUNCTION 2 TFTP
5 ISSUERNAME 62 CN=ao115sub-EC;OU=TAC;O=Cisco Systems;L=Boxborough;ST=MA;C=US
6 SERIALNUMBER 16 53:CC:1D:87:BA:6A:28:BD:DA:22:B2:49:56:8B:51:6C
7 PUBLICKEY 97
8 SIGNATURE 103
9 CERTIFICATE 651 E0 CF 8A B3 4F 79 CE 93 03 72 C3 7A 3F CF AE C3 3E DE 64 C5 (SHA1 Hash HEX)

The ITL file was verified successfully.

CAPF條目在ITL中被確認為條目，您就可以在電話上完成證書操作。在本示例中，使用Null String身份驗證安裝2048位RSA證書。

在電話上，驗證是否尚未安裝LSC，如圖所示。例如，在79XX系列電話上，導航到設定> 4 -安全配置> 4 - LSC。

打開電話的電話配置頁面。導航到Cisco Unified CM管理>裝置>電話。

將這些詳細資訊輸入到電話配置的CAPF Information部分，如圖所示：

• 對於證書操作，請選擇Install/Upgrade。
• 對於身份驗證模式，選擇By Null String。
• 對於此示例，請將Key Order、RSA Key Size (Bits)和EC Key Size (Bits)設定為系統預設值。
• 對於「工序完成時間」，輸入至少一個小時的日期和時間。

儲存配置更改，然後應用配置。

電話上的LSC狀態更改為「掛起」，如圖所示。

電話生成如圖所示的按鍵。

電話重置，當重置完成時，電話LSC狀態將更改為「已安裝」，如圖所示。

此圖示也顯示在電話的「Status Messages（狀態消息）」下，如圖所示。

驗證

使用本節內容，確認您的組態是否正常運作。

要驗證多個電話上的LSC證書安裝，請參閱Cisco統一通訊管理器版本11.0(1)安全指南的生成CAPF報告部分。或者，您可以使用按LSC狀態或身份驗證字串查詢電話程式，在CUCM管理Web介面中檢視相同的資料。

要獲取安裝在電話中的LSC證書的副本，請參閱如何從Cisco IP電話檢索證書文章。

批次LSC安裝

使用此部分可將LCS批次上傳到相同型號的電話。

1. 導航到Bulk Administration > Phones > Update Phones > Query。
2. 查詢裝置型別包含<輸入四位數型號編號>的電話。選擇查詢，然後選擇下一步。
3. 滾動到Certification Authority Proxy Function (CAPF) Information部分。
4. 在下拉部分中，選擇Install/Upgrade。

使用批次管理並選擇身份驗證模式時，身份驗證模式必須與電話安全配置檔案的操作匹配。  如果存在不匹配，例如，By Null String in Bulk和By Existing Certificate (Precedence to LSC) in Phone Security Profile，則操作無法完成。

檢查電話安全配置檔案和身份驗證模式，確保您使用的是正確的模式。

按LSC優先順序的LSC

要設定批次配置，請在下拉選單中，選擇與電話安全配置檔案匹配的身份驗證模式。

大量選取

如果更改電話安全配置檔案身份驗證模式，則需要使用Save，然後Apply配置。  這可能導致使用特定電話安全配置檔案的那些裝置重新啟動。

身份驗證選擇

疑難排解

本節提供的資訊可用於對組態進行疑難排解。

沒有有效的CAPF伺服器

LSC無法安裝。電話的狀態消息顯示「No valid CAPF server」（沒有有效的CAPF伺服器）。這表明國際交易日誌檔案中沒有CAPF條目。驗證CAPF服務是否已啟用，然後重新啟動TFTP服務。重啟後，驗證ITL檔案是否包含CAPF證書，重置電話以選擇最新的ITL檔案，然後重試證書操作。如果電話安全設定選單中的CAPF伺服器條目顯示為主機名或完全限定域名，請確認電話能夠將該條目解析為IP地址。

LSC：連線失敗

LSC無法安裝。電話的狀態消息顯示「LSC：連線失敗」。這可能表示以下情況之一：

• 由於ITL檔案中的CAPF證書與當前證書不匹配，CAPF服務正在使用中。
• CAPF服務已停止或停用。
• 電話無法通過網路訪問CAPF服務。

驗證CAPF服務是否已啟用，重新啟動CAPF服務，在啟動時重新啟動TFTP服務，重置電話以接收最新的ITL檔案，然後重試證書操作。如果問題仍然存在，請從電話和CUCM發佈方捕獲資料包，並進行分析，以檢視埠3804（預設CAPF服務埠）上是否存在雙向通訊。如果不是，則可能存在網路問題。

LSC：失敗

LSC無法安裝。電話的狀態消息顯示「LSC：失敗」。「Phone Configuration」網頁顯示「Certificate Operation Status： Upgrade Failed： User Initiated Request Late/Timedout」。這表示「作業完成者」的時間與日期已過期或過去。請輸入至少一小時之後的日期和時間，然後重試證書操作。

LSC：作業擱置

LSC無法安裝。電話的狀態消息顯示「LSC：連線失敗」。電話「配置」頁面顯示「證書操作狀態：操作掛起」。檢視證書操作狀態：操作掛起狀態的原因有很多。其中一些包括：

• 電話上的ITL與配置的TFTP伺服器上當前使用的ITL不同。
• 國際交易日誌的腐敗問題。當發生這種情況時，裝置將失去其受信任狀態，並且需要從CUCM發佈伺服器運行utils reset localkey命令，以強制電話現在使用ITLRecovery證書。如果集群處於混合模式，則需要使用命令utils ctl reset localkey。接下來，您將看到一個示例，說明嘗試從CUCM的CLI檢視已損壞的ITL時可以看到的內容。如果在您嘗試檢視ITL並嘗試運行utils itl reset localkey命令時出現錯誤，但您看到第二個錯誤，則這可能是思科漏洞ID CSCus33755的缺陷。確認CUCM的版本是否受到影響。

• 由於TVS故障，電話無法驗證新LSC。
• 電話使用MIC證書，但「電話配置」頁面上的「證書頒發機構代理功能(CAPF)資訊」部分的「身份驗證模式」被現有證書（優先於LSC）設定為。
• 電話無法解析CUCM的FQDN。

對於最後一個方案，實驗室環境設定為模擬電話無法解析CUCM FQDN時您在日誌中看到的內容。目前，本實驗使用以下伺服器進行設定：

• 運行11.5.1.15038-2版的CUCM發佈伺服器和訂閱伺服器
• Windows 2016 Server設定為我的DNS伺服器

對於測試，沒有為PUB11 CUCM伺服器配置DNS條目。

嘗試將LSC推送到實驗室中的其中一個電話(8845)。請參閱它仍然顯示「Certificate Operation Status： Operation Pending」。

在電話控制檯日誌中，檢視電話在轉發查詢到配置的DNS伺服器地址之前嘗試查詢其本地快取(127.0.0.1)。

0475 INF Mar 12 15:07:53.686410 dnsmasq[12864]: query[A] PUB11.brianw2.lab from 127.0.0.1
0476 INF Mar 12 15:07:53.686450 dnsmasq[12864]: forwarded PUB11.brianw2.lab to X.X.X.X
0477 INF Mar 12 15:07:53.694909 dnsmasq[12864]: forwarded PUB11.brianw2.lab to X.X.X.X
0478 INF Mar 12 15:07:53.695263 dnsmasq[12864]: reply PUB11.brianw2.lab is NXDOMAIN-IPv4
0479 INF Mar 12 15:07:53.695833 dnsmasq[12864]: query[A] PUB11.brianw2.lab from 127.0.0.1
0480 INF Mar 12 15:07:53.695865 dnsmasq[12864]: cached PUB11.brianw2.lab is NXDOMAIN-IPv4
0481 WRN Mar 12 15:07:53.697091 (12905:13036) JAVA-configmgr MQThread|NetUtil.traceIPv4DNSErrors:? - DNS unknown IPv4 host PUB11.brianw2.lab

++ However, we see that the phone is not able to resolve the FQDN of the CUCM Publisher. This is because we need to configure the DNS entry for PUB11 on our DNS server.

0482 ERR Mar 12 15:07:53.697267 (12905:13036) JAVA-configmgr MQThread|cip.sec.TvsProperty:? - Failed to resolve Tvs Ipv4 Address with hostname PUB11.brianw2.lab

++ Afterwards, we see the CAPF operation fail. This is expected because we do not have a DNS mapping for PUB11. 

0632 NOT Mar 12 15:07:55.760715 (12905:13036) JAVA-configmgr MQThread|cip.sec.CertificateProperty:? - CertificateProperty.setCertificate() authMode=CAPF_AUTH_MODE_NULL_STR authorizationString=null theReason=CAPF_REASON_AUTO
0633 NOT Mar 12 15:07:55.761649 (322:17812) SECUREAPP-RCAPF_START_MODE: Start CAPF - mode:[1]([NULL_STR]), reason:[1]([AUTO]) no auth-str
0634 NOT Mar 12 15:07:55.761749 (322:17812) SECUREAPP-CAPF_CLNT_INIT:CAPF clnt initialized
0635 NOT Mar 12 15:07:55.761808 (322:17812) SECUREAPP-CAPFClnt: SetDelayTimer - set with value <0>
0636 ERR Mar 12 15:07:55.761903 (322:17812) SECUREAPP-Sec create BIO - invalid parameter.
0637 ERR Mar 12 15:07:55.761984 (322:17812) SECUREAPP-SEC_CAPF_BIO_F: CAPF create bio failed
0638 ERR Mar 12 15:07:55.762040 (322:17812) SECUREAPP-SEC_CAPF_OP_F: CAPF operation failed, ret -7
0639 CRT Mar 12 15:07:55.863826 (12905:13036) JAVA-configmgr MQThread|cip.sec.CertificateProperty$1:? - LSC: Connection failed

++ What we would expect to see is something similar to the following where DNS replies with the IP address that is associated with the FQDN of CUCM. After configuring a AAAA record in DNS for PUB11, we now see the below result in the console logs.

4288 INF Mar 12 16:34:06.162666 dnsmasq[12864]: query[A] PUB11.brianw2.lab from 127.0.0.1
4289 INF Mar 12 16:34:06.162826 dnsmasq[12864]: forwarded PUB11.brianw2.lab to X.X.X.X
4290 INF Mar 12 16:34:06.164908 dnsmasq[12864]: reply PUB11.brianw2.lab is X.X.X.X
4291 NOT Mar 12 16:34:06.165024 (12905:13036) JAVA-configmgr MQThread|cip.sec.TvsProperty:? - Resolve Tvs Ipv4 Address to X.X.X.X from hostname PUB11.brianw2.lab

請參閱電話狀態消息中的電話無法解析PUB11.brianw2.lab。隨後顯示「LSC：連線」失敗消息。

要考慮的缺陷：

思科漏洞ID CSCub62243 - LSC安裝間歇性失敗，然後凍結CAPF伺服器。

要考慮的增強功能缺陷：

思科漏洞ID CSCuz18034 -需要針對已安裝LSC的終端以及到期狀態進行報告。

相關資訊

這些檔案提供了有關在AnyConnect VPN客戶端身份驗證和802.1X身份驗證的上下文中使用LSC的詳細資訊。

• AnyConnect VPN電話- IP電話、ASA和CUCM故障排除
• 基於身份的網路服務：啟用IEEE 802.1X的網路中的IP電話部署和配置指南

還有一種高級型別的LSC配置，其中LSC證書由第三方證書頒發機構直接簽署，而不是CAPF證書。

有關詳細資訊，請參閱CUCM第三方CA簽署LSC生成和導入配置示例

• 技術支援與文件 - Cisco Systems