<div dir="ltr">Did you make sure to upload those certs in the right order so CUCM was able to chain them?</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 16, 2017 at 3:32 PM, Gary Parker <span dir="ltr"><<a href="mailto:G.J.Parker@lboro.ac.uk" target="_blank">G.J.Parker@lboro.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On 16 May 2017, at 19:27, Charles Goldsmith <<a href="mailto:wokka@justfamily.org">wokka@justfamily.org</a>> wrote:<br>
><br>
> In addition to what Nate stated, the CCMCIP profile needs to be FQDN as well.<br>
><br>
> On Tue, May 16, 2017 at 1:21 PM, NateCCIE <<a href="mailto:nateccie@gmail.com">nateccie@gmail.com</a>> wrote:<br>
> Are you using cuplogin or cisco-uds for discovery now?  If your UC services or system/server is not fqdn and is IP address then the client will complains about the cert unless the ip is listed as a SAN. If cup login make sure your tftp server is fqdn over in IM&P.<br>
<br>
</span>Charles/Nate we’re all fqdn throughout our UC infrastructure (have been since we first started using CA certs on Jabber) and using UDS. We’re also using expressways/MRA for off-site and telepresence. MRA logins, predictably, don’t give a certificate error as the expressway is present them correctly and, essentially, MITM’ing the connection to the CUCM/IM&P nodes.<br>
<br>
Brian > curious one, that: browsers (at least Chrome and Safari in my testing) always show the full chain, even though it isn’t offered by the server. My more security minded colleagues believe this is because we use the same CA intermediate for many other servers throughout our enterprise and the browser caches them internally and reuses them. This caused a great deal of confusion initially as pointing a web browser at <server>:8443 always showed a correct and full certificate chain in Chrome but Jabber was complaining. It wasn’t until we started pointing openssl at the server and looking at the returned certificates that we realised something was amiss.<br>
<br>
If I manually install the intermediate on a client, the problem goes away as the client can construct the full chain. My argument with TAC is that I shouldn’t have to do this, and that the tomcat server on CUCM should be presenting the full chain to any clients that connects, be it a browser, Jabber or RTMT (which also complains about an invalid certificate).<br>
<span class="HOEnZb"><font color="#888888"><br>
Gary<br>
</font></span><div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel="noreferrer" target="_blank">https://puck.nether.net/<wbr>mailman/listinfo/cisco-voip</a><br>
</div></div></blockquote></div><br></div>