[cisco-voip] CUCM 11.5 Tomcat Service SSL Certificate Issue

Brian Meade bmeade90 at vt.edu
Tue May 16 15:42:29 EDT 2017


Did you make sure to upload those certs in the right order so CUCM was able
to chain them?

On Tue, May 16, 2017 at 3:32 PM, Gary Parker <G.J.Parker at lboro.ac.uk> wrote:

>
> > On 16 May 2017, at 19:27, Charles Goldsmith <wokka at justfamily.org>
> wrote:
> >
> > In addition to what Nate stated, the CCMCIP profile needs to be FQDN as
> well.
> >
> > On Tue, May 16, 2017 at 1:21 PM, NateCCIE <nateccie at gmail.com> wrote:
> > 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.
>
> 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.
>
> 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.
>
> 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).
>
> Gary
> _______________________________________________
> 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/20170516/0e7b03a0/attachment.html>


More information about the cisco-voip mailing list