Remote access breaks after a certificate renewal
A distributor has 3,000 Jabber users on CUCM/IM&P 14 and needs mobile and remote access. An Expressway-C/E pair sits in the DMZ; internal clients register to CUCM directly. After the PKI team renewed the public certificate on Expressway-E, remote Jabber clients on home Wi-Fi and LTE cannot sign in - the client reports it cannot reach the server - while internal users are unaffected. The chain was exported from the issuing CA and installed on both Expressway nodes. External DNS has _collab-edge._tls.<domain> SRV records pointing at the Edge FQDN on 8443, and the firewall team confirms TCP 8443 and 5061 are open. A second symptom appeared the same week: users roaming from corporate Wi-Fi to LTE wait several minutes before Jabber gives up on the internal path and falls back. Only one public IP is available, already used by the Edge for SIP and HTTPS.
1. Walk through the diagnosis in order. Which property of a renewed certificate most often breaks MRA while leaving internal users untouched?
Read the worked answer
Internal users never touch the Edge - they auto-discover _cisco-uds._tcp and register to CUCM over the LAN - so their being fine tells you the fault is between Jabber and Expressway-E, not in CUCM.
Check in this order:
- Handshake. From outside the network,
openssl s_client -connect <edge-fqdn>:8443 -servername <edge-fqdn>. What comes back? If the handshake fails or presents a different certificate, no amount of DNS work matters. - SAN. The most common renewal failure is a SAN that no longer contains the FQDN Jabber is discovering - typically the single 'cluster/edge' name that clients were given, or the domain name configured in the Unified Communications traversal zone. If the new certificate lists only a short hostname, MRA breaks and nothing else does.
- Chain and key. Confirm the intermediate CA is actually in the Edge's trust store (not just imported as a server cert), that the private key matches, and that the same certificate was applied to both Edge nodes - a half-finished renewal gives intermittent failures that look like load balancing.
- Traversal zone state. On Expressway-C, check the Unified Communications traversal zone to the Edge is Active; a TLS verification failure there silently blocks UDS and SIP even with perfect DNS.
Note the asymmetry: 8443 being open is necessary but not sufficient - a TLS verification failure on Expressway-C also produces 'cannot reach server' on the client. Rule out the tunnel before blaming DNS.
2. Why do roaming users wait minutes before falling back, and how do you shorten that?
Read the worked answer
Jabber's service discovery is ordered: it tries the internal _cisco-uds._tcp first, and only if that fails (or times out) does it try _collab-edge._tls. On corporate Wi-Fi the internal attempt succeeds instantly. When the client moves to LTE, the phone must re-run discovery, and the internal query now has to fail before the Edge attempt begins.
A 'wait several minutes' pattern means the internal lookup is timing out rather than failing fast. Likely culprits: a DNS forwarder that blackholes the query instead of returning NXDOMAIN, a stale public A/CNAME record for an internal CUCM name, or a split-horizon view that answers the internal name from outside with an RFC1918 address the phone then tries to reach until TCP times out.
Fixes:
- Ensure the internal service records and any internal A records return NXDOMAIN quickly from public resolvers - no wildcard, no stale entries, no private addresses in public zones.
- Validate with
nslookup -type=SRV _cisco-uds._tcp.<domain> 8.8.8.8from outside: you want a prompt NXDOMAIN, not a pause. - Reduce client-side hunt time where the client version supports it, and instruct users that a Jabber restart forces a fresh discovery - useful as an interim workaround.
This is purely a discovery-order problem; the Edge itself is healthy, which is why fixed-location remote users in the first symptom behave differently from roaming ones.
3. With one public IP and the Edge already serving SIP and HTTPS, what must be reachable and how do you avoid breaking the design?
Read the worked answer
Every client-to-Edge flow must arrive on that one address, so the Edge needs a static one-to-one NAT with the public address mapped to the Edge's DMZ address - never PAT, because the certificate SAN and the TLS handshake must match the name clients resolve, and SIP/TLS does not survive source-port rewriting.
Must be permitted, inbound from the internet to the Edge: HTTPS/UDS on 8443, SIP over TLS on 5061, and the Expressway traversal media range for the RTP that is relayed when endpoints cannot reach each other directly. Anything you forget in the media range degrades to one-way audio rather than a clean failure, which is much harder to diagnose later.
Must be permitted, Edge to Edge-C across the inner firewall: 5061 (SIP), 8443 (UDS/HTTPS to CUCM and IM&P), and the same traversal media range. The C sits inside; the E never talks to CUCM directly.
Must be permitted, Edge-C inward: SIP to the CUCM call-processing nodes and HTTPS to the IM&P/UDS nodes in the cluster - several nodes, not one, or you have built a hidden single point of failure.
Design cautions with a single IP:
- Do not put a B2B TLS or other service on the same address that terminates TLS with a different certificate; the handshake will present the wrong SAN to one of the two clients.
- Keep the identity used in the certificate, the DNS SRV target and the traversal zone domain identical - one rename and MRA breaks for the entire remote population.
- Document the media port range as part of the firewall change request, and re-test with a remote client on LTE and home Wi-Fi after any certificate or firewall change, since the two paths exercise different discovery and different NAT behaviour.