<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">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 class="h5">
<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>