The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This document describes how to identify whether the Certificate Authority (CA) signed certificate matches the existing Certificate Signing Request (CSR) for Cisco Unified Application Servers.
Cisco recommends that you have knowledge of X.509/CSR.
This document is not restricted to specific software and hardware versions.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
This document can also be used with these hardware and software versions:
Cisco Unified Communications Manager (CUCM)
Cisco Unified IM and Presence
Cisco Unified Unity Connection
Cisco Unified Contact Center Express (UCCX)
A certification request consists of a distinguished name, a public key, and an optional set of attributes collectively signed by the entity that request the certification. Certification requests are sent to a certification authority that transforms the request into an X.509 public-key certificate. In what form the certification authority returns the newly signed certificate is outside the scope of this document. A PKCS #7 message is one possibility.(RFC:2986).
The intention to include a set of attributes is twofold:
In order to provide other information about a given entity, or a challenge password by which the entity can later request certificate revocation.
In order to provide attributes for inclusion in X.509 certificates. The current Unified Communications (UC) servers do not support a challenge password.
Current Cisco UC servers require these attributes in a CSR as shown in this table:
location of organization
state of organization
country code can not be changed
alternate host name
When you support UC, you can encounter a lot of cases where the CA signed certificate fails to be uploaded on the UC servers. You cannot always identify what has occurred at the time of the creation of the signed certificate, since you are not the person who used the CSR in order to create the signed certificate. In most scenarios, re-signing a new certificate takes more than 24 hours. UC servers such as CUCM do not have detailed log/trace in order to assist in identifying why the certificate upload fails but they just give an error message. This article's intention is to narrow down the issue, whether it is a UC server or a CA issue.
General Practice for CA-Signed Certificates in CUCM
CUCM supports integration with third-party CAs with the use of a PKCS#10 CSR mechanism that is accessible at the Cisco Unified Communications Operating System Certificate Manager GUI. Customers, who currently use third-party CAs must use the CSR mechanism in order to issue certificates for Cisco CallManager, CAPF , IPSec, and Tomcat.
Step 1. Change the Identify before you generate the CSR.
The identity of the CUCM server in order to generate a CSR can be modified with the use of the command set web-security as shown in this image.
If you have space in the above fields, use “” in order to achieve the command as shown in the image.
Step 2. Generate CSR as shown in the image.
Step 3. Download the CSR and get it signed by the CA as shown in the image.
Step 4. Upload the CA-signed certificate to the server.
Once the CSR is generated and the certificate is signed and if you fail to upload it with an error message "Error reading the certificate" (as shown in this image), then you need to check whether the CSR is regenerated or whether the signed certificate itself is the cause of the issue.
There are three ways to check whether the CSR is regenerated or the signed certificate itself is the cause of the issue.
Solution 1. Use OpenSSL Command in root (or linux)
Step 1. Log in to the root and navigate to the folder as shown in the image.
Step 2. Copy the signed certificate to the same folder with Secure FTP (SFTP). If you are unable to set up an SFTP server, then the upload on the TFTP folder can also get the certificate onto the CUCM as shown in the image.
3. Check the MD5 for the CSR and the signed certificate as shown in the image.
Solution 2. Use Any SSL Certificate Key Matcher from Internet
Solution 3. Compare Content from Any CSR Decoder from Internet
Step 1. Copy the session Certificate Detailed Information for each as shown in this image.
Step 2. Compare them in a tool such as Notepad++ with the Compare plugin as shown in this image.