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

[Justin Steinberg]

To circle back around on all of this, I finally got Jabber working remotely
via Edge today.  And turns out I may have worked myself up over this after
all.  The problem that caused me to spend so much time on this turned out
to be in the firewall.  I couldn't get Jabber to work remotely via edge and
so spent alot of time working through the various SRVs, etc and that is
when I found the cert validation issues that I previously described.

Turns out (atleast in my fairly limited testing so far) that if I
pre-populate the jabber.msi file with the fallback authenticator info via
bootstrap/MS Orca that Jabber will work remotely via Edge and locally when
on the LAN without needing to have the _cisco-uds SRV in place.  Though I'
suspect this may not work in a multicluster environment, since I believe
_cisco-uds helps the jabber client find the home cluster.  In my case,
there is a single cluster so there isn't an issue with that.

Finally, IM/Softphone/Voicemail (Jabber) working remotely without VPN.
 Feels good!


On Wed, Feb 19, 2014 at 9:51 AM, Ryan Ratliff (rratliff) <rratliff at cisco.com
> wrote:

>  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>
> wrote:
>
>  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/8e6d1d31/attachment.html>