[cisco-voip] CUCM 11.5(1)SU6, Port 6972 and EC Certs

[Tim Smith]

Im on the road, but there was a similar bug for this. Can’t seem to find it.
It’s TFTP based issue from memory.
You had to de-activate and re-activate the TFTP services.


From: cisco-voip <cisco-voip-bounces at puck.nether.net> on behalf of Anthony Holloway <avholloway+cisco-voip at gmail.com>
Date: Wednesday, 4 September 2019 at 12:03 pm
To: "cisco-voip at puck.nether.net" <cisco-voip at puck.nether.net>
Subject: [cisco-voip] CUCM 11.5(1)SU6, Port 6972 and EC Certs

So, I just ran into something interesting where someone else took care of the certs for a CUCM I now have access to, and while the main CCMAdmin pages load fine in my browser with a full chain of trust, the 6972 page(s) are being delivered as EC certs, which were not signed, and thus, I get a warning in my browser.

Now, I have other CUCM deployments under my belt where the Tomcat RSA certs are signed and EC not, because the default setting for CUCM is to not use EC certs until you tell it to.  These deployments still present the RSA cert to me for 6972.

The only difference is the SU6 part.

I couldn't find anything in the release notes nor in the bug search, and so I'm wondering if any of you know what might be happening.

I tried toggling the HTTP Ciphers from RSA only to All and back again, but that didn't work.

I tried re-uploading the RSA cert chain, starting from root, and then back through the 2 intermediates (yes, three layers deep, it's a public CA chain).

I've restarted Tomcat, I've deactivated/reactivate TFTP, I've rebooted the cluster, and I'm just at a loss.  It's not that big of a deal, it just bothers me that I don't know why it's doing this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20190904/ac335f7a/attachment.htm>