# Setting up certificates on Cisco Expressway

Systems: Cisco Expressway

For Collaboration engineers configuring certificates on Cisco Expressway-C and Expressway-E nodes.

Canonical: https://warmtransfer.net/guides/expressway-certificate-setup

Last verified: 2026-10-01

Expressway nodes require certificates with appropriate Subject Alternative Names (SANs) and Enhanced Key Usage (EKU) extensions to authenticate traversal, edge, and clustering connections[^46][^17]. Proper configuration of certificate trust stores and signing attributes ensures uninterrupted session establishment between nodes and external endpoints[^55][^23].

## Before you start

- Cisco recommends certificates from recognized third-party CAs for Expressway, though internally generated certificates can be used in test environments[^7].
- Expressway-E and Expressway-C must both be upgraded to matching versions for EKU remediation[^29].
- Expressway-E and Expressway-C must not share an IP address or a shared NAT address[^74].
- Ensure forward and reverse DNS records exist for Expressway-C and Expressway-E nodes[^75].
- For MRA, confirm that the external firewall allows SIP TCP 5061, HTTPS TCP 8443, XMPP TCP 5222, and media UDP 36002 to 59999 inbound to Expressway-E[^76].
- The internal firewall must allow SIP TCP 7001, traversal media UDP 2776 to 2777, XMPP TCP 7400, and HTTPS tunneled over SSH TCP 2222 outbound from Expressway-C to Expressway-E[^77].

## What changes by situation

- Which Expressway release runs on your Expressway pair? X15.5 or later; X15.4; X15.3.x or earlier (including X14).
- Which CA signs the Expressway-C certificate? Enterprise (private) CA; Public CA issuing both client and server EKUs.
- How will the Expressway-E obtain its certificate? Manual CSR submission to a public CA; Automated ACME with Let's Encrypt.
- Which services run across this Expressway pair? Mobile and Remote Access (MRA) only; B2B SIP calling only; Both MRA and B2B SIP calling.
- Are the Expressway nodes clustered? Single node per role; Clustered peers.

## Step 1: Confirm the EKU posture for your release

**X15.5 or later**

### Do
Review your PKI strategy to provision separate server and client certificates, as Expressway X15.5 splits certificates into a server store presented on inbound TLS and a client store presented when Expressway initiates TLS[^78]. Plan a public CA certificate issuing server EKU for the server store and a private CA certificate issuing both client and server EKUs for the client store[^66]. If you upgraded from X15.4 or earlier, be aware that the upgrade process copied the existing server certificate into the client store[^72].
### Verify
Navigate to Maintenance > Security > Server Certificate and Maintenance > Security > Client Certificate to verify both stores exist[^70]. Confirm that Expressway-C and Expressway-E run the same version[^79].
### Rollback
Suggested rollback: Revert software upgrades if version compatibility criteria are not met.

**X15.4**

### Do
Plan to install a certificate with only the serverAuth EKU on Expressway-E, which is supported starting in X15.4 while retaining MRA registration support[^33]. Prepare a certificate containing both clientAuth and serverAuth EKUs for Expressway-C, which acts as the TLS client on the traversal zone[^25].
### Verify
Verify that both Expressway-C and Expressway-E run matching versions[^29].
### Rollback
Suggested rollback: Keep current certificates unchanged until matching software releases are installed.

**X15.3.x or earlier (including X14)**

### Do
Every Expressway X14 release and X15.0.0 through X15.3.2 is affected by the loss of client-authentication EKU in public-CA certificates, which are needed for SIP B2B over mTLS, SIP neighbor zones with mTLS, UC traversal zones, XMPP federation, and MRA onboarding[^24][^30]. Because public CAs assert only Server Authentication under Chrome Root Program policies[^32], procure certificates from an alternative root issuing combined EKUs or upgrade both nodes to matching versions of X15.4 or X15.5[^29].
### Verify
Before deployment, inspect the issued certificate to confirm both Client Authentication and Server Authentication are present in the EKU attributes[^25].
### Rollback
Suggested rollback: Keep existing valid certificates in service.

## Step 2: Build the trusted CA list on every node

**Manual CSR submission to a public CA**

### Do
Install the trusted CA certificates before installing server certificates[^63]. Navigate to Maintenance > Security > Trusted CA certificate and click Append CA certificate to add PEM-formatted CA certificates[^56]. Append the full CA chain (root and intermediates) that signed the Expressway-C certificate to the Expressway-E trust store[^54]. Append the CA chain that signed the Expressway-E certificate to the Expressway-C trust store[^57].
### Verify
Verify that the uploaded CAs appear in the trusted list and do not exceed the limit of 1000 uploaded certificate authorities[^51]. Confirm that full certificate chains are present to satisfy TLS verification requirements[^55].
### Rollback
Delete uploaded CA certificates manually if needed, avoiding Reset to default CA certificate which replaces every uploaded CA certificate with the system's original trusted CA list[^58].

**Automated ACME with Let's Encrypt**

### Do
Append the CA chain that signed the Expressway-C certificate to each Expressway-E[^54]. Append the Let's Encrypt intermediate CA certificate to the trust store of each Expressway-E and of the traversal Expressway-C[^1]. Use Maintenance > Security > Trusted CA certificate and select Append CA certificate to retain existing trust entries[^56].
### Verify
Confirm that the full chain of trust appears in the list on each node[^55] and stays within the 1000 CA limit[^51].
### Rollback
Delete appended Let's Encrypt or private CA certificates individually; do not use Reset to default CA certificate unless you intend to wipe all uploaded certificates[^58].

## Step 3: List the SAN entries the Expressway-C certificate needs

**Mobile and Remote Access (MRA) only**

### Do
Compile the Subject Alternative Names for Expressway-C, including the Unified CM phone security profile names used by MRA endpoints in FQDN format[^42][^47]. Include IM and Presence chat node aliases if federated group chat is used[^80].
### Verify
Confirm that the planned SAN contains the exact name that will be configured as the TLS verify subject name on the Expressway-E traversal zone[^50]. Note that Expressway validates certificates against the Subject Alternative Name rather than the common name[^46].
### Rollback
Suggested rollback: Discard the planned name list.

**B2B SIP calling only**

### Do
Compile the Subject Alternative Names for Expressway-C to include all FQDNs that neighbor zones and traversal partners will use to contact this node[^73]. Ensure the FQDN matching the Expressway-E traversal zone TLS verify subject name is included[^50].
### Verify
Verify that every FQDN used as a target by neighbor zones appears in the SAN list, as Expressway validates against the SAN attribute rather than the common name[^46][^73].
### Rollback
Suggested rollback: Discard the planned name list.

**Both MRA and B2B SIP calling**

### Do
Compile the Subject Alternative Names for Expressway-C to include the Unified CM phone security profile names in FQDN format[^47], any IM and Presence chat node aliases[^43], and all FQDNs checked by neighbor zones and traversal partners[^73][^50].
### Verify
Confirm all phone profile names and peer FQDNs appear in the SAN list[^46].
### Rollback
Suggested rollback: Discard the planned name list.

## Step 4: Generate the Expressway-C CSR

**Single node per role**

### Do
Navigate to Maintenance > Security > Server certificate and click Generate CSR[^19]. Select an RSA key of 2048 or 4096 bits, or an ECDSA key of 256, 384, or 521 bits[^18], avoiding 8192-bit keys[^60]. Keep the default SHA-256 digest algorithm[^15].
### Verify
Verify that the CSR contains the requested SAN entries and automatically includes both Client Authentication and Server Authentication EKU extensions[^17]. Confirm the private key is generated on the node, where it remains stored and cannot be downloaded[^22].
### Rollback
Click Discard CSR if details must be corrected, noting that only one CSR can be in progress at a time[^20].

