Re: [cisco-voip] Expressway cluster certificates.

[Ryan Huff]

So having more certs than need in the Truststore generally wont cause issues, 
it’s just one more certificate that can potentially be trusted.

As long as the new certificates are signed by the same internal CA as the one 
that is currently in the truststore for CUCM (all nodes), then you shouldn’t 
need to have the identity certificates in the truststore.

One reason that may have been done is because the original person wasn’t able 
to get CUCM to properly recognize the internal CA and trust certificates signed 
by it.

This could happen if the CA chain was uploaded incorrectly. The root should be 
uploaded first, then any intermediates.

Sent from my iPhone

On Oct 14, 2019, at 17:40, ROZA, Ariel  wrote:


Hi Ryan,

Both Expressway servers are signed by the internal CA. I have uploaded the root 
and intermediate certificates, too.
But I am renewing the certificates on an existing cluster, and whoever 
instelled it, they manually added the ExpC certs into tomcat-trust.

So, I understand that it would be safe to remove the ExpC certs from 
tomcat-trust and everything would be working fine?
What about the use the cluster name/don´t use the cluster name contradiction?

Thanks,

Ariel.

De: Ryan Huff 
Enviado el: lunes, 14 de octubre de 2019 18:14
Para: ROZA, Ariel 
CC: cisco-voip (cisco-voip@puck.nether.net) 
Asunto: Re: [cisco-voip] Expressway cluster certificates.

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


___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Expressway cluster certificates.

[ROZA, Ariel]

Hi Ryan,

Both Expressway servers are signed by the internal CA. I have uploaded the root 
and intermediate certificates, too.
But I am renewing the certificates on an existing cluster, and whoever 
instelled it, they manually added the ExpC certs into tomcat-trust.

So, I understand that it would be safe to remove the ExpC certs from 
tomcat-trust and everything would be working fine?
What about the use the cluster name/don´t use the cluster name contradiction?

Thanks,

Ariel.

De: Ryan Huff 
Enviado el: lunes, 14 de octubre de 2019 18:14
Para: ROZA, Ariel 
CC: cisco-voip (cisco-voip@puck.nether.net) 
Asunto: Re: [cisco-voip] Expressway cluster certificates.

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


___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Expressway cluster certificates.

[Ryan Huff]

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

[cisco-voip] Expressway cluster certificates.

[ROZA, Ariel]

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@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
Business and technology working as one
[cid:image003.jpg@01D582BA.3104E530][cid:image004.png@01D582B8.04178020][cid:image005.png@01D582B8.04178020][cid:image006.png@01D582B8.04178020][cid:image007.png@01D582B8.04178020][cid:image008.png@01D582B8.04178020][cid:image009.png@01D582B8.04178020]
[cid:image010.jpg@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.