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

[Justin Steinberg]

here is how I understand it.

If DNS has the _cisco-uds._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> 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>
> 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>
> 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>
>> 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>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
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>>
>>  _______________________________________________
>> cisco-voip mailing list
>> 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/4f45fca3/attachment.html>