Configuration · guide

Setting up certificates on Cisco Expressway

Cisco Expressway

Verified 2026-10-01 · 83 sources · tier 1–2

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

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

Pick your answers to see only your path. Nothing is sent anywhere until you make a plan.

Which Expressway release runs on your Expressway pair?

Which CA signs the Expressway-C certificate?

How will the Expressway-E obtain its certificate?

Which services run across this Expressway pair?

Are the Expressway nodes clustered?

Five questions. One permanent page you can send to your manager.

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.

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.
Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - Using ACME on Expressway-E · 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.
Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - Using ACME on Expressway-E · 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.
Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - Using ACME on Expressway-E · 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.
Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - Using ACME on Expressway-E · 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.
Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - Using ACME on Expressway-E · 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.
Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - Using ACME on Expressway-E · 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.
Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - About This Guide · 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.
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.
Cisco Expressway Cluster Creation and Maintenance Deployment Guide (X15.4) - Clustering Requirements · 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.
Cisco Expressway Cluster Creation and Maintenance Deployment Guide (X15.4) - Use Fully Qualified Domain Names to Form a Cluster · 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.
Cisco Expressway Cluster Creation and Maintenance Deployment Guide (X15.4) - Use Fully Qualified Domain Names to Form a Cluster · 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.
Cisco Expressway Cluster Creation and Maintenance Deployment Guide (X15.4) - Clustering Requirements · 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.
Cisco Expressway Cluster Creation and Maintenance Deployment Guide (X15.4) - Use Fully Qualified Domain Names to Form a Cluster · 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.
Generate CSR and Upload Signed Certificate to VCS/Expressway Servers · 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.
Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - Generating a Certificate Signing Request · 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>.
Generate CSR and Upload Signed Certificate to VCS/Expressway Servers · 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.
Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - Generating a Certificate Signing Request · 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.
Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - Generating a Certificate Signing Request · 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.
Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - Generating a Certificate Signing Request · 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.
Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - Generating a Certificate Signing Request · 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.
Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - Generating a Certificate Signing Request · 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.
Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - Generating a Certificate Signing Request · 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.
Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - About This Guide · 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.
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 · 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.
Prepare Expressway for Client Authentication EKU Sunset in Public CA Certificates · 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.
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 · 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
Prepare Expressway for Client Authentication EKU Sunset in Public CA Certificates · 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
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 · Problem Description · Checked 2026-09-30
29
For the EKU remediation, Expressway-E and Expressway-C must both be upgraded to matching versions.
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 · 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.
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 · 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.
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 · 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.
Prepare Expressway for Client Authentication EKU Sunset in Public CA Certificates · 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.
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 · 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.
Prepare Expressway for Client Authentication EKU Sunset in Public CA Certificates · 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.
Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - Loading Certificates and Keys Onto Expressway · 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.
Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - Loading Certificates and Keys Onto Expressway · 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.
Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - Loading Certificates and Keys Onto Expressway · 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.
Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - Loading Certificates and Keys Onto Expressway · 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
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.
Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - Server Certificate Requirements for Unified Communications · 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.
Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - Server Certificate Requirements for Unified Communications · 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.
Mobile and Remote Access Through Cisco Expressway Deployment Guide (X15.2) - MRA Requirements and Prerequisites · 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.
Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - Server Certificate Requirements for Unified Communications · 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.
Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - Server Certificate Requirements for Unified Communications · 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.
Mobile and Remote Access Through Cisco Expressway Deployment Guide (X15.2) - MRA Requirements and Prerequisites · 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.
Mobile and Remote Access Through Cisco Expressway Deployment Guide (X15.2) - MRA Configuration · 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.
Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - Managing Expressway Certificates · 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.
Cisco Expressway Cluster Creation and Maintenance Deployment Guide (X15.4) - Use Fully Qualified Domain Names to Form a Cluster · 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.
Mobile and Remote Access Through Cisco Expressway Deployment Guide (X15.2) - MRA Configuration · 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.
Mobile and Remote Access Through Cisco Expressway Deployment Guide (X15.2) - MRA Configuration · 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.
Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - Loading Certificates and Keys Onto Expressway · 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.
Cisco Expressway Administrator Guide (X15.3) - Unified Communications · 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.
Mobile and Remote Access Through Cisco Expressway Deployment Guide (X15.2) - MRA Requirements and Prerequisites · 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.
Mobile and Remote Access Through Cisco Expressway Deployment Guide (X15.2) - MRA Requirements and Prerequisites · 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.
Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - Loading Certificates and Keys Onto Expressway · 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.
Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - Loading Certificates and Keys Onto Expressway · 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.
Mobile and Remote Access Through Cisco Expressway Deployment Guide (X15.2) - MRA Configuration · 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.
Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - Loading Certificates and Keys Onto Expressway · 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.
Mobile and Remote Access Through Cisco Expressway Deployment Guide (X15.2) - MRA Requirements and Prerequisites · 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.
Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - Troubleshooting · Troubleshooting > 8192-bit key certificates · Checked 2026-09-30
61
MRA can fail if the uploaded private key file lacks a trailing newline character.
Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - Troubleshooting · 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.
Cisco Expressway Administrator Guide (X15.3) - Unified Communications · Unified Communications > Unified Communications traversal zones · Checked 2026-09-30
63
Cisco recommends installing the CA certificate before installing the server certificate on Expressway.
Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - Loading Certificates and Keys Onto Expressway · 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.
Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - Loading Certificates and Keys Onto Expressway · 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.
Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - View the Currently Uploaded Certificate · 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.
Navigate Client EKU Sunset with Expressway x15.5 · 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.
Navigate Client EKU Sunset with Expressway x15.5 · 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.
Navigate Client EKU Sunset with Expressway x15.5 · 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.
Navigate Client EKU Sunset with Expressway x15.5 · 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.
Navigate Client EKU Sunset with Expressway x15.5 · 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.
Navigate Client EKU Sunset with Expressway x15.5 · 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.
Navigate Client EKU Sunset with Expressway x15.5 · 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.
Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - Troubleshooting · 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.
Mobile and Remote Access Through Cisco Expressway Deployment Guide (X15.2) - MRA Requirements and Prerequisites · 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'.
Resolve Collaboration Edge Most Common Issues · 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.
Mobile and Remote Access Through Cisco Expressway Deployment Guide (X15.2) - MRA Requirements and Prerequisites · 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.
Mobile and Remote Access Through Cisco Expressway Deployment Guide (X15.2) - MRA Requirements and Prerequisites · 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.
Navigate Client EKU Sunset with Expressway x15.5 · 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.
Prepare Expressway for Client Authentication EKU Sunset in Public CA Certificates · 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.
Mobile and Remote Access Through Cisco Expressway Deployment Guide (X15.2) - MRA Requirements and Prerequisites · 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.
Mobile and Remote Access Through Cisco Expressway Deployment Guide (X15.2) - MRA Troubleshooting · 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.
Mobile and Remote Access Through Cisco Expressway Deployment Guide (X15.2) - MRA Troubleshooting · 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.
Mobile and Remote Access Through Cisco Expressway Deployment Guide (X15.2) - MRA Troubleshooting · General Techniques > Checking Alarms and Status · Checked 2026-10-01

Documents

tier 1 standards and regulators

Cisco Expressway Certificate Creation and Use Deployment Guide (X15.5) - Server Certificate Requirements for Unified Communications

Cisco Systems · 2026-07-29 · accessed 2026-09-24

tier 2 current vendor documentation

Cisco Expressway Cluster Creation and Maintenance Deployment Guide (X15.4) - Use Fully Qualified Domain Names to Form a Cluster

Cisco Systems · 2026-02-09 · accessed 2026-09-30

tier 2 current vendor documentation

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

Cisco Systems · 2026-06-01 · accessed 2026-09-24

tier 2 current vendor documentation

Cite this page

APA

WarmTransfer. (2026, October 1). Setting up certificates on Cisco Expressway. WarmTransfer. https://warmtransfer.net/guides/expressway-certificate-setup

BibTeX

@misc{warmtransfer-expressway-certificate-setup,
  title  = {Setting up certificates on Cisco Expressway},
  author = {{WarmTransfer}},
  year   = {2026},
  url    = {https://warmtransfer.net/guides/expressway-certificate-setup},
  note   = {Verified 2026-10-01}
}