12-23-2015 09:36 AM - edited 03-17-2019 05:45 PM
We are in the process of deploying Jabber 10.5 on call manager 9.01. We have all of our pubs, subs and presence servers running with FQDN's etc. We have also placed valid GeoTrust SSL certs on the boxes. However, when jabber launches it is still complaining that one of the certs isn't valid. instead of pointing to a FQDN it is pointing to an IP. (screenshot attached). We have had several engineers look over all the clusters and we can not find where it's getting the IP from.
Can you guys think of something we are missing? Also, one quick question...Does Jabber look at the DHCP scope for phone services? Could it get that IP from there?
Thanks
RB
12-23-2015 10:05 AM
And exactly whose IP is it????
12-23-2015 10:21 AM
It is the IP address of the Call Manager.
12-23-2015 10:59 AM
I'm assuming you mean under system->server they're all using FQDN, what about all the UC services you assigned to Jabber??
12-23-2015 11:18 AM
Yup, checked all of those as well as the UC services. All FQDNs.
12-23-2015 02:22 PM
Give this a try, by changing the "Cluster Fully Qualified Domain Name" from enterprise parameters in Call Manager
Other options would be to add CUCM IP address as "SAN" (Subject Alternate host)entry in the tomcat cert using "set web-security" command. This will re-generate the tomcat cert
12-28-2015 11:38 AM
those are all correct. (checked those first). Also, You can no longer request SSL Certs w/ IP addresses. That includes in the SAN field.
12-29-2015 02:12 PM
Can you post your jabber prt log files?
01-04-2016 08:25 AM
After some digging I found the issue. It seems that there is a known bug in the COP file for Jabber. Uploaded the new COP file today and the error has stopped.
https://tools.cisco.com/bugsearch/bug/CSCul15900
https://tools.cisco.com/bugsearch/bug/CSCul15923
Symptom:
In the response from server, the value of homeCluster is an IP address of server. This should be FQDN.
Due to the IP address value, Jabber windows client prompts user for the certificate presented by server even though the certificates are already imported in Trusted Root Certification Authorities store on user's machine.
Conditions:
Send a request to CUCM UDS for a cluster user on a system running CUCM 9.1(2). Newer versions of CUCM , i.e. 10.0(1) and up are not affected (although CUCM still needs to have DNS configured in the following order):
1. set network dns primary x.x.x.x
2. set network domain example.com (automatic reboot will finalize the configuration)
If DNS domain is set prior to adding a DNS server, more than 1 reboot will be necessary before FQDN is seen in UDS responses.
Workaround:
Install cmterm-cucm-uds-912-5.cop.sgn: "Cisco Unified Communications Manager UDS Collaboration Edge Update for 9.1(2)" COP file.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide