[cisco-voip] Cisco CUCM SSL Certificates Issues Resolved

[Gary Parker]

Afternoon all, I finally got to the bottom of my SSL cert chain woes this morning so I thought I’d update you all and close the thread as I received so many helpful responses during my debugging. Also, apologies for cross-posting!

Quick recap:
Following a complicated roll-back and upgrade of our CUCM cluster with installation of fresh CA certs, the pub and 4x subs where all presenting a lone server cert to SSL connections on port 443 where they should have been presenting a minimum of intermediate and server. Jabber and other clients connecting to port 443 flagged an invalid certificate as they couldn’t create a full chain from server to root without the intermediate. Our support provider and TAC initially argued this was expected behaviour and suggested I manually, or via group policy, install the intermediate certificate on all client machines or else advise users to accept the invalid certificate(!). I rejected this assertion along with SSL documentation and feedback from these mailing lists showing other sites’ server infrastructure presenting a full certificate chain.

Solution:
The case was eventually escalated to the BU, a DE got root on our CUCM nodes and established that the CA certs I’d installed had, for some reason, only gone into the trust store on each of the servers and not the key store. I thought it was odd that the same thing had happened on all five servers but, hey, be thankful for small mercies: at least it failed consistently! From a root console the following commands were executed:

rm -rf /usr/local/platform/.security/tomcat/certs/tomcat.keystore

openssl pkcs12 -export -name tomcat -in /usr/local/platform/.security/tomcat/certs/tomcat.pem -chain -CApath /usr/local/platform/.security/tomcat/trust-certs -inkey /usr/local/platform/.security/tomcat/keys/tomcat_priv.pem -out /usr/local/platform/.security/tomcat/certs/tomcat.keystore -password file:/usr/local/platform/.security/tomcat/keys/tomcat.passphrase

chown certbase:ccmbase /usr/local/platform/.security/tomcat/certs/tomcat.keystore

chmod 755 /usr/local/platform/.security/tomcat/certs/tomcat.keystore

This basically deletes the existing tomcat keystore, exports the contents of the truststore to a new keystore, and sets the correct permissions on it. The tomcat service was restarted and running

openssl s_client -showcerts -connect <server>:443

…showed all three certificates in the presented chain. This had to be carried out on each of the five servers but our Jabber and RTMT clients are now connecting without issue.

Thanks again for everyone’s assistance on this one, particularly in carrying out testing on your infrastructure and reporting your findings.

---
/-Gary Parker----------------------------------f--\
| Unified Communications Service Manager |
n Loughborough University, IT Services |
| tel:[phone] sip:***@lboro.ac.uk o
| http://delphium.lboro.ac.uk/pubkey.txt |
\r----------------------------------------------d-/

[Gary Parker]

http://cisco-voip.markmail.org/thread/u37mdgcoaizjmyzj
Was there a defect ID given to you, or at least an understanding of how it happened?

Thanks for the link above, Anthony, I hadn’t thought of that.

I’m afraid there was no defect ID given and, while the diagnosis and solution where very clear, there was nothing offered as to how it had come about, either by (my) user error or a software bug. The TAC case is still open so I’ll ask and let the list know if I hear anything.

Gary