[cisco-voip] Expressway cluster certificates.

Mon Oct 14 17:07:10 EDT 2019

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 certificates)

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*

https://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/expressway/config_guide/X8-10/Cisco-Expressway-Certificate-Creation-and-Use-Deployment-Guide-X8-10.pdf

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 /tandberg/persistent/certs.

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 servers.
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.

https://www.cisco.com/c/en/us/support/docs/unified-communications/expressway/213872-configure-and-troubleshoot-collaboration.html#anc17

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.

TIA,

[cid:image001.png at 01D582B8.04178020]Ariel Roza
Support & Maintenance Engineer | Latam
t: +54 11 5282-0458 / c: +54 11 5017-4417 / webex: https://logicalis-la.webex.com/join/ariel.roza
Av. Belgrano 955 – Piso 20 – CABA – Argentina – C1092AAJ
www.la.logicalis.com<http://www.la.logicalis.com/>
Business and technology working as one
[cid:image003.jpg at 01D582BA.3104E530][cid:image004.png at 01D582B8.04178020][cid:image005.png at 01D582B8.04178020]<https://www.instagram.com/logicalislatam/>[cid:image006.png at 01D582B8.04178020]<https://www.facebook.com/logicalislatam>[cid:image007.png at 01D582B8.04178020]<https://twitter.com/logicalislatam>[cid:image008.png at 01D582B8.04178020]<https://ar.linkedin.com/company/logicalis-latam>[cid:image009.png at 01D582B8.04178020]<https://www.youtube.com/logicalislatam>
[cid:image010.jpg at 01D582B8.04178020]
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 vigor.
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20191014/7ded3e65/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 12524 bytes
Desc: image001.png
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20191014/7ded3e65/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 824 bytes
Desc: image002.png
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20191014/7ded3e65/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 6706 bytes
Desc: image004.png
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20191014/7ded3e65/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.png
Type: image/png
Size: 1600 bytes
Desc: image005.png
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20191014/7ded3e65/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image006.png
Type: image/png
Size: 502 bytes
Desc: image006.png
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20191014/7ded3e65/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image007.png
Type: image/png
Size: 942 bytes
Desc: image007.png
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20191014/7ded3e65/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image008.png
Type: image/png
Size: 776 bytes
Desc: image008.png
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20191014/7ded3e65/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image009.png
Type: image/png
Size: 493 bytes
Desc: image009.png
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20191014/7ded3e65/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image010.jpg
Type: image/jpeg
Size: 2051 bytes
Desc: image010.jpg
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20191014/7ded3e65/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 1229 bytes
Desc: image003.jpg
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20191014/7ded3e65/attachment-0001.jpg>