**Clustered peers**

### Do
Generate a separate CSR on each Expressway-C peer node from Maintenance > Security > Server certificate[^19][^21]. Select RSA keys of 2048 or 4096 bits or ECDSA keys of 256, 384, or 521 bits[^18], with a SHA-256 digest[^15]. Configure the cluster FQDN as the common name and include both the cluster FQDN and all peer FQDNs in the alternative names[^41]. Do not reuse a single certificate across multiple peers[^12].
### Verify
Verify that each peer's CSR lists all peer FQDNs present in System > Clustering Peer address fields[^11].
### Rollback
Click Discard CSR on any peer where values need modification[^20].

## Step 5: Get the Expressway-C certificate signed

**Enterprise (private) CA**

### Do
Submit the Expressway-C CSR to your enterprise CA using a certificate template configured to issue both clientAuth and serverAuth EKUs[^25][^31].
### Verify
Examine the issued certificate to confirm that both Client Authentication and Server Authentication appear in the EKU extension[^25].
### Rollback
Suggested rollback: Revoke or discard the certificate at the enterprise CA.

**Public CA issuing both client and server EKUs**

### Do
Submit the CSR to a public CA service that provides both clientAuth and serverAuth EKUs using an alternative issuing root[^25]. Note that Cisco gives 2026-03-15 as the date public TLS certificate validity dropped to 200 days[^34].
### Verify
Verify that the issued public certificate explicitly contains Client Authentication alongside Server Authentication in its EKU attributes[^25].
### Rollback
Suggested rollback: Revoke or request reissuance through the public CA account.

## Step 6: List the SAN entries the Expressway-E certificate needs

**Mobile and Remote Access (MRA) only**

### Do
Compile the Subject Alternative Names for Expressway-E to include the Unified CM registration domains[^44]. Add XMPP federation domains and IM and Presence chat node aliases if federated group chat is enabled[^45]. Include the Expressway-E FQDN used by Expressway-C as the traversal client peer address[^49].
### Verify
Confirm all Unified CM registration domains and external hostnames are included in the SAN list, as Jabber checks the certificate SAN[^81].
### Rollback
Suggested rollback: Discard the planned name list.

**B2B SIP calling only**

### Do
Compile the Subject Alternative Names for Expressway-E to include the FQDN configured on Expressway-C as the traversal peer address[^49]. Include any FQDNs or IP addresses that external neighbor systems check during TLS verification[^73].
### Verify
Ensure the peer address configured on the traversal client matches an entry in the SAN list[^49].
### Rollback
Suggested rollback: Discard the planned name list.

**Both MRA and B2B SIP calling**

### Do
Compile the Subject Alternative Names for Expressway-E to include the Unified CM registration domains[^44], XMPP federation domains and chat node aliases[^45], and the FQDNs checked by neighbor systems and traversal connections[^49][^73].
### Verify
Verify that all registration domains and external hostnames are present in the SAN list[^46].
### Rollback
Suggested rollback: Discard the planned name list.

## Step 7: Obtain the Expressway-E certificate

**Manual CSR submission to a public CA**

### Do
Navigate to Maintenance > Security > Server certificate on each Expressway-E node and click Generate CSR[^19][^21]. Select RSA keys of 2048 or 4096 bits or ECDSA keys of 256, 384, or 521 bits[^18], with a SHA-256 digest[^15].
### Verify
Check that the issued certificate includes all required SANs[^46] and that Jabber clients have the signing CA in their trust list[^53].
### Rollback
Click Discard CSR to abandon the CSR before installation[^20].

**Automated ACME with Let's Encrypt**

### Do
Ensure inbound TCP 80 from the internet is permitted to every Expressway-E peer[^5]. Configure and enable the ACME service on Expressway-E, which signs and deploys server certificates automatically with Let's Encrypt[^2]. Set the desired deployment schedule, noting that renewal triggers once two-thirds of certificate validity has elapsed[^6].
### Verify
Confirm that the certificate deploys successfully without requiring a restart, as processes load the certificate automatically[^3].
### Rollback
Disable ACME on the Expressway-E and install a manually requested certificate if needed[^65].

## Step 8: Upload and activate the server certificates

**Single node per role**

### Do
Navigate to Maintenance > Security > Server certificate[^19]. Ensure the signing CA chain has been installed first[^63]. Upload the signed PEM certificate; if the CSR was generated externally, upload the unencrypted private key matching the certificate[^64]. Restart the Expressway for the new certificate to take effect[^40].
### Verify
Click Show (decoded) under Maintenance > Security > Server certificate to verify the issuer, SAN entries, and validity dates[^65].
### Rollback
Restore the previous certificate if necessary, or use Reset to default server certificate to restore the system's original certificate, then restart[^65][^40].

**Clustered peers**

### Do
If System > Clustering TLS Verification mode is set to Enforce, set it to Permissive before changing certificates[^36]. Upload each peer's unique signed server certificate on its respective node[^35]. Restart the cluster nodes one at a time, letting each recover before restarting the next[^38]. Set TLS Verification mode back to Enforce[^37].
### Verify
Navigate to Show (decoded) on each peer to confirm its certificate is active[^65]. Verify that System > Clustering displays green status for all peers[^11].
### Rollback
Switch TLS Verification mode back to Permissive and reinstall the previous valid certificates using the rolling restart sequence[^36][^38].

## Step 9: Set the client certificate

**X15.5 or later**

### Do
Navigate to Maintenance > Security > Client Certificate[^70]. Upload a certificate carrying the Client Authentication EKU extension, noting that Cisco recommends a private CA issuing both client and server EKUs[^66]. Ensure the signing CA is added to the shared trusted CA list[^71].
### Verify
Confirm the certificate uploads successfully, as a certificate lacking the client-authentication EKU will be rejected by the store[^67].
### Rollback
Suggested rollback: Re-upload the previous client certificate.

**X15.4**

### Do
Expressway X15.4 uses a single certificate store where the Expressway-C server certificate acts as the client certificate on outbound TLS connections[^68]. Ensure the certificate on Expressway-C possesses both clientAuth and serverAuth EKUs[^25].
### Verify
Confirm on Expressway-C that the active server certificate displays both Client Authentication and Server Authentication in its EKU attributes[^25].
### Rollback
Suggested rollback: Keep the existing combined-EKU certificate active.

**X15.3.x or earlier (including X14)**

### Do
Because X15.3 and earlier versions do not provide separate client certificate stores[^68], verify that the server certificates loaded on both nodes carry both Client Authentication and Server Authentication[^24].
### Verify
Verify the presence of both EKUs in the active certificates under Show (decoded)[^25][^65].
### Rollback
Suggested rollback: Keep the existing valid combined-EKU certificate.

## Step 10: Align the traversal zone names with the certificates

**Single node per role**

### Do
On the Expressway-E traversal server zone, set the TLS verify subject name to a name matching an entry in the Expressway-C certificate SAN[^50]. On the Expressway-C traversal client zone, enter the Expressway-E FQDN that is listed in its SAN as the peer address[^49]. Note that UC traversal zones are configured with TLS verify mode On[^62].
### Verify
Verify that the traversal zone establishes and shows an Active state on both Expressway-C and Expressway-E[^62].
### Rollback
Suggested rollback: Restore the prior peer address and TLS verify subject name values in zone configuration.

