04-30-2020 06:45 AM - edited 09-18-2024 01:09 AM
Unified Communication system uses self-signed and third-party-signed certificates. Certificates are used between devices in the system to securely authenticate devices, encrypt data, and hash the data to ensure its integrity from source to destination. When a system trusts a certificate, this means that there is a preinstalled certificate on your system which states it is fully confident that it shares information with the correct destination. Otherwise, it terminates the communication between these points. In order to trust a certificate, trust must already be established with a third-party certificate authority (CA). The devices must know that they can trust both the CA and intermediate certificates before they can trust the server certificate presented by the exchange of messages called the secure sockets layer (SSL) handshake.
Name | Description | Multi-Server support | Related service |
tomcat |
This self-signed root certificate is generated during installation for the HTTPS node. | Yes | Tomcat and TFTP |
ipsec | This self-signed root is generated during isntallation for IPsec connection with MGCP and H.323 gateways. | No | Cisco Disaster recovery system (DRS) Local and Cisco DRF Master |
CallManager |
This self-signed root is installed automatically when you install Cisco Unified Communication Manager. this certificate provide node identification, including the node name and the global unique identifier (GUID). | Yes | CallManager, CAPF and CTI |
CAPF | The system copies this root certificate to your node or to all nodes in the cluster after you complete the Cisco client configuration. | No | CallManager and CAPF |
TVS | This is a self-signed root certificate. | No | Trust Verification Service (TVS) |
ITLRecovery | This certificate is used when devices lose their trusted status | No | Trust Verification Service (TVS) |
cup-xmpp |
Presented to a Cisco Jabber client, Third-Party XMPP client, or a CAXL based application when the XMPP session is being created. |
Yes |
Cisco XCP Connection Manager, Cisco XCP Web Connection Manager, Cisco XCP Directory service and Cisco XCP Router service |
cup-xmpp-s2s | Presented for XMPP interdomain federation when connecting to externally federated XMPP systems | No | Cisco XCP XMPP Federation Connection Manager |
cup | Used for internal server communication. | No |
Cisco SIP Proxy and Cisco Presence Engine |
AUTHZ | Used for Keys for OAuth Refresh Logins | No |
|
In general the same applies to UC systems version 8.x and 9.x, besides that these do not support multi SAN certificates, so each server needs it's own CA signed certificate.
Warning:
DO NOT regenerate CallManager and TVS certificates at the same time. This will cause an unrecoverable mismatch to the installed ITL on the phone to the newly generated ITL in CUCM causing the need to remove the ITL from ALL phones in the cluster.
Note:
* When regenerating certificates, it is advised that this action be performed after hours due to the needs of restarting services and rebooting all phones in the cluster.
** Monitor phone registration through RTMT tool.
*** Check Relevant Certificates Procedure as per UC nodes for CUC/CUPS/UCCX
To regenerate expiring or expired certificates please follow the procedures below.
Note: This certificate will only need to be regenerated on the publisher since it is pushed to all the nodes.
Specific note for UCCX:
When updating the Tomcat certificate in CUCM it has to be uploaded to the tomcat-trust store in UCCX if the version of UCCX is 12.5 or newer as it it effect Finesse desktop logins. If the certificate is signed by a CA the corresponding certificates for the root and if applicable intermediate certificate(s) also needs to be uploaded to the tomcat-trust store.
Make sure services are not restarted on all nodes simultainiously as that will disrupt services. Recommended to do the restart of services with a gap of minimum 15 minutes between nodes. Disregard the part with disable and re-enable SSO. This is not required.
If SSO is used the below needs to be done after Tomcat certificate has been renewed.
Warning:
DO NOT regenerate CallManager and TVS certificates at the same time. This will cause an unrecoverable mismatch to the installed ITL on the phone to the newly generated ITL in CUCM causing the need to remove the ITL from ALL phones in the cluster. A reboot of ALL phone will be required after the regeneration of CallManager certificate.
Note: This certificate will only need to be regenerated on the publisher since it is pushed to all the nodes.
Make sure services are not restarted on all nodes simultaneously as that will disrupt services. Recommended to do the restart of services with a gap of minimum 15 minutes between nodes.
Note: IPSEC certificates will affect the DRF master and local service witch deals with backup and restore.
Note:
The ITLRecovery Certificate is used when devices lose their trusted status. The certificate appears in both the ITL and CTL (when CTL provider is active).
If devices lose their trust status, you can use the command utils itl reset localkey for non-secure clusters and the command utils ctl reset localkey for mix-mode clusters. Read the Security guide for your Call Manager version to become familiar with how the ITLRecovery certificate is used and the process required to recover trusted status.
If the cluster has been upgraded to a version that supports a key length of 2048 and the clusters server certificates have been regenerated to 2048 and the ITLRecovery has not been regenerated and is currently 1024 key length, the ITL recovery command will fail and the ITLRecovery method will not be able to be used.
Note: Ensure the cluster is not in Secure or Mixed Mode.
Check if the cluster is in secure cluster mode.
Warning:
DO NOT regenerate CallManager and TVS certificates at the same time. This will cause an unrecoverable mismatch to the installed ITL on the phone to the newly generated ITL in CUCM causing the need to remove the ITL from ALL phones in the cluster. A reboot of ALL phone will be required after the regeneration of TVS certificate.
Note:
Presented to a Cisco Jabber client, Third-Party XMPP client, or a CAXL based application when the XMPP session is being created.
The associated trust-store is used to verify connections made by Cisco XCP Directory service in performing LDAP search operations for third-party XMPP clients.
The associated trust-store is used by the Cisco XCP Router service when establishing secure connections between IM and Presence Service servers if the Routing Communication Type is set to Router-to-Router.
This certificate will only need to be regenerated on the publisher since this certificate is pushed to all the nodes.
Make sure the below is selected.
For example altNames:
usdecups02.domain.com (dNSName)
domain.com (dNSName)
usdecups01.domain.com (dNSName)
Redo step 3 from first section to view the new certificate and verify the expiration has changed to the new date.
After all nodes have received the signed cup-xmpp certificate, the following services needs to be restarted in the following order:
Make sure services are not restarted on all nodes simultaneously as that will disrupt services. Recommended to do the restart of services with a gap of minimum 15 minutes between nodes.
If you encounter an error when you attempt to access Unified Communications Manager services from an IM and Presence Service node or IM and Presence Service functionality from a Unified Communications Manager node, the source of the issue is the tomcat-trust certificate. The error message Connection to the Server cannot be established (unable to connect to Remote Node) appears on the following Serviceability interface windows:
Use this procedure to help you resolve the certificate error. Start with the first step and proceed, if necessary. Sometime, you may only have to complete the first step to resolve the error; in other cases, you have to complete all the steps.
Hi Roger,
Great document. Thank you for putting this together. It's so much easier for us all to have a single go to reference for cert related information like this.
Thanks Ayodeji,
Appreciate your comment.
Hello Roger,
That’s a great post, thank you for collecting all this info in one piece!
George
Your welcome George. Glad you found it useful.
Dear Roger, Appreciate the details you covered in this post. It will be really helpful for all. Thanks. :)
Your welcome Sunny. Glad it was of use to you.
Very fantastic Post... There are many post covering to certs regen but in this post which I came by was about creating blank ITL files and being pushed to Cisco IP Phones. What's your view on this? Although I haven't tried experimenting on it. I skipped this step and followed the TAC tech notes post while performing the CUCM cluster cert regeneration.
That is a precautionary step that you could use to make sure that all phones have a blank ITL before you regenerate TVS and Callmanager certificates. If you follow the correct process for certificate registration this should not be required, but there is always a risk that a few phones would not have updated the ITL and then they would not be able to get configuration changes as they would not trust the TVS. The recommendation is to if possible have a time gap between regeneration of these two types of certificates, the longer the better, to allow time for phones to update this information. Best practices would be to spread them out by a week or so.
This is absolutely fantastic. Please keep writing more.
With respect to this warning:
DO NOT regenerate CallManager and TVS certificates at the same time. This will cause an unrecoverable mismatch to the installed ITL on the phone to the newly generated ITL in CUCM causing the need to remove the ITL from ALL phones in the cluster. A reboot of ALL phone will be required after the regeneration of TVS certificate.
Is there any way to see if the current phones have any certificate problems and need to be reset prior to regenerating these certificates?
Thank you for your kind words @derek.andrew
There are some 3:rd party tools that can be used to test/check if the phones have an issue with ITL. Please do a search for “itl file cisco phone” to find out more.
You can also test if a device has ITL issues by doing some configuration change that’s visible or easy to verify, like turn on/off the web server on the device and then test if you can reach the web page of the device.
Thank you for your work. I'm sure it should be obvious, but one clarification in the above instructions about meaning of "one by one" if I may. Do you mean one by one according to host or by service?
By host like this #1
On pub restart:
Cisco CallManager
Cisco CTIManager
Cisco Trust Verification
Cisco Tftp
Then repeat process for subs one by one with 15 minutes between nodes? If so, how long should I wait between restarts of each service on the same node?
Or according to service this #2
On pub restart:
Cisco CallManager wait 15
On sub1 restart:
Cisco CallManager wait 15
Etc. Repeating for the same service on each host with 15 minutes between service restart before restarting same service on next host until all services on all hosts have been restarted?
Many thanks
The note reference restart of services per node, with 15 minutes gap between the nodes.
@Roger Kallberg , thanks this is a great post.
I have one question. Do we have the option to create CSR using CLI (or GUI) for changing CSR location parameters ( O= , S= , L= , C=) on UCCX?
@Jahangir Tahirov It is possible to change this, however that would not be done during the CSR creation as there is no option AFAIK available for this at that part of the webUI.
What you can do is change this from the CLI by this command "set web-security orgunit orgname locality state [country] [alternatehostname]"
You can check what the settings for this is current set to by this command "show web-security"
@Roger Kallberg thanks for the detailed information.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: