使用CUCM在思科IP电话上配置LSC

下载选项

PDF (1.1 MB)
在各种设备上使用 Adobe Reader 查看
ePub (930.7 KB)
在 iPhone、iPad、Android、Sony Reader 或 Windows Phone 上使用各种应用查看
Mobi (Kindle) (815.1 KB)
在 Kindle 设备上查看或在多个设备上使用 Kindle 应用查看

已更新: 2021 年 4 月 6 日

文档 ID:213295

关于翻译

关于此翻译

思科采用人工翻译与机器翻译相结合的方式将此文档翻译成不同语言，希望全球的用户都能通过各自的语言得到支持性的内容。请注意：即使是最好的机器翻译，其准确度也不及专业翻译人员的水平。 Cisco Systems, Inc. 对于翻译的准确性不承担任何责任，并建议您总是参考英文原始文档（已提供链接）。

简介

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

先决条件

要求

Cisco 建议您了解以下主题：

思科统一通信管理器(CUCM)集群安全模式选项
X.509证书
制造安装证书(MIC)
LSCs
证书颁发机构代理功能(CAPF)证书操作
默认安全(SBD)
初始信任列表(ITL)文件

使用的组件

本文档中的信息基于支持SBD的CUCM版本，即CUCM 8.0(1)及更高版本。

注意：它还仅涉及默认支持安全(SBD)的电话。例如，7940和7960电话不支持SBD，7935、7936和7937会议电话也不支持SBD。有关在CUCM版本中支持SBD的设备列表，请导航至Cisco Unified Reporting > System Reports > Unified CM Phone Feature List并运行有关Feature的报告：默认情况下为安全。

本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始（默认）配置。如果您使用的是真实网络，请确保您已经了解所有命令的潜在影响。

背景信息

MIC与LSC

如果对802.1X或Anyconnect Phone VPN使用基于证书的身份验证，了解MIC和LSC之间的区别非常重要。

每部思科电话都出厂预装了MIC。此证书由思科制造CA、思科制造CA SHA2、CAP-RTP-001或CAP-RTP-002证书中的一个思科制造CA证书签名。当电话提供此证书时，它会证明它是有效的思科电话，但这不会验证电话是否属于特定客户或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，其中Certificate是CAPF，如图所示。

单击Common Name以打开“Certificate Details”页。检查有效性：和收件人：以确定证书到期时间，如图所示。

如果CAPF证书已过期或即将过期，请重新生成该证书。请勿在CAPF证书过期或即将过期的LSC安装过程中继续。这可避免由于CAPF证书过期而在不久的将来重新发布LSC。有关如何重新生成CAPF证书的信息，请参阅CUCM证书重新生成/续约流程文章。

同样，如果您需要让第三方证书颁发机构签署您的CAPF证书，您在此阶段可以选择。请立即完成证书签名请求(CSR)文件的生成和已签名的CAPF证书的导入，或使用自签名的LSC继续配置以进行初步测试。如果需要第三方签名的CAPF证书，则通常应先使用自签名的CAPF证书配置此功能，测试并验证，然后重新部署由第三方签名的LSC参与方签名的CAPF证书。如果第三方签名CAPF证书的测试失败，这可简化以后的故障排除。

警告：如果在激活和启动CAPF服务时重新生成CAPF证书或导入第三方签名的CAPF证书，CUCM会自动重置电话。如果电话可以重置，请在维护窗口中完成这些步骤。有关参考，请参阅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文件。另外，请确保不要命中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中的条目后，您可以在电话上完成证书操作。在本示例中，2048位RSA证书通过使用空字符串身份验证进行安装。

在电话上，验证LSC是否尚未安装，如图所示。例如，在79XX系列电话上，导航到设置> 4 — 安全配置> 4 - LSC。

打开电话的电话配置页面。导航至Cisco Unified CM管理>设备>电话。

在电话配置的CAPF信息部分输入以下详细信息，如图所示：

对于证书操作，选择安装/升级
对于身份验证模式，选择按空字符串
在本示例中，将Key Order、RSA Key Size(Bits)和EC Key Size(Bits)设置为系统默认值。
对于工序完成者，请输入至少为将来一小时的日期和时间。

保存配置更改，然后应用配置。

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

电话会生成如图所示的密钥。

电话重置，重置完成后，电话LSC状态将更改为Installed，如图所示。

如图所示，这也可在电话的状态消息下显示。

验证

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

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

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

故障排除

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

无有效 CAPF 服务器

LSC无法安装。电话的状态消息显示无有效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:失败。“电话配置”网页显示“证书操作状态：升级失败:用户发起的请求延迟/超时。这表示工序按时间和日期完成已过期或已过。请输入至少为将来一小时的日期和时间，然后重试证书操作。

LSC:操作挂起

LSC无法安装。电话的状态消息显示LSC:连接失败。电话配置页显示证书操作状态：操作挂起.可能看到证书操作状态的原因不同：操作挂起状态。其中一些可能包括：

电话上的ITL与混乱的TFTP服务器上当前使用的ITL不同。
ITL的腐败问题。当发生这种情况时，设备将失去其受信任状态，并且需要从CUCM发布服务器运行utils itl reset localkey命令，以强制电话现在使用ITLRecovery证书。如果集群处于混合模式，则需要使用命令utils ctl reset localkey。下面我们看到一个示例，说明在尝试从CUCM的CLI查看损坏的ITL时，您可能会看到什么。如果尝试查看ITL并尝试运行utils itl reset localkey命令时出现以下错误，但出现第二个错误，则可能是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)。请参阅下文，它仍显示“认证操作状态”：操作挂起.

在电话控制台日志中，在将查询转发到已配置的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:连接失败消息。

需要考虑的缺陷：

CSCub62243 - LSC安装间歇性失败，随后将冻结CAPF服务器

要考虑的增强缺陷：

CSCuz18034 — 需要报告LSC安装的终端以及到期状态