验证UC的CSR和证书不匹配

简介

本文档介绍如何确定证书颁发机构(CA)签名的证书是否与思科统一应用服务器的现有证书签名请求(CSR)匹配。

先决条件

要求

思科建议您了解X.509/CSR。

使用的组件

本文档不限于特定的软件和硬件版本。

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

相关产品

本文档也可用于以下硬件和软件版本：

• 思科统一通信管理器 (CUCM)
• 思科统一即时消息和在线状态
• 思科统一Unity Connection
• CUIS
• 思科媒体
• 思科统一联系中心快捷版(UCCX)

背景信息

认证请求由可分辨名称、公钥和由请求认证的实体共同签名的一组可选属性组成。认证请求被发送到将请求转换为X.509公钥证书的认证机构。证书颁发机构以何种形式返回新签名的证书不属于本文档的范围。  PKCS #7消息是一种可能。(RFC:2986)。

思科通信管理器证书管理

包含一组属性的意图是双重的：

• 为了提供关于给定实体的其他信息，或者提供挑战密码，该实体随后可以通过该密码请求证书撤销。
• 为了提供要包含在X.509证书中的属性。当前的统一通信(UC)服务器不支持质询密码。

当前Cisco UC服务器需要CSR中的以下属性，如下表所示：

信息	描述
组织	组织单位
组织名称	组织名称
位置	组织位置
状态	组织状态
国家	国家/地区代码无法更改
替代主机名	备用主机名

问题

当您支持UC时，可能会遇到许多CA签名证书无法上传到UC服务器的情况。由于您不是使用CSR创建签名证书的人，因此您无法始终确定在创建签名证书时发生了什么。在大多数情况下，重新签名新证书需要24小时以上。CUCM等UC服务器没有详细的日志/跟踪，无法帮助确定证书上传失败的原因，但它们只会提供错误消息。本文的目的是缩小问题范围，无论是UC服务器问题还是CA问题。

CUCM中CA签名证书的一般实践

CUCM支持使用PKCS#10 CSR机制与第三方CA集成，该机制可在思科统一通信操作系统证书管理器GUI中访问。当前使用第三方CA的客户必须使用CSR机制为Cisco CallManager、CAPF、IPSec和Tomcat颁发证书。

步骤1.在生成CSR之前更改标识。

使用如下图所示的命令set web-security可修改CUCM服务器的身份以生成CSR。

如果上述字段中有空格，请使用“”以实现如图所示的命令。

步骤2.生成CSR，如图所示。

步骤3.下载CSR，并使其由CA签名，如图所示。

步骤4.将CA签名的证书上传到服务器。

生成CSR并签名证书后，如果您上传时未显示错误消息“读取证书时出错”（如此图所示），则您需要检查CSR是否重新生成或签名的证书本身是否是问题的原因。

有三种方法可检查CSR是否重新生成或签名证书本身是问题的原因。

解决方案1.在根（或linux）中使用OpenSSL命令

步骤1.登录到根目录并导航至文件夹，如图所示。

步骤2.将签名证书复制到使用Secure FTP(SFTP)的同一文件夹。 如果无法设置SFTP服务器，则TFTP文件夹上的上传也可以将证书上传到CUCM，如图所示。

3.检查MD5中的CSR和签名证书，如图所示。

解决方案2.使用来自Internet的任何SSL证书密钥匹配程序

解决方案3.比较来自Internet的任何CSR解码器的内容

步骤1.复制每个会话的证书详细信息，如下图所示。

步骤2.在Notepad++等工具中将它们与此图中所示的“比较”插件进行比较。