<div dir="ltr">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.<div>
<br></div><div>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.</div>
<div><br></div><div>Finally, IM/Softphone/Voicemail (Jabber) working remotely without VPN. Feels good!</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Feb 19, 2014 at 9:51 AM, Ryan Ratliff (rratliff) <span dir="ltr"><<a href="mailto:rratliff@cisco.com" target="_blank">rratliff@cisco.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">
Thanks for the info Justin.
<div><br>
</div>
<div>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.</div>
<span class="HOEnZb"><font color="#888888">
<div><br>
</div>
</font></span><div><span class="HOEnZb"><font color="#888888">
<div>-Ryan </div></font></span><div><div class="h5">
<br>
<div>
<div>On Feb 19, 2014, at 8:32 AM, Justin Steinberg <<a href="mailto:jsteinberg@gmail.com" target="_blank">jsteinberg@gmail.com</a>> wrote:</div>
<br>
<div>
<div dir="ltr">
<div>here is how I understand it.</div>
<div> </div>
<div>If DNS has the _cisco-uds._<a href="http://tcp.customer.com/" target="_blank">tcp.customer.com</a> SRV record, Jabber starts the service discovery process using that SRV.</div>
<div> </div>
<div>Jabber takes the results from the SRV, then performs a query against the CUCM defined in the SRV using:</div>
<div> </div>
<div>https://<homeCluster>:8443/cucm-uds/servers</div>
<div> </div>
<div>Unfortunately, the results to the above query are based on the CUCM System > Server. If that is defined as IP, then Jabber gets IPs.</div>
<div> </div>
<div>Then Jabber takes those IPs, and performs the check below.</div>
<div> </div>
<div>https://<IP>:8443/cucm-uds/clusterUser?username=<userid></div>
<div> </div>
<div>Since Jabber uses IP, it throws a cert validation error because the IP doesn't match the FQDN (or SAN) of the certs.</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>I've opened TAC case for this 629194597, and the Presence engineer indicated changing CUCM System>Server to FQDN was an option. </div>
<div> </div>
<div>There is also a defect on the Jabber client <span lang="EN">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.</span>
<p>It seems to be, that if CUCM team opened CSCul15900 to address:</p>
<p>https://<IP>:8443/cucm-uds/clusterUser?username=<userid></p>
<p>They could also fix:</p>
<p>https://<homeCluster>:8443/cucm-uds/servers</p>
<p>and that would fix the problem.</p>
</div>
<div> </div>
<div> </div>
<div> </div>
<div> </div>
<div> </div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Tue, Feb 18, 2014 at 10:27 PM, Ryan Ratliff (rratliff)
<span dir="ltr"><<a href="mailto:rratliff@cisco.com" target="_blank">rratliff@cisco.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="auto">
<div>The doc I have is a draft version so may be subject to change. </div>
<div><br>
</div>
<div>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. <br>
<br>
Sent from my iPhone</div>
<div>
<div>
<div><br>
On Feb 18, 2014, at 8:35 PM, "Justin Steinberg" <<a href="mailto:jsteinberg@gmail.com" target="_blank">jsteinberg@gmail.com</a>> wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<p dir="ltr">What document is that?</p>
<p dir="ltr">The reason for changing the system>server to fqdn is more because of the Jabber for Windows certificate validation process than for CE.
</p>
<p dir="ltr">That being said, if Jabber wants FQDN and Collab Edge doesn't, we will have a problem.</p>
<div class="gmail_quote">On Feb 18, 2014 2:45 PM, "Ryan Ratliff (rratliff)" <<a href="mailto:rratliff@cisco.com" target="_blank">rratliff@cisco.com</a>> wrote:<br type="attribution">
<blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote">
<div style="word-wrap:break-word">Using FQDN in System->Server on UCM is specifically not supported in the Collab Edge deployment guide I'm looking at.
<div><br>
</div>
<div>It's ok to use a hostname there but it must be resolvable by the Expressway-C (and the phones of course). </div>
<div><br>
<div>-Ryan </div>
<br>
<div>
<div>On Feb 18, 2014, at 11:36 AM, Erick Wellnitz <<a href="mailto:ewellnitzvoip@gmail.com" target="_blank">ewellnitzvoip@gmail.com</a>> wrote:</div>
<br>
<div>
<div dir="ltr">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.</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Tue, Feb 18, 2014 at 8:39 AM, Justin Steinberg <span dir="ltr">
<<a href="mailto:jsteinberg@gmail.com" target="_blank">jsteinberg@gmail.com</a>></span> wrote:<br>
<blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote">
<div dir="ltr">
<div>Is anyone using CUCM deployments where they set the System>Server value to the FQDN of the CUCM nodes ?</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>I'm concerned around making this change and curious if others are using FQDN.</div>
</div>
<br>
_______________________________________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
<br>
</blockquote>
</div>
<br>
</div>
_______________________________________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
</div>
</div>
<br>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
<br>
</div></div></div>
</div>
</blockquote></div><br></div>