在具有CUCM的IP電話上配置LSC

下載選項

  • PDF     (1.1 MB)
    在多種裝置上使用 Adobe Reader 檢視
  • ePub     (957.2 KB)
    在 iPhone、iPad、Android、Sony Reader 或 Windows Phone 上的各種應用程式中檢視
  • Mobi (Kindle)     (819.9 KB)
    在 Kindle 裝置或多部裝置的 Kindle 應用程式上檢視
已更新: 2023 年 3 月 17 日
文件 ID:213295

無偏見用語

本產品的文件集力求使用無偏見用語。針對本文件集的目的，無偏見係定義為未根據年齡、身心障礙、性別、種族身分、民族身分、性別傾向、社會經濟地位及交織性表示歧視的用語。由於本產品軟體使用者介面中硬式編碼的語言、根據 RFP 文件使用的語言，或引用第三方產品的語言，因此本文件中可能會出現例外狀況。深入瞭解思科如何使用包容性用語。

關於此翻譯

思科已使用電腦和人工技術翻譯本文件，讓全世界的使用者能夠以自己的語言理解支援內容。請注意，即使是最佳機器翻譯，也不如專業譯者翻譯的內容準確。Cisco Systems, Inc. 對這些翻譯的準確度概不負責，並建議一律查看原始英文文件（提供連結）。

    簡介

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

    必要條件

    需求

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

    • Cisco Unified Communications Manager(CUCM)集群安全模式選項
    • X.509憑證
    • 製造安裝證書(MIC)
    • LSC
    • 證書頒發機構代理功能(CAPF)證書操作
    • 預設安全性(SBD)
    • 初始信任清單(ITL)檔案

    採用元件

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

    註：它只適用於預設情況下支援安全(SBD)的電話。例如，7940和7960電話不支援SBD，7935、7936和7937會議電話也不支援。有關您的CUCM版本中支援SBD的裝置清單，請導航至Cisco Unified Reporting > System Reports > Unified CM Phone Feature List，然後運行功能報告：預設安全性。

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

    背景資訊

    MIC與LSC

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

    每部思科電話出廠時都預裝了MIC。此憑證由其中一個Cisco製造CA憑證簽署，包括Cisco製造CA、Cisco製造CA SHA2、CAP-RTP-001或CAP-RTP-002憑證。當電話提供此證書時，會證明它是有效的思科電話，但不會驗證電話是否屬於特定客戶或CUCM集群。它可能是在公開市場上購買或從其他站點帶來的流氓電話。

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

    設定

    網路拓撲

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

    • ao115pub - 10.122.138.102 - CUCM Publisher和TFTP伺服器
    • ao115sub - 10.122.138.103 - CUCM使用者和TFTP伺服器 

    確認CAPF證書尚未過期，並且在近期內不會過期。導覽至Cisco Unified OS Administration > Security > Certificate Management，然後導覽至Find Certificate List，其中Certificate正好是CAPF，如下圖所示。

    Certificate Name is Exactly CAPF

    按一下「Common Name」以開啟「Certificate Details」頁面。檢查Certificate File Data窗格中的Validity From：和To：日期，以確定證書到期時間，如下圖所示。

    Click Common Name to Open Certificate Details Page

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

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

    警告：如果在CAPF服務啟用和啟動時重新生成CAPF證書或匯入第三方簽名的CAPF證書，CUCM會自動重置電話。當電話可以重置時，請在維護視窗中完成這些步驟。有關參考，請參閱Cisco錯誤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 Subscriber 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檔案。此外，請確保未命中Cisco錯誤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。

    LSC Not Installed

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

    在電話配置的CAPF資訊部分輸入以下詳細資訊，如下圖所示：

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

    CAPF Install Upgrade

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

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

    LSC Pending

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

    Phone Generates Keys

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

    LSC Installed

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

    Status Messages - LSC Installed

    驗證

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

    要驗證多個電話上的LSC證書安裝，請參閱Cisco Unified Communications Manager版本11.0(1)安全指南的生成CAPF報告部分。或者，也可以使用按LSC狀態或身份驗證字串查詢電話過程，在CUCM管理Web介面中檢視相同的數據。

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

    疑難排解

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

    沒有有效的CAPF伺服器

    LSC無法安裝。電話的狀態消息顯示No valid CAPF server(無有效的CAPF伺服器)。這表明ITL檔案中沒有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：失敗。「電話配置」網頁顯示證書操作狀態：升級失敗：使用者發起請求延遲/超時。這表示工序完成時間和日期已到期或過去。請輸入至少將來1小時的日期和時間，然後重試證書操作。

    LSC：操作掛起

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

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

    Corrupt ITL

    Reset Local Key Error

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

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

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

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

    DNS Configuration

    已嘗試將LSC推送到實驗室中的某個電話(8845)。請注意，它仍顯示「Certificate Operation Status: Operation Pending（證書操作狀態：操作掛起）」。

    CAPF Operation Pending

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

    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：連線失敗消息。

    Status Messages

    要考慮的缺陷：

    思科錯誤ID CSCub6243 - LSC安裝間歇性失敗，然後凍結CAPF伺服器

    要考慮的增強缺陷：

    思科錯誤ID CSCuz18034 — 需要報告LSC安裝的終端以及到期狀態

    相關資訊

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

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

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

    修訂記錄

    修訂 發佈日期 意見
    2.0
    17-Mar-2023
    已更新標題、簡介、Alt文本、SEO、樣式要求、機器翻譯、德語和格式。已更正拼寫。
    1.0
    03-May-2018
    初始版本
    TAC Authored

    由思科工程師貢獻

    • Patrick Kinane
      Cisco TAC Engineer

    這份文件是否有所幫助？

    Feedback意見

    讓思科協助您