cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1576
Views
0
Helpful
7
Replies

Conductor XC4.3.2 clustering via TLS

an0000001111
Level 1
Level 1

Hi Community members,

 

I'm wondering if anyone of you has some experience with clustering the conductors via TLS.

With this major update the TLS enforcement for the verification mode has been activated.

 

However, we used in the past IPSec for clustering two conductors and wanted to switch to TLS.

We requested new certificates with an additional X509 IP entry.

 

When leaving the cluster on "Permisssive" verification mode everything works fine. We just get the warning that the server allows an unsecure clustering.

When switching on the primary peer to "Enforce" for using TLS, the local IP OR the FQDN (I know that is not recommended) and certificate are valid. The remote peer is shown as invalid and clustering fails.

The remote peer takes over the change of verification and shows "Enforce" after a page refresh.

The first entry (of the primary peer) is shown as invalid while the second entry (its own IP) is shown as valid.

Both systems can perform a DNS lookup to the remote peer, ping and trace it.

 

Has anyone encountered the same issue? Or did anyone clustered conductors via TLS successfully?

1 Accepted Solution

Accepted Solutions

Hi Patrick,

 

thanks for your reply. We're not using wildcards in the certificate(s).

Cisco described to work here with IP adresses. Therefore we requested a new certificate with an additional value for the IP adress.

The host name is identical to the CN in the certificate.

The mystery of this issue is that when we're running the cluster in permissive mode and use the FQDN instead of the IP adress then both peers are able to successfull validate the certificates of both peers. When switching it to enforce mode the remote peer certificate is not successfull validated. In the diagnostic log then comes this:

 

Detail="Invalid TLS certificate; handshake failed" Reason="invalid_ext_key_usage" Certificate="

 

Any further ideas?

View solution in original post

7 Replies 7

an0000001111
Level 1
Level 1
Maybe as a short hint:
The upgrade has been done according the guide lines.
Long story short: Permissive mode is working. Enforce mode is not working. All certificates have been generated new and are valid.
When in Permissive mode the comment appears next to the peers (Certificate valid). When switching to Enforce mode they are no longer valid. Why?????

Make sure the Common Name (CN) of the certificate you're uploading to Conductor matches the host name under System > DNS, also make sure that this same host name is what is entered as the cluster peer under System Clustering. If you're using a wildcard certificate, they aren't supported by Conductor.

Hi Patrick,

 

thanks for your reply. We're not using wildcards in the certificate(s).

Cisco described to work here with IP adresses. Therefore we requested a new certificate with an additional value for the IP adress.

The host name is identical to the CN in the certificate.

The mystery of this issue is that when we're running the cluster in permissive mode and use the FQDN instead of the IP adress then both peers are able to successfull validate the certificates of both peers. When switching it to enforce mode the remote peer certificate is not successfull validated. In the diagnostic log then comes this:

 

Detail="Invalid TLS certificate; handshake failed" Reason="invalid_ext_key_usage" Certificate="

 

Any further ideas?

The keyword for clustering Conductors via TLS is: mTLS !

 

With mTLS it was working directly. Previously I was using a certificate for web server. As both are working as servers it can't work as they were expecting from the remote peer a certificate which was for web clients. This didn't fit.

So maybe Cisco updates its documentation. It seems that the description of the cluster process is copied & pasted from the VCS cluster guide. There is no cluster name configureable on the Conductor systems.

I agree regarding the certificate creation guide, since Conductor doesn't provide a place for a cluster FQDN like VCS does. I checked Conductor and when you generate a CSR, the only options are:

  • CN: FQDN of Conductor (the one generating the CSR)
  • SAN: FQDN of Conductor plus FQDNs of all peers in the cluster

Have you tried a certificate with the above CN and SAN entries?

Hi Patrick,

 

I added a further value as CN entry -> the ip address of the device and repeated that for the 2nd peer.

With a signed certificate for mTLS I've benn able to cluster both systems.

I was just wondering that the clustering via FQDN obviously worked but in the end left a mess on the TMS.

Now I know why Cisco requests to use IP addresses.

On the TMS, with FQDN clustered conductors, TMS was determining that the 2nd peer is the master of the cluster. Additionally in the TMS navigator both conductors were displayed with the host name of the 2nd peer but showed the correct FQDN. In the end TMS got pretty confused and was not able to communicate with the conductors. I was receiving one error message after the other when trying to save or work with the conductors via TMS. Next to it TMS was changing the booking values (denied booking and SIP incoming/outgoing) which had manually to get activated again.

 

Now everything works:

mTLS - certificate should have a further CN entry containing the IP address

Conductor - Clustering with IP and enforced TLS validation

TMS - reconfigured the primary conductor which applied the config to the 2nd peer.

Glad you were able to get it sorted out and working!

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: