Remote Access Stops After Expressway-E Certificate Renewal
Acme Health has 750 remote workers using Webex App in Mobile and Remote Access mode. The DMZ contains an Expressway-E cluster (exp-e1 and exp-e2) fronted by a load balancer; the internal Expressway-C cluster registers clients to Cisco Unified CM 14. DNS SRV records for _collab-edge._tls.acmehealth.com point to collab-edge.acmehealth.com. Last Friday the security team replaced the expired public certificate on both Expressway-E nodes with a new wildcard certificate for *.acmehealth.corp. The old certificate, which included collab-edge.acmehealth.com, was removed from the trust stores. After the change, internal Jabber registrations are fine, but external users get 'Cannot connect to server.' Expressway-C logs show TLS handshake failures to Expressway-E, and Expressway-E logs 'no matching certificate' for connections arriving through the load balancer. Desktop users on full VPN are unaffected; mobile users on cellular fail consistently. No firewall or DNS changes were made, and Expressway software is X14.0.2.
1. What is the most likely certificate mismatch, and what identities must the new Expressway-E certificate contain?
Read the worked answer
The certificate presented to external clients is for *.acmehealth.corp. The MRA discovery name is collab-edge.acmehealth.com, which is in a different DNS suffix, so the wildcard does not match. Wildcards match only one label within the same registered domain. The replacement certificate must list collab-edge.acmehealth.com in the Subject Alternative Name extension; the common name alone is not enough for modern TLS clients. If clients or the load balancer can reach individual nodes, include exp-e1.acmehealth.com and exp-e2.acmehealth.com as SANs. If the cluster is addressed by a separate cluster FQDN, include that name too. The certificate must be issued by a public CA whose root and intermediate are trusted by the endpoints, and the private key must match. Expressway-C must trust the issuing CA chain used by Expressway-E, not just the leaf. The load balancer must pass TLS through or present the same certificate; if it terminates TLS, its certificate and SNI handling become part of the path. The fact that full-VPN desktops work supports an external certificate-name mismatch rather than a CUCM registration problem.
2. What repair and validation steps would you take, in order, to restore MRA with minimal disruption?
Read the worked answer
Generate a new CSR on each Expressway-E node with the correct SANs, obtain the certificate, and install the leaf plus intermediate chain. Keep the current certificate until the new one is validated. Update the load balancer if it terminates TLS. Confirm Expressway-C has the issuing CA in its trusted CA list and that its own certificate is still trusted by Expressway-E. Restart the Expressway-E TLS services or the nodes in a maintenance window, one node at a time if clustered. Validate from an external network with openssl s_client -connect collab-edge.acmehealth.com:5061 -servername collab-edge.acmehealth.com -showcerts; the chain must end at a trusted root and the SAN must match. Then test Webex App mobile registration over cellular, check Expressway-C and Expressway-E logs for handshake errors, and confirm DNS/SRV still resolves to the load balancer. Clear client caches only after server-side validation. Finally, monitor registration counts and call success for 24 hours.
3. Why do internal users and full-VPN desktop users still work while mobile users on cellular fail?
Read the worked answer
Internal Jabber uses CUCM directly or internal discovery, not Expressway-E. Full-tunnel VPN clients resolve internal names and use the internal path, so they do not present the external certificate mismatch. Mobile clients on cellular use external DNS/SRV and hit collab-edge.acmehealth.com through the load balancer, so they fail consistently. This split is a diagnostic clue: if the failure were a CUCM Tomcat trust issue, internal and MRA users would be affected differently, but here only the external edge path fails. It also rules out a total Expressway-C outage.