MRA Sign-In Fails After CUCM Tomcat Certificate Regeneration
Contoso has 1,100 users on MRA with Expressway-C/E and CUCM 14. The security team regenerated the CUCM Tomcat certificate using the internal Microsoft CA. The new certificate is issued by 'Contoso Issuing CA 02', which is subordinate to 'Contoso Root CA'. The Tomcat certificate includes SAN cucm-pub.contoso.com and cucm-cluster.contoso.com. Expressway-C is configured to use cucm-pub.contoso.com for CUCM and IM&P. After the change, internal Jabber clients that already trust the root still log in, but external MRA clients fail at sign-in. Expressway-C logs show 'SSL certificate verification failed: unable to get local issuer certificate'. The Expressway-C trust store contains only the Contoso Root CA, not the issuing CA. The Expressway-C certificate is still valid and trusted by endpoints. No DNS changes were made.
1. Explain the TLS trust failure and why internal clients may still work.
Read the worked answer
TLS validation requires the complete chain from the server certificate to a trusted root. The CUCM Tomcat leaf is issued by Contoso Issuing CA 02, but Expressway-C trusts only Contoso Root CA. If the Tomcat server does not send the intermediate, Expressway-C cannot build the path and logs 'unable to get local issuer certificate.' Internal clients may still work if they already cached the intermediate or can fetch it via AIA, so their success does not prove the chain is complete. The fix is to install the issuing CA certificate in Expressway-C's trusted CA store, or install the full chain on the Tomcat certificate. Prefer both: upload the intermediate to Expressway-C and configure Tomcat to send the chain. Also confirm the SAN contains cucm-pub.contoso.com because Expressway-C connects to that name.
2. What changes and validation steps would you perform to restore external MRA sign-in?
Read the worked answer
Export the Contoso Issuing CA 02 certificate from the CA and upload it to Expressway-C as a trusted CA. On CUCM, install the Tomcat certificate with the intermediate chain if the option is available, then restart the Tomcat service in a window. From Expressway-C, use openssl s_client -connect cucm-pub.contoso.com:8443 -showcerts to confirm the server sends the leaf and intermediate and the chain verifies. Check Expressway-C logs for a successful TLS handshake, then test an external MRA sign-in and a call. Verify the certificate dates, SAN, and EKU serverAuth. Check that no CRL or OCSP failure is masquerading as a chain error. Finally, test from a fresh client with no cached certificates.
3. If sign-in still fails after the trust store update, what else would you check?
Read the worked answer
If it still fails, check whether the server sends the intermediate, whether the Expressway-C trust store is actually applied to the relevant TLS peer, and whether the configured CUCM address matches the SAN. Check clock skew, because an expired or not-yet-valid intermediate looks like a chain failure. Validate TLS version and cipher overlap, and inspect for a load balancer or reverse proxy that presents a different certificate. If revocation is enabled, confirm CRL/OCSP reachability. Also confirm that the Tomcat certificate was not regenerated with a new key without updating the trust relationship. These checks separate a trust-store problem from a hostname, time, or revocation problem.