**Clustered peers**

### Do
On the Expressway-E traversal server zone, set the TLS verify subject name to the Expressway-C cluster FQDN, ensuring that name is present in each Expressway-C peer certificate's SAN[^41][^50]. On the Expressway-C traversal client zone, configure each Expressway-E peer FQDN as a peer address[^49].
### Verify
Confirm that the traversal zone status is Active across all cluster peers with TLS verify mode On[^62].
### Rollback
Suggested rollback: Restore previous traversal peer addresses and verify subject names.

## Step 11: Establish trust with Unified CM

**Mobile and Remote Access (MRA) only**

### Do
Upload the root CA that signed the Expressway-C certificate to the CallManager-trust and tomcat-trust stores on each Unified CM cluster[^59]. Ensure Expressway-C trusts the Unified CM CallManager and tomcat certificates, and ensure the hostname used to define each Unified CM node is present as a SAN in its tomcat certificate[^52].
### Verify
Navigate to Configuration > Unified Communications on Expressway-C and verify that Unified CM server discovery completes successfully[^52][^82].
### Rollback
Suggested rollback: Remove the root CA from Unified CM CallManager-trust and tomcat-trust stores.

**B2B SIP calling only**

### Do
For each SIP neighbor zone configured with TLS verify enabled, verify that the neighbor system's FQDN matches the name in its certificate[^73]. Ensure the signing CA of each neighbor system is present in the Expressway trusted CA list with a full chain of trust[^55].
### Verify
Check zone status to verify that the neighbor zones transition to Active without TLS verification errors[^73].
### Rollback
Suggested rollback: Remove any added neighbor CA certificates from the trusted list.

**Both MRA and B2B SIP calling**

### Do
Upload the Expressway-C root CA to the CallManager-trust and tomcat-trust stores on each Unified CM cluster[^59]. Ensure the Unified CM node definitions match SANs in their tomcat certificates and are trusted by Expressway-C[^52]. For neighbor zones, confirm the neighbor FQDNs match their certificates[^73] and upload their issuing CA chains into the trusted CA list to establish a full chain of trust[^55].
### Verify
Verify that Unified CM discovery completes successfully on Expressway-C and that neighbor zones show Active status[^52][^73].
### Rollback
Suggested rollback: Remove added CAs from Unified CM and Expressway trust stores.

## Step 12: Enforce cluster TLS verification

**Single node per role**

### Do
### Verify
Suggested check: Verify that standalone system alarms and status remain clear.
### Rollback
Suggested rollback: No action required.

**Clustered peers**

### Do
Before changing verification mode, confirm that each peer certificate's SANs contain the FQDNs in the Peer address fields, each peer trusts the CA that signed the other peers' certificates, and System > Clustering shows green status for each peer[^11]. Set TLS verification mode to Enforce on the primary peer, then restart the primary first and each other peer in turn[^10].
### Verify
Confirm that System > Clustering displays a green status across all cluster peers after the restarts complete[^11].
### Rollback
Change TLS verification mode back to Permissive and perform a rolling restart of the cluster nodes[^36][^38].

## Step 13: Renew without an outage

**Single node per role**

### Do
Generate a new CSR and obtain the signed certificate prior to expiry to prevent external connection failures[^19][^23]. Append any new CA certificates to the trust list before applying the server certificate[^63]. Schedule a maintenance window to upload the certificate and restart the Expressway, as a standalone node requires a restart[^40]. If using ACME on Expressway-E, renewal occurs automatically at two-thirds validity without requiring a restart[^3][^6].
### Verify
Verify the renewed certificate details and updated expiration date using Show (decoded)[^65].
### Rollback
Re-upload the prior certificate and restart the system if issues arise before the old certificate expires[^40][^65].

**Clustered peers**

### Do
Generate separate CSRs for each peer[^21]. Append any new trusted CA certificate across all cluster nodes before uploading the server certificates[^35]. Set System > Clustering TLS Verification mode to Permissive[^36]. Upload the new certificates to every peer, then restart nodes one at a time, allowing each to recover before restarting the next[^38]. Set TLS Verification mode back to Enforce and remove unused CAs[^37]. CA/Browser Forum ballot SC081v3 cuts public TLS validity to 47 days in stages between March 2026 and March 2029[^8]; WarmTransfer's reading of the sources is that manual renewals will require rolling restarts several times a year[^39].
### Verify
Verify that each peer successfully rejoins the cluster and displays green status before proceeding to the next node restart[^11][^38].
### Rollback
Set TLS verification to Permissive, reinstall the prior valid certificates, and perform a rolling restart across peers[^36][^38].

## Step 14: Verify the finished configuration

### Do
Inspect the certificates on each Expressway by navigating to Maintenance > Security > Server certificate and selecting Show (decoded) to review issuers, SAN entries, and validity periods[^65]. Check Status > Alarms on both Expressway-C and Expressway-E, and review the Status > Unified Communications page[^83]. Confirm that the UC traversal zone is configured with TLS verify mode On[^62].
### Verify
Confirm that all traversal and neighbor zones show an Active state[^62][^73]. If SIP TLS zones fail to activate, verify that certificate key sizes do not exceed 4096 bits, as 8192-bit keys can cause zone negotiation failures[^60].
### Rollback
Suggested rollback: Revert zone settings or re-upload previous certificates if alarms persist.

