在使用CUCM的IP电话上配置LSC

简介

本文档介绍如何在Cisco Internet Protocol电话（Cisco 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会议电话也不支持SBD。有关您的CUCM版本中支持SBD的设备列表，请导航到思科统一报告>系统报告> Unified CM电话功能列表，并运行关于功能：默认安全的报告。

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

背景信息

思科授权代理功能(CAPF)服务仅在发布方节点上运行。发布者充当LSC的证书颁发机构(CA)或签署者。

MIC与LSC

如果对802.1X或AnyConnect电话VPN使用基于证书的身份验证，了解MIC和LSC之间的差异非常重要。

每部思科电话出厂时都预装了MIC。此证书由其中一个思科制造CA证书签署，由思科制造CA、思科制造CA SHA2、CAP-RTP-001或CAP-RTP-002证书签署。当电话提供此证书时，会证明它是有效的思科电话，但这不会验证电话是否属于特定客户或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 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自动重置电话。当电话可以重置时，请在维护窗口中完成以下步骤。有关参考，请参阅思科漏洞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输出的摘要。

注：此文件中有一个CAPF函数的ITL记录条目。

注意：如果您的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字符串身份验证安装2048位RSA证书。

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

打开电话的电话配置页面。导航到Cisco Unified CM Administration > Device > Phone。

将这些详细信息输入到电话配置的CAPF Information部分，如图所示：

• 对于证书操作，请选择Install/Upgrade。
• 对于身份验证模式，选择By Null String。
• 对于本示例，请将Key Order、RSA Key Size (Bits)和EC Key Size (Bits)设置为系统默认值。
• 对于工序完成时间，请输入日期和时间，此日期与时间至少相差一小时。

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

电话上的LSC状态更改为“待处理”，如图所示。

电话生成如图所示的按键。

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

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

验证

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

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

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

批量LSC安装

使用此部分将LC批量上传到相同型号的电话。

1. 导航到Bulk Administration > Phones > Update Phones > Query。
2. 查找设备类型包含<enter four digit model number>的电话，选择查找，然后选择下一步。
3. 滚动到证书颁发机构代理功能(CAPF)信息部分。
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： Connection Failed”。这可能表示以下情况之一：

• ITL文件中的CAPF证书与当前证书不匹配，CAPF服务正在使用中。
• CAPF服务已停止或停用。
• 电话无法通过网络到达CAPF服务。

验证CAPF服务是否已激活，重新启动CAPF服务，在启动时重新启动TFTP服务，重置电话以获取最新的ITL文件，然后重试证书操作。如果问题仍然存在，请从电话和CUCM发布方捕获数据包，然后进行分析，以查看端口3804（默认CAPF服务端口）上是否存在双向通信。否则，可能存在网络问题。

LSC：失败

LSC安装失败。电话的状态消息显示“LSC： Failed”。“Phone Configuration”网页显示“Certificate Operation Status： Upgrade Failed： User Initiated Request Late/Timedout”。这表示工序完成时间和日期已过期或过去。输入至少在一小时后到达的日期和时间，然后重试证书操作。

LSC：操作挂起

LSC安装失败。电话的状态消息显示“LSC： Connection Failed”。“电话配置”(Phone Configuration)页面显示“证书操作状态：操作挂起”(Certificate Operation Status： Operation Pending)。可以看到证书操作状态：操作挂起状态的原因有很多。其中一些挑战包括：

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

• 由于TVS故障，电话无法验证新LSC。
• 电话使用MIC证书，但电话配置页面上的“证书授权代理功能(CAPF)信息”(Certificate Authority Proxy Function， CAPF) Information部分的“身份验证模式”(Authentication Mode)已由“现有证书”(Existing Certificate)设置为（优先于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： Connection”（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