[cisco-voip] Changing CUCM System>Server from IP to FQDN

Wed Feb 19 09:51:10 EST 2014

Thanks for the info Justin.

It seems to me that the fix for that would be to use hostnames and then ensure the tomcat certificate of the server has a SAN for the hostname.  Alternately Jabber could do a reverse-dns lookup on the IP in an attempt to avoid the cert validation error.

-Ryan

On Feb 19, 2014, at 8:32 AM, Justin Steinberg <jsteinberg at gmail.com<mailto:jsteinberg at gmail.com>> wrote:

here is how I understand it.

If DNS has the _cisco-uds._tcp.customer.com<http://tcp.customer.com/> SRV record, Jabber starts the service discovery process using that SRV.

Jabber takes the results from the SRV, then performs a query against the CUCM defined in the SRV using:

https://<homeCluster>:8443/cucm-uds/servers

Unfortunately, the results to the above query are based on the CUCM System > Server.   If that is defined as IP, then Jabber gets IPs.

Then Jabber takes those IPs, and performs the check below.

https://<IP>:8443/cucm-uds/clusterUser?username=<userid>

Since Jabber uses IP, it throws a cert validation error because the IP doesn't match the FQDN (or SAN) of the certs.

There is a defect on CUCM CSCul15900 and a COP to correct that, but it only applies to the second URL above.   The first URL continues to return IPs and this causes the issue.

If I remove the _cisco-uds SRV and go without using service discovery, I don't encounter the issue.  Because Jabber doesn't perform the associated queries listed above.

I've opened TAC case for this 629194597, and the Presence engineer indicated changing CUCM System>Server to FQDN was an option.

There is also a defect on the Jabber client CSCul39696, which seems to indicate that jabber will allow CUCM System>Server to just be a hostname and the tomcat to only have the FQDN.   So it seems like eventually, we could get by with CUCM System>Server just set to hostname, but I don't yet believe this is fixed in an available verson of Jabber.

It seems to be, that if CUCM team opened CSCul15900  to address:

https://<IP>:8443/cucm-uds/clusterUser?username=<userid>

They could also fix:

https://<homeCluster>:8443/cucm-uds/servers

and that would fix the problem.

On Tue, Feb 18, 2014 at 10:27 PM, Ryan Ratliff (rratliff) <rratliff at cisco.com<mailto:rratliff at cisco.com>> wrote:
The doc I have is a draft version so may be subject to change.

What is directing you to use the FQDN for helping jabber validate certs? I don't see anything perusing the server setup guide or install guide for 9.6.

Sent from my iPhone

On Feb 18, 2014, at 8:35 PM, "Justin Steinberg" <jsteinberg at gmail.com<mailto:jsteinberg at gmail.com>> wrote:

What document is that?

The reason for changing the system>server to fqdn is more because of the Jabber for Windows certificate validation process than for CE.

That being said, if Jabber wants FQDN and Collab Edge doesn't, we will have a problem.

On Feb 18, 2014 2:45 PM, "Ryan Ratliff (rratliff)" <rratliff at cisco.com<mailto:rratliff at cisco.com>> wrote:
Using FQDN in System->Server on UCM is specifically not supported in the Collab Edge deployment guide I'm looking at.

It's ok to use a hostname there but it must be resolvable by the Expressway-C (and the phones of course).

-Ryan

On Feb 18, 2014, at 11:36 AM, Erick Wellnitz <ewellnitzvoip at gmail.com<mailto:ewellnitzvoip at gmail.com>> wrote:

We were but it interferes with EMCC.  The phone only does DNS lookups for the domain it is assigned so we switched back to IP addreses.

On Tue, Feb 18, 2014 at 8:39 AM, Justin Steinberg <jsteinberg at gmail.com<mailto:jsteinberg at gmail.com>> wrote:
Is anyone using CUCM deployments where they set the System>Server value to the FQDN of the CUCM nodes ?

I'm in the process of deploying Jabber for Windows 9.6+ with Collaboration Edge, and there are requirements around certificate validation that seem to require the CUCM System>Server value set to a FQDN.

I'm concerned around making this change and curious if others are using FQDN.

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20140219/4ea2a4d0/attachment.html>