Are the expressway-C server using self-signed certificates (I doubt it because 
you said they are multi-san)?

Generally, CUCM doesn’t need to trust the identity certificate (unless it is 
self signed). In all other cases, CUCM needs to trust the certificate authority 
the signed the expressway-c certificates.

If for example, GoDaddy signed the SSL certificates for the Expressway-C, CUCM 
just needs to trust the GoDaddy certificate authority chain.

Sent from my iPhone

On Oct 14, 2019, at 17:07, ROZA, Ariel <> wrote:

Hi, Guys

I am renewing the certificates in an Expressway X8.10.1 cluster. But I am 
running into a conflict between the official documentation and how CUCM works.

I have set both Expressway-C certificates to use the Cluster name for the 
Common Name and each server´s name as a SAN, as the oficial guide states.
But when I load both signed certificates into CUCM trust stores, it shows only 
one of the certificates, instead of both, as CUCM uses the CN tu build its 
listo f certs, and both ExpC´s CN is the same (Although they are two diferente 

So, I started to re-read all related documents I could find and I found some 
contradictions that I do not now how to solve.

On one hand, I have the official “Certificate  Creation and Deployment Guide” 
that states:

“A certificate identifies the Expressway. It contains names by which it is 
known and to which traffic is routed. If the Expressway is known by multiple 
names for these purposes, such as if it is part of a cluster, this must be 
represented in the X.509 subject data, according to the guidance of RFC5922. 
The certificate must contain the FQDN of both the Expressway itself and of the 
cluster. The following lists show what must be included in the X.509 subject, 
depending on the deployment model chosen.
If the Expressway is not clustered:
■ Subject Common Name = FQDN of Expressway
■ Subject Alternate Names = leave blank*
If the Expressway is clustered, with individual certificates per Expressway:
■ Subject Common Name = FQDN of cluster
■ Subject Alternate Name = FQDN of Expressway peer, FQDN of cluster*<>

On the other hand I have the “Configure and Troubleshoot Collaboration Edge 
(MRA) Certificates“ that says:

Cluster Certificates

It is strongly recommended that if you have a cluster of Expressway-C or 
Expressway-E servers for redundancy that you generate a separate CSR for each 
server and have it signed by a CA.  Most deployments will use the server name 
for the subject and list all peers and the cluster ID as SANs.  It is possible 
for you to use the cluster-id as the subject to use the same certificate for 
all nodes in the cluster, therefore avoiding the cost of multiple certs signed 
by a public CA.  If absolutely necessary, this can be done with the following 
process or by using OpenSSL to generate both the private key and CSR manually:

Step 1.  Generate a CSR on the master of the cluster and configure it to list 
the cluster-alias as the subject.  Add all peers in the cluster as alternative 
names, along with all other required SANs.

Step 2.  Sign this CSR and upload to the master peer.

Step 3.  Log into the master as root and download the private key located in 

Step 4.  Upload both the signed certificate and matching private key to each 
other peer in the cluster.

Note: This is not recommended for the following reasons:
1. It is a security risk because all peers are using the same private key.  If 
one is somehow compromised an attacker can decrypt traffic from any of the 
2.  If a change needs to be made to the certificate, this entire process must 
be followed again rather than a simple CSR generation and signing.<>

So, one says to use the cluster name, the other says the opposite. And I have 
the CUCM showing me only one cert intead of two.

What should I do? Re-sign both certificates with the peer name as CN and 
cluster as SAN and be done with it? Ori s there a legitimate way to use the 
cluster name and not have issues with CUCM?

Right now, the Expressway cluster is in service, because I left the cluster´s 
main peer certificate showing in CUCM, but as far as I know, the backup peer 
won´t work.


Ariel Roza
Support & Maintenance Engineer | Latam
t: +54 11 5282-0458 / c: +54 11 5017-4417 / webex:<>
Av. Belgrano 955 – Piso 20 – CABA – Argentina – C1092AAJ<>
Business and technology working as one
Logicalis Argentina S.A. solo puede ser obligado por sus representantes legales 
conforme los límites establecidos en el acto constitutivo y la legislación en 
El contenido del presente correo electrónico e inclusive sus anexos contienen 
información confidencial.
El mismo no puede ser divulgado y/o utilizado por cualquiera otro distinto al 
destinatario, ni puede ser copiado de cualquier forma

cisco-voip mailing list;data=02%7C01%7C%7C947276c8718c41c85c7608d750ea89df%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637066840572677369&amp;sdata=kS%2FWccGQz25%2FQb%2FN3R7%2F1ZlD1%2FDcLCbKeHy0N2oZ1Zs%3D&amp;reserved=0
cisco-voip mailing list

Reply via email to