使用CUCM在IP电话上配置LSC

简介

本文档介绍如何在思科互联网协议电话（思科IP电话）上安装本地重要证书(LSC)。

先决条件

要求

Cisco 建议您了解以下主题：

• Cisco Unified Communications Manager(CUCM)集群安全模式选项
• X.509证书
• 制造安装证书(MIC)
• LSCs
• 证书颁发机构代理功能(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。此证书由其中一个思科制造CA证书签署，由思科制造CA、思科制造CA SHA2、CAP-RTP-001或CAP-RTP-002证书签署。当电话提供此证书时，会证明它是有效的Cisco电话，但这不会验证电话是否属于特定客户或CUCM集群。它可能是在公开市场上购买或从其他站点带来的非法电话。

另一方面，LSC由管理员有意安装在电话上，并由CUCM发布服务器的CAPF证书签名。您可以将802.1X或Anyconnect VPN配置为仅信任由已知CAPF证书颁发机构颁发的LSC。基于LSC而不是MIC进行证书身份验证可让您对受信任电话设备进行更精细的控制。

配置

网络拓扑

本文档使用了以下CUCM实验服务器：

• ao115pub - 10.122.138.102 - CUCM发布服务器和TFTP服务器
• ao115sub - 10.122.138.103 - CUCM用户和TFTP服务器 

确认CAPF证书尚未过期，并且在近期不会过期。导航到Cisco Unified OS Administration > Security > Certificate Management，然后导航到Find Certificate List，其中证书正好是CAPF，如图所示。

单击Common Name以打开Certificate Details页面。检查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 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 Bug 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部分，如图所示：

• 对于证书操作，请选择安装/升级
• 对于身份验证模式，选择By Null String
• 在本例中，将Key Order、RSA Key Size(Bits)和EC Key Size(Bits)设置为系统默认值。
• 对于“工序完成时间”，请输入至少在一小时之后的日期和时间。

保存配置更改，然后单击Apply Config。

电话上的LSC状态更改为“挂起”，如图所示。

电话生成如图所示的键。

电话重置，重置完成后，电话LSC状态将更改为“已安装”，如图所示。

如图所示，这也可显示在电话的Status Messages下。

验证

使用本部分可确认配置能否正常运行。

要验证多部电话上的LSC证书安装，请参阅Cisco Unified Communications Manager版本11.0(1)安全指南的生成CAPF报告部分。或者，您可以使用按LSC状态查找电话或身份验证字符串过程，在CUCM管理Web界面中查看相同的数据。

要获取电话中安装的LSC证书的副本，请参阅如何从Cisco IP电话检索证书文章。

故障排除

本部分提供了可用于对配置进行故障排除的信息。

无有效 CAPF 服务器

LSC安装失败。电话的Status Messages显示No valid CAPF server。这表明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：失败。“电话配置”网页显示证书操作状态：升级失败：用户发起请求延迟/超时。这表示工序完成时间和日期已过期或过去。请输入至少一小时之后的日期和时间，然后重试证书操作。

LSC：操作挂起

LSC安装失败。电话的状态消息显示LSC：连接失败。“电话配置”页显示证书操作状态：操作挂起。查看证书操作状态：操作暂挂状态的原因有多种种。其中可能包括：

• 电话上的ITL与混杂TFTP服务器上当前使用的ITL不同。
• ITL损坏的问题。发生这种情况时，设备会失去其受信任状态，并且需要从CUCM发布方运行utils reset localkey命令，强制电话现在使用ITLRecovery证书。如果集群处于混合模式，则需要使用命令utils ctl reset localkey。接下来，您将看到一个示例，说明您尝试从CUCM的CLI查看损坏的ITL时能看到的内容。如果您尝试查看ITL并尝试运行utils itl reset localkey命令时出现错误，但您看到第二个错误，则这可能是思科漏洞ID CSCus33755的缺陷。确认CUCM的版本是否受到影响。

• 由于TVS故障，电话无法验证新LSC。
• 电话使用MIC证书，但电话配置页面上的Certificate Authority Proxy Function(CAPF)Information部分的Authentication Mode已由Existing Certificate(Precedence to 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：连接失败消息。

要考虑的缺陷：

Cisco Bug 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