To generate CA and RSA signed ECDSA certs for 11.6(1) on a system... but I'm still getting the request for a certificate on the load of the live gadgets. I installed the certs and even restarted both sides of the UCCX 11.6(1) cluster.
Am I missing something? The CSRs worked fine, the tomcat and tomcat-ECDSA certs went in fine and the CAs and such are added to the tomcat-trust.
Thanks for the reply. I think this is connected with the Policy-CA on the new ECDSA certs, it checks on those certs for revocation, whereas our other certs do not. The xxxx-Policy-CA referenced is not on my sandbox network for setup so this is likely the cause. When I manually added the CA cert to the workstation, it was accepted, so as a workaround on go-live I can put them into a GPO. I wish Cisco would develop a little more literature on this for a few different CAs, what's supported, etc. - as one of my systems is on 11.5(1) and I think they used the COP file for ECDSA disable and I'd like to get everyone on a single, preferred design.
I had this issue today after renewing our Tomcat certs. While I couldn't find any documentation I noticed port 12015 is used by the Cisco Unified CCX Socket.IO Service and when I browsed directly to CCX.doman.com:12015 the cert was still showing the old date. I restarted the Socket.IO service and my problem cleared. This is in addition to the other services I restarted below. I did validate with TAC before restarting and did not experience any impact as this service only seems to be for live data reporting.
§ Tomcat service (utils service restart Cisco Tomcat)
§ Finesse Tomcat service (utils service restart Cisco Finesse Tomcat)
§ Unified Intelligence Center Reporting service (utils service restart Cisco Unified Intelligence Center Reporting Service)
§ Cisco Unified CCX Notification Service (utils service restart Cisco Unified CCX Notification Service)
Thanks for posting your experience. Why didn't you write out the command to restart Socket.IO?
I typically will recommend a reboot of UCCX after cert work for two reasons:
1) It's faster and easier than restarting the 6 services necessary (you missed listing Socket.IO and Cisco Unified Intelligence Center Serviceability Service in your list of 4)
2) There is a "feature" in CUCM where you need to deactivate and reactivate TFTP after cert work, not simply restart it. With that as a looming possibility, combined with Cisco introducing a new service to restart in future versions, again, it's easier and faster to just restart the whole server.
Granted, in server cert work, you don't need to restart the Engine, so the only impact is to your Agents/Supervisors, there is a case where you need to restart the Engine, and it's when you're adding new certs into Tomcat-Trust for use within scripts (E.g., Make REST Call).