## Applicability
Applies to: Cisco Expressway and CA Browser Forum Public TLS certificates. Deployments: on-premises and public-pki. Sources checked 2026-10-01. The claims in this article specifically address Cisco Expressway releases X8.10 through X15.5[^15][^70], with EKU remediation and dual certificate stores applying to X15.4 and X15.5[^33][^68]. Public CA certificate validity reduction rules follow CA/Browser Forum ballot SC081v3 spanning 2026 to 2029[^8]. See also [Troubleshooting Expressway Mobile and Remote Access](https://warmtransfer.net/knowledge/expressway-mra-troubleshooting).

## What remains uncertain
Specific SAN requirements and validation behaviors enforced by external third-party B2B federation partners are not covered by the sources below. In addition, the exact enforcement scope of the X15.5 EKU checking CLI toggle is not covered by the sources below.

## Sources

[^1]: When ACME is used, the Let's Encrypt intermediate CA certificate is appended to the trust store of each Expressway-E and of the traversal Expressway-C. Source: [Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - Using ACME on Expressway-E](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X15-5/cert-creation-use/exwy_b_cisco-expressway-certificate-creation-and-use-deployment-guide-x155/exwy_m_using-acme-on-expressway-e.html), Using ACME on Expressway-E > prerequisites, trust stores. Checked 2026-09-30.
[^2]: The ACME service on Expressway-E signs and deploys server certificates automatically, and Let's Encrypt is the only CA it currently works with. Source: [Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - Using ACME on Expressway-E](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X15-5/cert-creation-use/exwy_b_cisco-expressway-certificate-creation-and-use-deployment-guide-x155/exwy_m_using-acme-on-expressway-e.html), Using ACME on Expressway-E > introduction. Checked 2026-09-30.
[^3]: A certificate deployed by ACME does not need an Expressway-E restart; the processes that use it load the new certificate on their own. Source: [Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - Using ACME on Expressway-E](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X15-5/cert-creation-use/exwy_b_cisco-expressway-certificate-creation-and-use-deployment-guide-x155/exwy_m_using-acme-on-expressway-e.html), Using ACME on Expressway-E > deployment. Checked 2026-09-30.
[^4]: In a cluster, ACME is enabled on each Expressway-E peer separately, and each peer's CSR carries only that node's FQDN and the cluster FQDN. Source: [Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - Using ACME on Expressway-E](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X15-5/cert-creation-use/exwy_b_cisco-expressway-certificate-creation-and-use-deployment-guide-x155/exwy_m_using-acme-on-expressway-e.html), Using ACME on Expressway-E > clustered systems. Checked 2026-09-30.
[^5]: ACME on Expressway-E needs inbound TCP 80 from the internet to every Expressway-E peer, because the requester must answer on port 80 for each domain in the CSR. Source: [Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - Using ACME on Expressway-E](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X15-5/cert-creation-use/exwy_b_cisco-expressway-certificate-creation-and-use-deployment-guide-x155/exwy_m_using-acme-on-expressway-e.html), Using ACME on Expressway-E > prerequisites. Checked 2026-09-30.
[^6]: The Expressway-E ACME service renews a certificate once two-thirds of its validity period has passed, and deployment can be scheduled for chosen times and weekdays. Source: [Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - Using ACME on Expressway-E](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X15-5/cert-creation-use/exwy_b_cisco-expressway-certificate-creation-and-use-deployment-guide-x155/exwy_m_using-acme-on-expressway-e.html), Using ACME on Expressway-E > certificate renewal and deployment schedule. Checked 2026-09-30.
[^7]: Cisco recommends certificates from recognized third-party CAs for Expressway and says internally generated certificates can be used in controlled or test environments. Source: [Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - About This Guide](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X15-5/cert-creation-use/exwy_b_cisco-expressway-certificate-creation-and-use-deployment-guide-x155/exwy_m_about-this-guide.html), About This Guide > certificate overview. Checked 2026-09-30.
[^8]: CA/Browser Forum ballot SC081v3 cuts the maximum validity of public TLS certificates from 398 days to 47 days in stages from March 2026 to March 2029. Source: [Ballot SC081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods](https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/), Ballot summary / purpose. Checked 2026-09-30.
[^9]: A DNS SRV record listing every peer is recommended for an Expressway cluster used for B2B and video interop but not for MRA; Expressway-E clusters use per-peer collab-edge SRV records for MRA. Source: [Cisco Expressway Cluster Creation and Maintenance Deployment Guide (X15.4) - Clustering Requirements](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X15-4/cluster_creation_maint/exwy_b_cisco-expressway-cluster-creation-and-maintenance-deployment-guide-x154/exwy_m_clustering-requirements.html), Clustering Requirements > DNS. Checked 2026-09-30.
[^10]: After TLS verification mode is set to Enforce on the primary peer, restart the primary first and then each other peer in turn. Source: [Cisco Expressway Cluster Creation and Maintenance Deployment Guide (X15.4) - Use Fully Qualified Domain Names to Form a Cluster](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X15-4/cluster_creation_maint/exwy_b_cisco-expressway-cluster-creation-and-maintenance-deployment-guide-x154/exwy_m_optional-use-fully-qualified-domain.html), Use Fully Qualified Domain Names to Form a Cluster > enabling Enforce TLS verification, restart steps. Checked 2026-09-30.
[^11]: Before setting cluster TLS verification mode to Enforce, confirm that each certificate's SANs contain the FQDNs in the Peer address fields and that System > Clustering shows green status for each peer. Source: [Cisco Expressway Cluster Creation and Maintenance Deployment Guide (X15.4) - Use Fully Qualified Domain Names to Form a Cluster](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X15-4/cluster_creation_maint/exwy_b_cisco-expressway-cluster-creation-and-maintenance-deployment-guide-x154/exwy_m_optional-use-fully-qualified-domain.html), Use Fully Qualified Domain Names to Form a Cluster > enabling Enforce TLS verification. Checked 2026-09-30.
[^12]: Each Expressway cluster peer has its own certificate identifying it to the other peers; using one certificate on several Expressways is discouraged because one compromised key exposes them all. Source: [Cisco Expressway Cluster Creation and Maintenance Deployment Guide (X15.4) - Clustering Requirements](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X15-4/cluster_creation_maint/exwy_b_cisco-expressway-cluster-creation-and-maintenance-deployment-guide-x154/exwy_m_clustering-requirements.html), Clustering Requirements > certificate requirements. Checked 2026-09-30.
[^13]: For cluster TLS in Enforce mode, each peer must trust the CA that issued the other peers' certificates. Source: [Cisco Expressway Cluster Creation and Maintenance Deployment Guide (X15.4) - Use Fully Qualified Domain Names to Form a Cluster](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X15-4/cluster_creation_maint/exwy_b_cisco-expressway-cluster-creation-and-maintenance-deployment-guide-x154/exwy_m_optional-use-fully-qualified-domain.html), Use Fully Qualified Domain Names to Form a Cluster > prerequisites. Checked 2026-09-30.
[^14]: For a clustered Expressway the CSR common name is the cluster FQDN, and the FQDNs of the peer servers are added as subject alternative names. Source: [Generate CSR and Upload Signed Certificate to VCS/Expressway Servers](https://www.cisco.com/c/en/us/support/docs/unified-communications/expressway/215670-generate-csr-and-upload-signed-certifica.html), Configure > Generate CSR, common name and subject alternative name guidance. Checked 2026-09-30.
[^15]: The Expressway CSR digest algorithm defaults to SHA-256, and SHA-1 cannot be selected from version X8.10. Source: [Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - Generating a Certificate Signing Request](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X15-5/cert-creation-use/exwy_b_cisco-expressway-certificate-creation-and-use-deployment-guide-x155/exwy_m_generating-a-certificate-signing-request.html), Generating a Certificate Signing Request > Digest algorithm. Checked 2026-09-30.
[^16]: For an Expressway-E with MRA, the MRA domain is added to the alternative names as either the bare domain or collab-edge.<domain>. Source: [Generate CSR and Upload Signed Certificate to VCS/Expressway Servers](https://www.cisco.com/c/en/us/support/docs/unified-communications/expressway/215670-generate-csr-and-upload-signed-certifica.html), Configure > Generate CSR, Expressway-E with MRA. Checked 2026-09-30.
[^17]: A CSR generated on Expressway automatically includes the client authentication and server authentication Enhanced Key Usage extensions. Source: [Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - Generating a Certificate Signing Request](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X15-5/cert-creation-use/exwy_b_cisco-expressway-certificate-creation-and-use-deployment-guide-x155/exwy_m_generating-a-certificate-signing-request.html), Generating a Certificate Signing Request > introductory paragraph. Checked 2026-09-30.
[^18]: The Expressway CSR generator offers ECDSA keys of 256, 384 or 521 bits and RSA keys of 2048 or 4096 bits. Source: [Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - Generating a Certificate Signing Request](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X15-5/cert-creation-use/exwy_b_cisco-expressway-certificate-creation-and-use-deployment-guide-x155/exwy_m_generating-a-certificate-signing-request.html), Generating a Certificate Signing Request > Public key algorithm and Key length. Checked 2026-09-30.
[^19]: On Cisco Expressway a certificate signing request is generated from Maintenance > Security > Server certificate by clicking Generate CSR. Source: [Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - Generating a Certificate Signing Request](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X15-5/cert-creation-use/exwy_b_cisco-expressway-certificate-creation-and-use-deployment-guide-x155/exwy_m_generating-a-certificate-signing-request.html), Generating a Certificate Signing Request > Generating a CSR using Expressway, step 1. Checked 2026-09-30.
[^20]: Only one CSR can be in progress on an Expressway at a time; starting over requires clicking Discard CSR. Source: [Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - Generating a Certificate Signing Request](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X15-5/cert-creation-use/exwy_b_cisco-expressway-certificate-creation-and-use-deployment-guide-x155/exwy_m_generating-a-certificate-signing-request.html), Generating a Certificate Signing Request > Generating a CSR using Expressway, note. Checked 2026-09-30.
[^21]: In an Expressway cluster a separate CSR must be generated on each peer. Source: [Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - Generating a Certificate Signing Request](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X15-5/cert-creation-use/exwy_b_cisco-expressway-certificate-creation-and-use-deployment-guide-x155/exwy_m_generating-a-certificate-signing-request.html), Generating a Certificate Signing Request > note on clusters. Checked 2026-09-30.
[^22]: When the CSR is generated on Expressway, the private key is stored on the Expressway and cannot be viewed or downloaded. Source: [Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - Generating a Certificate Signing Request](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X15-5/cert-creation-use/exwy_b_cisco-expressway-certificate-creation-and-use-deployment-guide-x155/exwy_m_generating-a-certificate-signing-request.html), Generating a Certificate Signing Request > note on private key. Checked 2026-09-30.
[^23]: If the Expressway server certificate expires, external systems may reject it and the Expressway may be unable to connect to them. Source: [Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - About This Guide](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X15-5/cert-creation-use/exwy_b_cisco-expressway-certificate-creation-and-use-deployment-guide-x155/exwy_m_about-this-guide.html), About This Guide > certificate overview, expiry note. Checked 2026-09-30.
[^24]: Every Expressway X14 release and X15.0.0 through X15.3.2 is affected by the loss of client-authentication EKU in public-CA certificates. Source: [Field Notice: FN74362 - Cisco Expressway: Impact on Secure Communication due to Upcoming Changes to TLS Certificates Issued by Public Certificate Authorities with Client Authentication EKU, Starting May 2026 - Workaround Provided](https://www.cisco.com/c/en/us/support/docs/field-notices/743/fn74362.html), Products Affected. Checked 2026-09-30.
[^25]: Expressway-C needs a certificate with both clientAuth and serverAuth EKUs because it acts as the TLS client on the UC traversal zone. Source: [Prepare Expressway for Client Authentication EKU Sunset in Public CA Certificates](https://www.cisco.com/c/en/us/support/docs/unified-communications/expressway-series/225482-prepare-expressway-for-client.html), Certificate requirements by Expressway role, Expressway-C row. Checked 2026-09-30.
[^26]: One Cisco workaround is to switch to public CAs that still issue certificates carrying both clientAuth and serverAuth EKUs from alternative roots, naming DigiCert and IdenTrust. Source: [Field Notice: FN74362 - Cisco Expressway: Impact on Secure Communication due to Upcoming Changes to TLS Certificates Issued by Public Certificate Authorities with Client Authentication EKU, Starting May 2026 - Workaround Provided](https://www.cisco.com/c/en/us/support/docs/field-notices/743/fn74362.html), Workaround/Solution > Option 1. Checked 2026-09-30.
[^27]: Cisco technote 225482 gives June 2026 as the full enforcement date of the public-CA client-authentication EKU restriction (disputed). Source: [Prepare Expressway for Client Authentication EKU Sunset in Public CA Certificates](https://www.cisco.com/c/en/us/support/docs/unified-communications/expressway-series/225482-prepare-expressway-for-client.html), Background > timeline, June 2026 entry. Checked 2026-09-30.
[^28]: Field notice FN74362 says the Chrome Root Program restriction phasing out multi-purpose public roots takes effect in March 2027 (disputed). Source: [Field Notice: FN74362 - Cisco Expressway: Impact on Secure Communication due to Upcoming Changes to TLS Certificates Issued by Public Certificate Authorities with Client Authentication EKU, Starting May 2026 - Workaround Provided](https://www.cisco.com/c/en/us/support/docs/field-notices/743/fn74362.html), Problem Description. Checked 2026-09-30.
[^29]: For the EKU remediation, Expressway-E and Expressway-C must both be upgraded to matching versions. Source: [Field Notice: FN74362 - Cisco Expressway: Impact on Secure Communication due to Upcoming Changes to TLS Certificates Issued by Public Certificate Authorities with Client Authentication EKU, Starting May 2026 - Workaround Provided](https://www.cisco.com/c/en/us/support/docs/field-notices/743/fn74362.html), Workaround/Solution > upgrade note. Checked 2026-09-30.
[^30]: Expressway connections in which it acts as a TLS client and needs a client-authentication EKU are SIP B2B over mTLS, SIP neighbor zones with mTLS (Unified CM, Unity, CUBE, CMS), UC traversal zones, XMPP federation, and MRA onboarding to the Cisco cloud. Source: [Field Notice: FN74362 - Cisco Expressway: Impact on Secure Communication due to Upcoming Changes to TLS Certificates Issued by Public Certificate Authorities with Client Authentication EKU, Starting May 2026 - Workaround Provided](https://www.cisco.com/c/en/us/support/docs/field-notices/743/fn74362.html), Problem Description > affected connections. Checked 2026-09-30.
[^31]: Cisco's option of moving to a private PKI that issues combined EKUs applies to Expressway-C only, not to Expressway-E, whose external-facing services need public CA certificates. Source: [Field Notice: FN74362 - Cisco Expressway: Impact on Secure Communication due to Upcoming Changes to TLS Certificates Issued by Public Certificate Authorities with Client Authentication EKU, Starting May 2026 - Workaround Provided](https://www.cisco.com/c/en/us/support/docs/field-notices/743/fn74362.html), Workaround/Solution > Option 3. Checked 2026-09-30.
[^32]: Under the Chrome Root Program policy, public CAs may assert only the Server Authentication EKU on TLS certificates, and Let's Encrypt stopped issuing combined-EKU certificates on 2026-02-11. Source: [Prepare Expressway for Client Authentication EKU Sunset in Public CA Certificates](https://www.cisco.com/c/en/us/support/docs/unified-communications/expressway-series/225482-prepare-expressway-for-client.html), Background > Chrome Root Program policy and timeline. Checked 2026-09-30.
[^33]: From X15.4, an Expressway-E accepts upload of a certificate with only the serverAuth EKU and still supports MRA registrations. Source: [Field Notice: FN74362 - Cisco Expressway: Impact on Secure Communication due to Upcoming Changes to TLS Certificates Issued by Public Certificate Authorities with Client Authentication EKU, Starting May 2026 - Workaround Provided](https://www.cisco.com/c/en/us/support/docs/field-notices/743/fn74362.html), Workaround/Solution > X15.4. Checked 2026-09-30.
[^34]: Cisco's EKU technote gives 2026-03-15 as the date public TLS certificate validity dropped to 200 days. Source: [Prepare Expressway for Client Authentication EKU Sunset in Public CA Certificates](https://www.cisco.com/c/en/us/support/docs/unified-communications/expressway-series/225482-prepare-expressway-for-client.html), Background > timeline, March 15, 2026 entry. Checked 2026-09-30.
[^35]: When changing a server certificate, the new trusted CA certificate is added on all nodes of the cluster before the new server certificate is applied to every node. Source: [Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - Loading Certificates and Keys Onto Expressway](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X15-5/cert-creation-use/exwy_b_cisco-expressway-certificate-creation-and-use-deployment-guide-x155/exwy_m_loading-certificates-and-keys-onto.html), Loading Certificates and Keys Onto Expressway > Changing an Existing Server Certificate, steps 2 and 4. Checked 2026-09-30.
[^36]: Before changing an existing server certificate in a cluster whose TLS Verification mode (System > Clustering) is Enforce, change it to Permissive. Source: [Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - Loading Certificates and Keys Onto Expressway](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X15-5/cert-creation-use/exwy_b_cisco-expressway-certificate-creation-and-use-deployment-guide-x155/exwy_m_loading-certificates-and-keys-onto.html), Loading Certificates and Keys Onto Expressway > Changing an Existing Server Certificate, step 3. Checked 2026-09-30.
[^37]: After the certificate change, TLS Verification mode is set back to Enforce if it was changed, and CA certificates no longer in use are removed. Source: [Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - Loading Certificates and Keys Onto Expressway](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X15-5/cert-creation-use/exwy_b_cisco-expressway-certificate-creation-and-use-deployment-guide-x155/exwy_m_loading-certificates-and-keys-onto.html), Loading Certificates and Keys Onto Expressway > Changing an Existing Server Certificate, steps 6 and 7. Checked 2026-09-30.
[^38]: After a server certificate change, the cluster nodes are restarted one at a time, letting each recover before restarting the next. Source: [Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - Loading Certificates and Keys Onto Expressway](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X15-5/cert-creation-use/exwy_b_cisco-expressway-certificate-creation-and-use-deployment-guide-x155/exwy_m_loading-certificates-and-keys-onto.html), Loading Certificates and Keys Onto Expressway > Changing an Existing Server Certificate, step 5. Checked 2026-09-30.
[^39]: Because public certificate validity keeps shrinking, an Expressway-E on a manually renewed public certificate will face a renewal and rolling restart several times a year, which makes ACME or a scripted process more attractive over time (inferred). Source: [Ballot SC081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods](https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/), Ballot summary, combined with the Changing an Existing Server Certificate procedure in cisco-exwy-x155-cert-loading. Checked 2026-09-30.
[^40]: The Expressway must be restarted for a newly uploaded server certificate to take effect. Source: [Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - Server Certificate Requirements for Unified Communications](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X15-5/cert-creation-use/exwy_b_cisco-expressway-certificate-creation-and-use-deployment-guide-x155/exwy_m_server-certificate-requirements-for-unified.html), Server Certificate Requirements for Unified Communications > note. Checked 2026-09-30.
[^41]: For MRA with a clustered Expressway-C, the Expressway-C certificate's subject alternative names must include the Expressway cluster name. Source: [Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - Server Certificate Requirements for Unified Communications](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X15-5/cert-creation-use/exwy_b_cisco-expressway-certificate-creation-and-use-deployment-guide-x155/exwy_m_server-certificate-requirements-for-unified.html), Expressway CSR Alternative Name Requirements for Unified Communications Features, row 'Expressway Cluster name'. Checked 2026-09-30.
[^42]: For MRA, the Expressway-C certificate's subject alternative names must include the Unified CM phone security profile names used by MRA endpoints. Source: [Mobile and Remote Access Through Cisco Expressway Deployment Guide (X15.2) - MRA Requirements and Prerequisites](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X15-2/mra/exwy_b_mra-deployment-guide-x152/exwy_m_requirements-for-mra.html), MRA Requirements and Prerequisites > Certificate Exchange Requirements. Checked 2026-09-30.
[^43]: The Expressway-C may need a new server certificate if IM and Presence chat node aliases are added or renamed. Source: [Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - Server Certificate Requirements for Unified Communications](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X15-5/cert-creation-use/exwy_b_cisco-expressway-certificate-creation-and-use-deployment-guide-x155/exwy_m_server-certificate-requirements-for-unified.html), Server Certificate Requirements for Unified Communications > note after SAN table. Checked 2026-09-30.
[^44]: For MRA, the Expressway-E certificate's subject alternative names must include the Unified CM registration domains. Source: [Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - Server Certificate Requirements for Unified Communications](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X15-5/cert-creation-use/exwy_b_cisco-expressway-certificate-creation-and-use-deployment-guide-x155/exwy_m_server-certificate-requirements-for-unified.html), Expressway CSR Alternative Name Requirements for Unified Communications Features, row 'Unified CM registrations domains'. Checked 2026-09-30.
[^45]: The Expressway-E certificate's subject alternative names must include the XMPP federation domains and, for federated group chat, the IM and Presence chat node aliases. Source: [Mobile and Remote Access Through Cisco Expressway Deployment Guide (X15.2) - MRA Requirements and Prerequisites](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X15-2/mra/exwy_b_mra-deployment-guide-x152/exwy_m_requirements-for-mra.html), MRA Requirements and Prerequisites > Certificate Exchange Requirements, Expressway-E SAN list. Checked 2026-09-30.
[^46]: Expressway validates received certificates against the Subject Alternative Name attribute, not the common name. Source: [Mobile and Remote Access Through Cisco Expressway Deployment Guide (X15.2) - MRA Configuration](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X15-2/mra/exwy_b_mra-deployment-guide-x152/exwy_m_basic-configuration.html), MRA Configuration > Unified Communications traversal zone settings, TLS verify subject name. Checked 2026-09-30.
[^47]: Unified CM phone security profile names placed in the Expressway-C SAN must be in FQDN format from X12.6. Source: [Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - Managing Expressway Certificates](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X15-5/cert-creation-use/exwy_b_cisco-expressway-certificate-creation-and-use-deployment-guide-x155/exwy_m_managing-expressway-certificates.html), Managing Expressway Certificates > Server certificate, Expressway-C SAN requirements. Checked 2026-09-30.
[^48]: For Expressway-E traversal zones facing a clustered Expressway-C, the Expressway-C cluster FQDN is entered as the TLS verify subject name. Source: [Cisco Expressway Cluster Creation and Maintenance Deployment Guide (X15.4) - Use Fully Qualified Domain Names to Form a Cluster](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X15-4/cluster_creation_maint/exwy_b_cisco-expressway-cluster-creation-and-maintenance-deployment-guide-x154/exwy_m_optional-use-fully-qualified-domain.html), Use Fully Qualified Domain Names to Form a Cluster > traversal zone note. Checked 2026-09-30.
[^49]: The peer address on the Expressway-C traversal client zone is checked against the Expressway-E certificate; if an IP address is used (not recommended), it must appear in the Expressway-E server certificate. Source: [Mobile and Remote Access Through Cisco Expressway Deployment Guide (X15.2) - MRA Configuration](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X15-2/mra/exwy_b_mra-deployment-guide-x152/exwy_m_basic-configuration.html), MRA Configuration > Configure a Unified Communications traversal zone on Expressway-C, Peer 1 to 6 address. Checked 2026-09-30.
[^50]: On the Expressway-E traversal server zone, TLS verify subject name is the name looked for in the traversal client's certificate and must be in that certificate's Subject Alternative Name. Source: [Mobile and Remote Access Through Cisco Expressway Deployment Guide (X15.2) - MRA Configuration](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X15-2/mra/exwy_b_mra-deployment-guide-x152/exwy_m_basic-configuration.html), MRA Configuration > Configure a Unified Communications traversal zone on Expressway-E, TLS verify subject name. Checked 2026-09-30.
[^51]: The Expressway trust store supports at most 1000 uploaded certificate authorities. Source: [Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - Loading Certificates and Keys Onto Expressway](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X15-5/cert-creation-use/exwy_b_cisco-expressway-certificate-creation-and-use-deployment-guide-x155/exwy_m_loading-certificates-and-keys-onto.html), Loading Certificates and Keys Onto Expressway > Managing the Trusted CA Certificate List, note. Checked 2026-09-30.
[^52]: The Expressway-C must trust the Unified CM CallManager and tomcat certificates, and the host name used to define each Unified CM node must be a SAN in its tomcat certificate. Source: [Cisco Expressway Administrator Guide (X15.3) - Unified Communications](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/admin_guide/X15-3/exwy_b_cisco-expressway-administrator-guide-x153/exwy_m_unified-communications.html), Unified Communications > certificate requirements for Unified CM. Checked 2026-09-30.
[^53]: Jabber clients validate the Expressway-E server certificate and must have the CA that signed it in their trusted CA list. Source: [Mobile and Remote Access Through Cisco Expressway Deployment Guide (X15.2) - MRA Requirements and Prerequisites](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X15-2/mra/exwy_b_mra-deployment-guide-x152/exwy_m_requirements-for-mra.html), MRA Requirements and Prerequisites > Certificate Requirements. Checked 2026-09-30.
[^54]: The Expressway-E trusted CA list must hold the full CA chain (root and intermediates) that signed the Expressway-C certificate; for the UC traversal zone, the root alone is not enough. Source: [Mobile and Remote Access Through Cisco Expressway Deployment Guide (X15.2) - MRA Requirements and Prerequisites](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X15-2/mra/exwy_b_mra-deployment-guide-x152/exwy_m_requirements-for-mra.html), MRA Requirements and Prerequisites > Certificate Exchange Requirements. Checked 2026-09-30.
[^55]: When a TLS connection requires certificate verification, the presented certificate must be signed by a CA in the Expressway trusted list with a full chain of trust. Source: [Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - Loading Certificates and Keys Onto Expressway](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X15-5/cert-creation-use/exwy_b_cisco-expressway-certificate-creation-and-use-deployment-guide-x155/exwy_m_loading-certificates-and-keys-onto.html), Loading Certificates and Keys Onto Expressway > Managing the Trusted CA Certificate List. Checked 2026-09-30.
[^56]: CA certificates are added in PEM format at Maintenance > Security > Trusted CA certificate using Append CA certificate, which keeps the existing list. Source: [Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - Loading Certificates and Keys Onto Expressway](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X15-5/cert-creation-use/exwy_b_cisco-expressway-certificate-creation-and-use-deployment-guide-x155/exwy_m_loading-certificates-and-keys-onto.html), Loading Certificates and Keys Onto Expressway > Managing the Trusted CA Certificate List. Checked 2026-09-30.
[^57]: Expressway-C and Expressway-E must each trust the other's certificate. Source: [Mobile and Remote Access Through Cisco Expressway Deployment Guide (X15.2) - MRA Configuration](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X15-2/mra/exwy_b_mra-deployment-guide-x152/exwy_m_basic-configuration.html), MRA Configuration > prerequisites for the Unified Communications traversal zone. Checked 2026-09-30.
[^58]: Reset to default CA certificate replaces every uploaded CA certificate with the system's original trusted CA list. Source: [Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - Loading Certificates and Keys Onto Expressway](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X15-5/cert-creation-use/exwy_b_cisco-expressway-certificate-creation-and-use-deployment-guide-x155/exwy_m_loading-certificates-and-keys-onto.html), Loading Certificates and Keys Onto Expressway > Managing the Trusted CA Certificate List. Checked 2026-09-30.
[^59]: For MRA, each Unified CM cluster must trust the Expressway-C certificate: the root CA that signed it goes into the CallManager-trust and tomcat-trust stores. Source: [Mobile and Remote Access Through Cisco Expressway Deployment Guide (X15.2) - MRA Requirements and Prerequisites](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X15-2/mra/exwy_b_mra-deployment-guide-x152/exwy_m_requirements-for-mra.html), MRA Requirements and Prerequisites > Certificate Exchange Requirements, Unified CM. Checked 2026-09-30.
[^60]: SIP TLS zones may fail to come up when certificates use an 8192-bit key; Cisco recommends 4096 bits. Source: [Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - Troubleshooting](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X15-5/cert-creation-use/exwy_b_cisco-expressway-certificate-creation-and-use-deployment-guide-x155/exwy_m_troubleshooting.html), Troubleshooting > 8192-bit key certificates. Checked 2026-09-30.
[^61]: MRA can fail if the uploaded private key file lacks a trailing newline character. Source: [Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - Troubleshooting](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X15-5/cert-creation-use/exwy_b_cisco-expressway-certificate-creation-and-use-deployment-guide-x155/exwy_m_troubleshooting.html), Troubleshooting > Mobile and Remote Access service failures. Checked 2026-09-30.
[^62]: A Unified Communications traversal zone is set up automatically with SIP TLS, TLS verify mode On and media encryption mode Force encrypted. Source: [Cisco Expressway Administrator Guide (X15.3) - Unified Communications](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/admin_guide/X15-3/exwy_b_cisco-expressway-administrator-guide-x153/exwy_m_unified-communications.html), Unified Communications > Unified Communications traversal zones. Checked 2026-09-30.
[^63]: Cisco recommends installing the CA certificate before installing the server certificate on Expressway. Source: [Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - Loading Certificates and Keys Onto Expressway](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X15-5/cert-creation-use/exwy_b_cisco-expressway-certificate-creation-and-use-deployment-guide-x155/exwy_m_loading-certificates-and-keys-onto.html), Loading Certificates and Keys Onto Expressway > Loading a Server Certificate and Private Key Onto Expressway. Checked 2026-09-30.
[^64]: If the CSR was generated outside Expressway, the matching unencrypted private key PEM file must be uploaded along with the server certificate. Source: [Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - Loading Certificates and Keys Onto Expressway](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X15-5/cert-creation-use/exwy_b_cisco-expressway-certificate-creation-and-use-deployment-guide-x155/exwy_m_loading-certificates-and-keys-onto.html), Loading Certificates and Keys Onto Expressway > Loading a Server Certificate and Private Key Onto Expressway. Checked 2026-09-30.
[^65]: The loaded server certificate can be viewed with Show (decoded) or Show (PEM file), and Reset to default server certificate restores the Expressway's original certificate. Source: [Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - View the Currently Uploaded Certificate](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X15-5/cert-creation-use/exwy_b_cisco-expressway-certificate-creation-and-use-deployment-guide-x155/exwy_m_view-the-currently-uploaded-certificate.html), View the Currently Uploaded Certificate. Checked 2026-09-30.
[^66]: For X15.5, Cisco recommends a private CA issuing both client and server EKUs for the client certificate, and says a public CA issuing server EKU only is acceptable for the server certificate. Source: [Navigate Client EKU Sunset with Expressway x15.5](https://www.cisco.com/c/en/us/support/docs/unified-communications/telepresence-video-communication-server-expressway/225693-navigate-client-eku-sunset-with.html), Recommendations > CA choice per store. Checked 2026-09-30.
[^67]: On X15.5 a certificate signed from a CSR without the client-authentication EKU cannot be uploaded to the client certificate store. Source: [Navigate Client EKU Sunset with Expressway x15.5](https://www.cisco.com/c/en/us/support/docs/unified-communications/telepresence-video-communication-server-expressway/225693-navigate-client-eku-sunset-with.html), Configure > client certificate CSR. Checked 2026-09-30.
[^68]: From X15.5, Expressway keeps separate server and client certificates: it presents the client certificate when it is the TLS client and the server certificate when it is the TLS server. Source: [Navigate Client EKU Sunset with Expressway x15.5](https://www.cisco.com/c/en/us/support/docs/unified-communications/telepresence-video-communication-server-expressway/225693-navigate-client-eku-sunset-with.html), Background > dual certificate stores. Checked 2026-09-30.
[^69]: X15.5 adds the CLI setting xConfiguration SIP TLS Certificate ExtendedKeyUsage Checking Mode (On or Off), which controls the client-EKU check on inbound SIP TLS connections. Source: [Navigate Client EKU Sunset with Expressway x15.5](https://www.cisco.com/c/en/us/support/docs/unified-communications/telepresence-video-communication-server-expressway/225693-navigate-client-eku-sunset-with.html), Configure > EKU validation toggle. Checked 2026-09-30.
[^70]: On X15.5 the server certificate is managed at Maintenance > Security > Server Certificate and the client certificate at Maintenance > Security > Client Certificate. Source: [Navigate Client EKU Sunset with Expressway x15.5](https://www.cisco.com/c/en/us/support/docs/unified-communications/telepresence-video-communication-server-expressway/225693-navigate-client-eku-sunset-with.html), Configure > certificate store navigation. Checked 2026-09-30.
[^71]: On X15.5 the server and client certificate stores share one trusted CA list, so the CAs that signed both certificates must be in it. Source: [Navigate Client EKU Sunset with Expressway x15.5](https://www.cisco.com/c/en/us/support/docs/unified-communications/telepresence-video-communication-server-expressway/225693-navigate-client-eku-sunset-with.html), Configure > trust store note. Checked 2026-09-30.
[^72]: Upgrading to X15.5 from X15.4 or earlier copies the existing server certificate into the client certificate store, so both start out identical. Source: [Navigate Client EKU Sunset with Expressway x15.5](https://www.cisco.com/c/en/us/support/docs/unified-communications/telepresence-video-communication-server-expressway/225693-navigate-client-eku-sunset-with.html), Upgrade behaviour. Checked 2026-09-30.
[^73]: With TLS verify enabled on a zone, the neighbor's FQDN or IP address is checked against the certificate holder name, so zone peer addresses should be FQDNs when certificates carry peer or cluster FQDNs. Source: [Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - Troubleshooting](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X15-5/cert-creation-use/exwy_b_cisco-expressway-certificate-creation-and-use-deployment-guide-x155/exwy_m_troubleshooting.html), Troubleshooting > SIP TLS negotiation failures on neighbor zones. Checked 2026-09-30.
[^74]: Expressway-E and Expressway-C must not share an address (including a shared NAT address) because the firewall cannot distinguish between them; Cisco does not support it. Source: [Mobile and Remote Access Through Cisco Expressway Deployment Guide (X15.2) - MRA Requirements and Prerequisites](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X15-2/mra/exwy_b_mra-deployment-guide-x152/exwy_m_requirements-for-mra.html), IP Addresses. Checked 2026-10-01.
[^75]: From Expressway X8.8 forward and reverse DNS records are required for Expressway-C; Expressway-E and Unified CM nodes; missing PTRs show as reverseDNSLookup exceptions or 'Certificate verification failed ... Invalid Hostname'. Source: [Resolve Collaboration Edge Most Common Issues](https://www.cisco.com/c/en/us/support/docs/unified-communications/expressway/118798-technote-cucm-00.html), Log In Issues > Expressway reverse DNS lookup fails. Checked 2026-10-01.
[^76]: The external firewall must allow inbound to Expressway-E for MRA: SIP TCP 5061; HTTPS TCP 8443; XMPP TCP 5222; media UDP 36002 to 59999. Source: [Mobile and Remote Access Through Cisco Expressway Deployment Guide (X15.2) - MRA Requirements and Prerequisites](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X15-2/mra/exwy_b_mra-deployment-guide-x152/exwy_m_requirements-for-mra.html), Firewall Configuration. Checked 2026-10-01.
[^77]: The internal firewall must allow outbound from Expressway-C to Expressway-E for MRA: SIP TCP 7001; traversal media UDP 2776 to 2777; XMPP TCP 7400; HTTPS tunneled over SSH TCP 2222. Source: [Mobile and Remote Access Through Cisco Expressway Deployment Guide (X15.2) - MRA Requirements and Prerequisites](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X15-2/mra/exwy_b_mra-deployment-guide-x152/exwy_m_requirements-for-mra.html), Firewall Configuration. Checked 2026-10-01.
[^78]: Expressway X15.5 splits certificates into a server store (presented on inbound TLS) and a client store (presented when Expressway initiates TLS); on upgrade from X15.4 the server certificate is copied into the client store. Source: [Navigate Client EKU Sunset with Expressway x15.5](https://www.cisco.com/c/en/us/support/docs/unified-communications/telepresence-video-communication-server-expressway/225693-navigate-client-eku-sunset-with.html), Key X15.5 Changes; Upgrade Behavior. Checked 2026-10-01.
[^79]: Cisco requires Expressway-E and Expressway-C to be upgraded to the same version (X15.4 or X15.5) for the Client Auth EKU fix. Source: [Prepare Expressway for Client Authentication EKU Sunset in Public CA Certificates](https://www.cisco.com/c/en/us/support/docs/unified-communications/expressway-series/225482-prepare-expressway-for-client.html), Expressway Software Fixes. Checked 2026-10-01.
[^80]: For MRA the Expressway-C server certificate SAN must include the phone security profile names used by MRA endpoints; the cluster name when clustered; and IM and Presence chat node aliases when federated group chat is used. Source: [Mobile and Remote Access Through Cisco Expressway Deployment Guide (X15.2) - MRA Requirements and Prerequisites](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X15-2/mra/exwy_b_mra-deployment-guide-x152/exwy_m_requirements-for-mra.html), CSR Requirements. Checked 2026-10-01.
[^81]: Jabber shows an invalid-certificate warning over MRA when the Expressway-E certificate is self-signed or does not list the external DNS domain in its SAN; the fix is a certificate from a CA Jabber trusts that includes those domains. Source: [Mobile and Remote Access Through Cisco Expressway Deployment Guide (X15.2) - MRA Troubleshooting](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X15-2/mra/exwy_b_mra-deployment-guide-x152/exwy_m_mra-troubleshooting.html), Cisco Jabber Sign-In Issues > Jabber popup warns about invalid certificate. Checked 2026-10-01.
[^82]: After Unified CM cluster or node configuration changes Expressway-C must rediscover all Unified CM and IM and Presence Service nodes under Configuration > Unified Communications or MRA communication problems can follow. Source: [Mobile and Remote Access Through Cisco Expressway Deployment Guide (X15.2) - MRA Troubleshooting](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X15-2/mra/exwy_b_mra-deployment-guide-x152/exwy_m_mra-troubleshooting.html), General Techniques > Expressway-C Synchronization to Unified CM. Checked 2026-10-01.
[^83]: Cisco's MRA troubleshooting guidance starts with checking Status > Alarms on both Expressway-C and Expressway-E and reviewing the Status > Unified Communications page. Source: [Mobile and Remote Access Through Cisco Expressway Deployment Guide (X15.2) - MRA Troubleshooting](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/expressway/config_guide/X15-2/mra/exwy_b_mra-deployment-guide-x152/exwy_m_mra-troubleshooting.html), General Techniques > Checking Alarms and Status. Checked 2026-10-01.