CUCM and IMP IP address to FQDN

[balukr]

We have a customer currently running  CUCM 10.5.1 and IMP 10.5.1, since Jabber has certificate issues instead of doing temporary fixes we would like to do permanent fix by changing IP address to FQDN under SYSTEM - SERVER in CUCM. I did find Cisco doc's to change the IP or hostname but in this case we are not changing anything other than replacing the IP to FQDN under SYSTEM - SERVER in CUCM GUI administration. I just want to be cautious before I do anything since the servers are already in production.  I would appreciate if there is a Cisco doc kindly forward that if not

My question is

- Can I just change the IP to  FQDN names one at a time starting from Publisher including the IMP primary node?

- Do I need to restart any server or services in any of the servers?

- Do I need to regenerate cert since they are using the 3rd party CA? If I do what servers and what services I need to do that on.

Thanks again for your help.

[Varundeep Chhatwal]

Just redeploy intermediate and root ca certs again on 1 test machine. If not resoved i would suggest you to open a tac case :-)

[LarryRenz_Alvarez]

I have already opened a TAC case and the engineer's recommendation was to change the CUCM servers' definition from IP address to either FQDN or hostname, in which I went the FQDN way. 

[Varundeep Chhatwal]

i just checked your TAC Case and noticed that issue was resolved after changing ip to FQDN. But you are still facing this issue. i believe this needs another webex session to look into situation as troubleshooting it through CSC forum may be difficult. i would suggest you to open another TAC Case as your CA certs are also going to expire in september.

[LarryRenz_Alvarez]

Yeah, I decided to have the case closed after I got the recommendation of changing the CUCM IP address to FQDN. I have sent an email to the engineer you handled my case, hoping he could have another look. I'll check to see tomorrow if he'll see my email and find time to respond to it. He might be interested with the results of the change I made.

[Jaime Valencia]

You're wrong, as I already explained, the Jabber documentation explains this behavior, what you're seeing right now is completely expected. You obviously need the root CA for the full chain of trust to be complete, but that is not enough.

Did you review the documentation around certificates???? There's a whole chapter dedicated to certificates on the guides that explains how they work, and how to deploy them (in order to avoid what you're seeing)

The key here is that it does SERVER CERTIFICATE VALIDATION.

http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/jabber/11_6/cjab_b_planning-guide-cisco-jabber-116/cjab_b_planning-guide-cisco-jabber-116_chapter_0111.html

http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/jabber/11_6/cjab_b_on-premises-deployment-ciscojabber-116/cjab_b_on-premises-deployment-ciscojabber-116_chapter_01100.html

Read the above documentation.

[LarryRenz_Alvarez]

Hi Jamie,

What I actually meant by 'trusted' is that the certificates of the root CA and the intermediate CA who signed the CUCM servers' certificates are already installed and stored on the PCs. Given that, is there a need still to store the actual CUCM certs that are presented to the PCs during Jabber login on the PCs Enterprise Tryust store?

Thanks.

[Jaime Valencia]

Have you reviewed the documentation I provided??????

[LarryRenz_Alvarez]

I did, yes! And the second document says:

To ensure that certificate validation occurs without users receiving a prompt to accept or decline certificates, deploy certificates to the local certificate store of the endpoint clients.

If you use a well-known public CA, then the CA certificate may already exist on the client certificate store or keychain. If so, you need not deploy CA certificates to the clients.

If the CA certificate is not already on the client certificate store or keychain, then deploy the CA certificate to the clients.
If your deployment size is to a large number of local machines, then we recommend that you use a certificate deployment tool, such as Group Policy or a certificate deployment management application.
If your deployment size is to a smaller number of local machines, then we recommend that you manually deploy the CA certificates.

If I may reiterate, the CA certificates (both the root CA and the intermediate CA) are already on the trust store of the machines (the root CA certificate being on the Trusted Root Certification Authorities and the intermediate CA certificate being on the Intermediate Certification Authorities).

[Jaime Valencia]

Yes, that's half of it, that's the root CA. Here's the other half:

The Certificate Validation Process

Cisco Jabber validates server certificates when authenticating to services. When attempting to establish secure connections, the services present Cisco Jabber with certificates. Cisco Jabber validates the presented certificate against what is in the client device's local certificate store. If the certificate is not in the certificate store, the certificate is deemed untrusted and Cisco Jabber prompts the user to accept or decline the certificate.

If the user accepts the certificate, Cisco Jabber connects to the service and saves the certificate in the certificate store or keychain of the device . If the user declines the certificate, Cisco Jabber does not connect to the service and the certificate is not saved to the certificate store or keychain of the device.

If the certificate is in the local certificate store of the device, Cisco Jabber trusts the certificate. Cisco Jabber connects to the service without prompting the user to accept or decline the certificate.

Cisco Jabber authenticates to two services on the Cisco Unified Communications Manager server. The service names are Cisco Tomcat and Extensible Messaging and Presence Protocol (XMPP). A certificate signing request (CSR) must be generated for each service. Some public certificate authorities do not accept more than one CSR per fully qualified domain name (FQDN). Which means that the CSR for each service may need to be sent to separate public certificate authorities.

Ensure that you specify FQDN in the service profile for each service, instead of the IP address or hostname.

[LarryRenz_Alvarez]

Quick update for everyone ...

I deleted the SERVER CERTIFICATES on a machine's Enterprise Trust store, logged out of Jabber (closed it in Task Manager), reset Jabber by deleting the Jabber folders under %appdata%\Cisco\Unified Communications and %localappdata%\Cisco\Unified Communications, and then tried logging back in to Jabber. I got the initial Jabber window that asks for email address. After that, I got the login page, supplied my username and password, and DID NOT get any certificate prompts! I went back to Enterprise Trust store to see if the SERVER CERTIFICATES got imported in there automatically -- THEY ARE NOT THERE!

So... seems like for internally signed certificates (in my case Microsoft), having the Root CA and the Intermediate CA certificates on the trust store of machines is all you need to get rid of the 'Certificate not valid' prompts.

[Jaime Valencia]

OK, and have you deployed the server certificates to the clients???

If the answer is no, that's the reason you're getting the prompts.

Jabber documentation explains that if the certificates are NOT in the device certificate store BEFORE you attempt to login, you'll be prompted to accept or decline the certificate.

[Nirmal Issac]

Check this enhancement request

https://tools.cisco.com/bugsearch/bug/CSCur75757

Also the document defect

https://tools.cisco.com/bugsearch/bug/CSCur62680

[Eduardo Leon Dominguez]

Hello all,

I'll go with the procedure for change the IP to the FQDN to fix the issue with the CERTs in Jabber clients and in this guide:

https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/211393-Change-CUCM-Server-Definition-from-IP-Ad.html

... we can read this related the regeneration of certs:

"Parameters at OS Administration page affect actual network configuration of the
server; hostname or domain change leads to regeneration of all certificates for the node. Settings
at CM Administration page define, how CUCM advertises itself to endpoints via configuration files
or UDS. Change of this setting does not require certificates regeneration. This setting must match
one of the following network parameters of the node: IP address, hostname or FQDN."

Please, If I use the FQDN name of the server instead the IP (Without change the Name of the server), could you confirm if the steps for regenerate the certs not apply? The regeneration only apply when the FQDN/Hostname change?

Could you confirm it?