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 - this is great info. My confusion is with the tomcat certificate. If it is expired on IM&P, do I regenerate and then upload to CUCM as tomcat-trust? It seems like a logical approach, but certificates are not necessarily so.
@aaron.banks11
I would recommend you to use the multi SAN type of certificate for Tomcat, and CallManager for the fact, as those are automatically distributed to all nodes in the cluster and are managed on the publisher. It’s been a long time since I’ve done individual node certificates, just because it’s a hassle to maintain it in large clusters and the multi SAN option is so much nimbler, that I hardly recall how this works with individual certificates.
They still form a cluster, with one CM and one IMP.
Roger,
in a Cluster NOT MIXED, is it used callmanager-ecdsa certificate ? My certificate is expired.
I am considering an Cluster Upgrade and I would like to know if I should regenerate it or or let it regenerate during the update.
If I should regenerate it, the procedure is as Call Manager.pem ?
Matteo
These certificates are used internally in the cluster, regardless of mixed mode I would recommend you to renew it before you do anything else. The process is similar to the RSA signed certificates. However it might not be applicable to get it signed by a CA. It would depend on if you’re internal CA can handle EC certificates.
Hello Roger,
Our infrastructure team renewed the certs for all the UC nodes. Do I still need to generate a CSR?
@cokho The Certificate Signing Request (CSR) is how you normally request a new or renewed certificate. If your infrastructure team have created renewed certificates by some other means you should not need to create a CSR.
For IM&P tomcat-ECDSA certificates. Anything aside from the tomcat certificate renewal information you provided to be aware of?
Thanks
@TomMar1
Not from what I know. However I have yet to get IRL experience with signing this specific certificate and would likely not even get it anytime soon for IM&P as we have decommissioned that in favour of Webex cloud messaging. We’re in the process of having ECDSA certificates in other systems signed by our internal CA, so I can in not to long update you on this.
Roger, this is amazing! I have a link to it for my "bag of tricks" to give to students.
And I learned a few things, which always makes for a good day!
Maren
@Roger KallbergThanks, I guess I'll find out soon enough. These CUPS ECDSA certificates are self signed.
Thanks for the response.
@Roger Kallberg Thank you for this comprehensive documentation on UC certs!
I know this is an older post, but i reference it often and figure others do as well. I wanted to add that the UCCX finesse agent chat feature uses the IM&P cup-xmpp-ecdsa cert. If you use this feature and want the benefits of a CA signed cert, you will need to include this cert in your refresh procedures.
This is such a useful document. Thanks for writing it.
In the tomcat certificate section where it states: "If not already present in the system the signing CA root certificates needs to be uploaded to the trust store for each of these, “callmanager-trust” for CallManager or “tomcat-trust” for Tomcat." Does the CA root certificate need uploading to the trust store of the publisher alone, or to all nodes in the cluster?
Thanks,
Olly
You’re welcome. Glad you liked it.
It’s enough to upload it to the publisher, it will replicate it to the other nodes in the cluster.
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: