CUCM 证书重新生成/续约流程
下载选项
关于此翻译
思科采用人工翻译与机器翻译相结合的方式将此文档翻译成不同语言，希望全球的用户都能通过各自的语言得到支持性的内容。 请注意：即使是最好的机器翻译，其准确度也不及专业翻译人员的水平。 Cisco Systems, Inc. 对于翻译的准确性不承担任何责任，并建议您总是参考英文原始文档（已提供链接）。
目录
简介
本文档介绍如何重新生成Cisco Unified Communications Manager(CUCM)8.x版及更高版本中使用的证书。为避免发生任何意外中断，本文档还介绍了默认安全功能 (ITL) 和混合模式 (CTL)。例如，如何避免电话注册问题或不接受配置更改或固件的电话。
警告：始终建议在维护时段完成证书重新生成。
先决条件
要求
Cisco 建议您了解以下主题：
- CallManager
- CAPF（思科证书颁发机构代理功能)
- IPsec
- Tomcat
- TVS（信任验证服务）
- ITLRecovery（仅适用于 CUCM 10.X 及更高版本）
- phone-vpn-trust
- phone-sast-trust
- phone-trust
- phone-ctl-trust
- LSC（本地重要证书）
- MIC（制造商安装的证书）
使用的组件
本文档中的信息基于以下软件版本：
- CUCM版本9.1(2)SU2a,
- CUCM版本8.x及更高版本
本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始（默认）配置。如果您的网络处于活动状态，请确保您了解所有命令的潜在影响。
何时重新生成证书?
在 CUCM 中，全新安装后使用的大多数证书都是自签名证书，默认情况下颁发期限为五年。请注意，当前无法将五年时间范围修改为CUCM上的较短时间范围。但是，证书颁发机构 (CA) 几乎可以颁发任何时间范围的证书。
还有一些预先加载并且有效期更长的可信证书（例如 CAPF-trust 和 CallManager-trust）。例如，思科制造CA证书在CUCM信任商店上提供到特定功能，直到2029年才过期。
应在证书到期前重新生成证书。当证书即将到期时，您会在RTMT（系统日志查看器）中收到警告，并且如果已配置，会发送包含通知的电子邮件。
详细说明CUCM01.der证书在5月19日星期一14:46 在信任存储tomcat-trust上的服务器CUCM02上过期的证书过期通知示例如下所示：
At Fri Sep 05 02:00:56 CEST 2014 on node 192.168.1.2, the following
SyslogSeverityMatchFound events generated:
SeverityMatch : Critical
MatchedEvent : Sep 5 02:00:06 CUCM02 local7 2 : 864: CUCM02.localdomain:
Sep 05 2014 00:00:06.433 UTC : %UC_CERT-2-CertValidfor7days:
%[Message=Certificate expiration Notification. Certificate name:CUCM01.der
Unit:tomcat-trust Type:own-cert Expiration:Mon May 19 14:46:]
[AppID=Cisco Certificate Monitor][ClusterID=][NodeID=CUCM02]:
Alarm to indicate that Certificate has Expired or Expires in less than seven days
AppID : Cisco Syslog Agent
ClusterID :
NodeID : CUCM02
TimeStamp : Fri Sep 05 02:00:16 CEST 2014
如果服务证书(未标有 — trust的证书存储区)已过期，则仍可以重新生成这些证书。请注意，过期证书可能会影响 CUCM 功能，具体取决于集群的配置。下一部分将介绍相关注意事项。
证书库对服务的影响
在CUCM集群中更新所有证书对系统的良好功能至关重要。如果您的证书已过期或无效，则可能会严重影响系统的正常运行。此处显示了当任何特定证书无效或过期时可能遇到的潜在问题列表。影响的差异可能取决于您的系统设置。
CallManager.pem
- TFTP 不受信任（电话不接受签名的配置文件和/或 ITL 文件）。
- 电话服务可能会受到影响。
- 安全会话发起协议(SIP)中继或媒体资源(会议网桥、媒体终端点(MTP)、编码器等)不会注册或工作。
- AXL 请求失败。
Tomcat.pem
- 电话不能访问 CUCM 节点上托管的 HTTP 服务，例如企业目录。
- CUCM 的 Web GUI 问题，例如无法从集群中的其他节点访问服务页面。
- 分机移动性或跨集群分机移动问题。
- 如果集成了UCCX（统一联系中心快捷版），由于CCX 12.5的安全更改，需要在UCCX tomcat信任存储中上传CUCM Tomcat证书（自签名）或Tomcat根和中间证书（用于CA签名），因为它会影响Finesse桌面登录
CAPF.pem
- 电话无法向电话 VPN、802.1x 或电话代理进行身份验证。
- 无法为电话颁发 LSC 证书。
- 加密的配置文件无法工作。
IPSec.pem
- 灾难恢复系统 (DRS)/灾难恢复框架 (DRF) 可能无法正常工作。
- 与通往其他 CUCM 集群的网关 (GW) 之间的 IPsec 隧道无法工作。
信任验证服务(TVS)
电话无法对 HTTPS 服务进行身份验证。电话无法对配置文件进行身份验证（这几乎会对 CUCM 上的一切造成影响）。
phone-vpn-trust
电话VPN不工作，因为无法验证VPN的HTTPS URL。
注意：如果不存在这种情况也无需担心。这种情况仅适用于特定配置。
phone-sast-trust
以前的CTL/eToken无法更新或修改CTL。
注意：如果不存在这种情况也无需担心。这种情况仅适用于特定配置。
Phone-trust 和 phone-ctl-trust
使用Unity或Unity Connection的可视语音邮件不起作用。
注意：如果不存在这种情况也无需担心。这种情况仅适用于特定配置。
LSC和 MICs
电话不注册，电话不向电话VPN、电话代理或802.1x进行身份验证。
注意：在默认情况下，大多数电话型号上都有 MIC。LSC 则默认由 CAPF 签名，有效期为五年。CIPC（思科 IP Communicator）和 Jabber 等软件客户端未安装 MIC。
创建 DRS 备份
建议您在执行任何此类重大更改之前先创建一份 DRS 备份。CUCM DRF 备份将备份集群中的所有证书。所有DRS备份/恢复过程都可在《思科统一通信管理器灾难恢复系统管理指南》中找到。
注意:请记住Cisco Bug ID CSCtn50405 ,CUCM DRF Backup不备份证书。
确定混合模式
要确定您运行的是不是 CTL/安全/混合模式集群，请依次选择思科 Unified CM 管理 > 系统 > 企业参数 > 集群安全模式（0 == 非安全；1 == 混合模式）。
如果集群处于混合模式
如果您运行的 CUCM 集群处于混合模式，这意味着需要在所有证书更改后再更新 CTL 文件。思科的安全指南文档中介绍了有关如何执行此操作的程序。但是，请务必从混合模式功能的初始启动中至少有一个eToken，并且eToken密码已知。
注意：CTL的更新不会自动发生（在ITL文件中也会发生）。 而是需要由管理员使用 CTL 客户端或 CLI 命令手动完成。
在 CUCM 10.X 及更高版本中，您可以通过两种方式将集群设置为混合模式：
- CLI 命令 - 如果使用此方法，则会使用发布方服务器的 CallManager.pem 证书签署 CTL 文件。
admin:show ctl
The checksum value of the CTL file:
0c05655de63fe2a042cf252d96c6d609(MD5)
8c92d1a569f7263cf4485812366e66e3b503a2f5(SHA1)
Length of CTL file: 4947
The CTL File was last modified on Fri Mar 06 19:45:13 CET 2015
[...]
CTL Record #:1
----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 1156
2 DNSNAME 16 cucm-1051-a-pub
3 SUBJECTNAME 62 CN=cucm-1051-a-pub;OU=TAC;O=Cisco;L=Krakow;
ST=Malopolska;C=PL
4 FUNCTION 2 System Administrator Security Token
5 ISSUERNAME 62 CN=cucm-1051-a-pub;OU=TAC;O=Cisco;L=Krakow;
ST=Malopolska;C=PL
6 SERIALNUMBER 16 70:CA:F6:4E:09:07:51:B9:DF:22:F4:9F:75:4F:C5:BB
7 PUBLICKEY 140
8 SIGNATURE 128
9 CERTIFICATE 694 E9 D4 33 64 5B C8 8C ED 51 4D 8F E5 EA 5B 6D 21
A5 A3 8C 9C (SHA1 Hash HEX)
10 IPADDRESS 4
This etoken was used to sign the CTL file. - CLI 客户端 - 如果使用此方法，则会使用其中一个硬件 eToken 签署 CTL 文件。
admin:show ctl
The checksum value of the CTL file:
256a661f4630cd86ef460db5aad4e91c(MD5)
3d56cc01476000686f007aac6c278ed9059fc124(SHA1)
Length of CTL file: 5728
The CTL File was last modified on Fri Mar 06 21:48:48 CET 2015
[...]
CTL Record #:5
----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 1186
2 DNSNAME 1
3 SUBJECTNAME 56 cn="SAST-ADN008580ef ";ou=IPCBU;o="Cisco Systems
4 FUNCTION 2 System Administrator Security Token
5 ISSUERNAME 42 cn=Cisco Manufacturing CA;o=Cisco Systems
6 SERIALNUMBER 10 83:E9:08:00:00:00:55:45:AF:31
7 PUBLICKEY 140
9 CERTIFICATE 902 85 CD 5D AD EA FC 34 B8 3E 2F F2 CB 9C 76 B0 93
3E 8B 3A 4F (SHA1 Hash HEX)
10 IPADDRESS 4
This etoken was used to sign the CTL file.
注意：您可以在使用无令牌CTL的CUCM混合模式的方法之间移动。
根据您用于保护集群安全的方法，需要使用相应的 CTL 更新程序。重新运行 CTL 客户端，或从 CLI 输入 utils ctl update CTLfile 命令。
验证集群的默认安全设置
避免ITL问题非常重要，因为它可能导致许多功能失败或电话拒绝遵守对配置的任何更改。ITL问题可以通过这两种方式避免。
使用准备集群回滚到8.0之前的功能
此功能会在所有服务器上清除您的ITL，因此电话信任任何TFTP服务器。当此参数设置为True时，电话服务（例如分机移动）不起作用。但是，您可以继续拨打和接听基本电话。
注意：更改此参数会导致所有电话重置。
设置此功能后，所有TFTP服务器需要重新启动（以提供新ITL），所有电话都需要重置，以强制它们请求新的空ITL。完成证书更改并重新启动所有必需服务后，此功能可设置回False、TFTP服务重新启动和电话重置（以便电话可以获取有效的ITL文件）。 然后，所有功能都能像以前一样继续工作。
按特定顺序重新生成证书
以下程序可以从受信任的可用 TFTP 服务器为另一台 TFTP 服务器提供有效的/更新后的 ITL 文件。
- 在主 TFTP 服务器上停止 TFTP 服务。
- 更改主TFTP服务器的证书（根据需要）。
- 重置电话（以便从辅助 TFTP 服务器获取新的 ITL 文件）- 根据要重新生成的具体证书，此操作可能会自动完成。
- 电话返回后，启动主 TFTP 服务器的 TFTP 服务。
- 在辅助 TFTP 服务器上进行证书更改。
- 重置电话（以便从主 TFTP 服务器获取新的 ITL 文件）。
警告：请勿同时在两台 TFTP 服务器上编辑证书。这会让电话没有可信任的 TFTP 服务器，而需要本地管理员从所有电话上手动删除 ITL。
在 CUCM 中删除并重新生成证书
只能重新生成服务证书（未标有“-trust”的证书库）。信任库（标有“-trust”的证书库）中的证书无法重新生成，因此需要将其删除。
警告：请注意思科漏洞 ID 的 CSCut58407 - 删除 CAPF/CallManager/TVS-trust 时，不应重新启动设备。
完成所有证书修改后，需要重新启动各自的服务以接受更改。重新生成/删除证书后部分将对此进行介绍。
警告： 请注意思科漏洞 ID CSCto86463 - 删除的证书重新出现，无法从 CUCM 删除证书。在此问题中，已删除的证书不断在删除后重新出现。请按照缺陷解决方法操作。
通过 CLI 重新生成证书
警告：重新生成证书会触发集群内ITL文件的自动更新，从而触发集群范围的软电话重置，以允许电话触发其本地ITL的更新。这侧重于CAPF和CallManager证书重生，但可以与CUCM内的其他证书存储（如Tomcat）一起发生。
重新生成CAPF:CAPF 证书在重新生成后会自动将自身上传到 CAPF-trust 和 CallManager-trust。此外，CAPF 始终有一个唯一的“使用者名称”标题，因此以前使用的 CAPF 证书将保留并用于身份验证。
set cert regen CAPF
注意：如果CAPF证书过期，使用LSC的电话将无法注册到CUCM，因为CUCM拒绝其证书。不过，您仍然可以使用新的 CAPF 证书为电话生成新的 LSC。当您重新启动电话时，它会下载配置，然后联系 CAPF 以更新 LSC。更新 LSC 后，电话即可正常注册。只要新的 CAPF 证书在 ITL 文件中并且电话已下载和信任签署它的证书 (callmanager.pem)，此方法就可以奏效。
重新生成CallManager:CallManager 在重新生成后会自动将自身上传到 CallManager-trust。
set cert regen CallManager
重新生成IPsec:Ipsec 证书在重新生成后会自动将自身上传到 ipsec-trust。
set cert regen ipsec
重新生成Tomcat:Tomcat 证书在重新生成后会自动将自身上传到 tomcat-trust。
set cert regen tomcat
重新生成TVS:
set cert regen TVS
期望什么？
通过 CLI 重新生成证书时，系统会要求您验证此更改。输入yes，然后单击Enter。
admin:set cert regen CAPF
WARNING: This operation will overwrite any CA signed certificate previously imported
for CAPF
Proceed with regeneration (yes|no)? yes
Successfully Regenerated Certificate for CAPF.
You must restart services related to CAPF for the regenerated certificates to become active.
通过 CLI 删除证书
删除 CAPF-trust 证书
set cert delete CAPF <name of certificate>.pem
删除 CallManager-trust 证书
set cert delete CallManager <name of certificate>.pem
删除 ipsec-trust 证书
set cert delete ipsec <name of certificate>.pem
删除 Tomcat-trust 证书
set cert delete tomcat <name of certificate>.pem
删除 TVS-trust 证书
set cert delete TVS <name of certificate>.pem
通过 Web GUI 重新生成证书
重新生成CAPF:
CAPF 证书在重新生成后会自动将自身上传到 CAPF-trust 和 CallManager-trust。此外，CAPF 证书始终有一个唯一的“使用者名称”标题，因此以前使用的 CAPF 证书将保留并用于身份验证。
OS Admin > Security > Certificate Management > Find > Click CAPF certificate > Regenerate
重新生成CallManager:
重新生成后，CallManager证书会自动将自身上传到CallManager-trust。
OS Admin > Security > Certificate Management > Find > Click CallManager certificate > Regenerate
重新生成IPsec:
Ipsec 证书在重新生成后会自动将自身上传到 ipsec-trust。
OS Admin > Security > Certificate Management > Find > Click ipsec certificate > Regenerate
重新生成Tomcat:
Tomcat 证书在重新生成后会自动将自身上传到 tomcat-trust。
OS Admin > Security > Certificate Management > Find > Click tomcat certificate > Regenerate
重新生成TVS:
OS Admin > Security > Certificate Management > Find > Click TVS certificate > Regenerate
通过 Web GUI 删除证书
OS Admin > Security > Certificate Management > Find > Click X certificate within the
'-trust' store > Remove/Delete
重新生成/删除证书后
在证书库中删除或重新生成证书后，需要重新启动各自的服务以接受更改。
| 证书库 | 要重新启动的服务 | 如何 |
| Tomcat | Tomcat | CLI:utils service restart Cisco Tomcat 如果适用，请遵循CCX环境中所需的步骤 |
| CallManager | CallManager；TFTP;CTI管理器 | Web GUI:导航至Cisco Unified Serviceability > Tools > Control Center - Feature Services >(Select Server)。 在“Cisco CallManager”下，单击“Restart”。 Web Gui：导航至Cisco Unified Serviceability > Tools > Control Center - Feature Services >(Select Server)。 在“Cisco Tftp”下，单击“Restart”。 Web Gui：导航至Cisco Unified Serviceability > Tools > Control Center - Feature Services >(Select Server)。 在Cisco CTIManager下，单击“重新启动”。 |
| CAPF | CAPF（仅在发布方服务器上） | Web GUI:导航至Cisco Unified Serviceability > Tools > Control Center - Feature Services >(Select Server)。在“Cisco Certificate Authority Proxy Function”下，单击“Restart”。 |
| TVS | 信任验证服务（在相应的服务器上） | Web GUI:导航至Cisco Unified Serviceability > Tools > Control Center - Network Services >(Select Server)。 在“思科信任验证服务”下，单击“重新启动”。 |
| ipsec | 本地思科 DRF（在所有节点上）；主思科 DRF（在发布方服务器上） | CLI:实用服务重新启动本地思科 DRF CLI:实用服务重新启动主思科 DRF |
通过电话安装/更新 LSC
如果已重新生成 CAPF 证书，则需要以新 CAPF 证书签名的 LSC 来更新集群中所有电话的 LSC 证书。
- 导航至CUCM Serviceability > Service Activation。在发布方服务器上，激活思科 CTL 提供程序和思科证书颁发机构代理功能。
- 在CUCM CCMAdmin下，导航至Device > Phone。选择要在其中调配 LSC 的 IP 电话。
- 在Certificate Operation下的Device configuration页面中，导航至Install / Upgrade > By Null String。
- 在 CCMAdmin 中保存电话配置，然后选择应用配置。
如果电话安装 LSC 时遇到问题，请在电话上完成以下操作：
当电话重置时，在物理电话下导航至Settings >(6)Security Configuration >(4)LSC > **#（此操作将解锁GUI并允许我们继续下一步）> Update（更新在您执行上一步之前不可见）。 现在单击Submit。
请勿将任何证书分配给电话，除非它是无线电话 (7921/25)。 为了对自身进行身份验证，无线电话使用第三方证书颁发机构 (CA)。
结论
倘若您遇到问题或需要有关此程序的帮助，请联系思科技术支持中心 (TAC) 寻求帮助。在此情况下，请确保 DRF 备份可用，因为如果 TAC 无法通过其他方法恢复服务，它将用作恢复服务的最后手段。
反馈