cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2878
Views
5
Helpful
8
Replies

Certificate names for TLS from cluster

exMSW4319
Level 3
Level 3

I'm looking at setting up inbound and outbound TLS for my cluster of two C-class machines. There are some very good TAC articles and a number of threads on the subject of TLS, but I've run into an apparent problem over the correct choice of certificate name.

 

I currently have two certificates, one for each machine. That doesn't really work for clustering which requires that one particular certificate be chosen. This means that either one machine or the other will be trying to use the "wrong" certificate. I can override the clustering and set individual settings per machine, but I'm nervous about the impact that would have. In an override, I have the choice of starting with default settings (factory?) or copying from my existing cluster. If I elect to copy, have I effectively broken the cluster for the purposes of configuration?

 

I'd much sooner continue running as a full cluster. Several of the discussion threads mention the use of a SAN certificate that would presumably include node1.my-domain and node2.my-domain, but I've also seen references to a certificate profile. Is there a generic third name that must be included in the SAN and then used in the cluster configuration?

 

Fortunately my certificates are nearly up for renewal, but I'd much sooner get this right first time.

1 Accepted Solution

Accepted Solutions

Hey exmsw4319,

As Ken shared as well - the certificate profile name is for your reference only - it will not be mentioned anywhere within your TLS/SSL traffic.

Generally it is recommended to have the Certificate Profile name the same across the board of all machines, from machine overrides or just at the cluster. This consistency makes it easier to keep settings at the same level across the board.

However as you're looking at moving certificates to complete cluster level and to keep listeners also at a cluster level (unless machine is required), keep the certificate profile name static - Profile names can be anything for your own reference - the important part of the certificate for TLS/SSL is the CN (common name).
As you're using a SAN; the CN should be for port 25 TLS traffic, the MX record names of your devices.
For HTTPS traffic, you should include the internal hostname that you're connecting to for full validation.

clusterconfig setname is just renaming your cluster.

I hope this helps,
Matthew

View solution in original post

8 Replies 8


@exMSW4319 wrote:

I'm looking at setting up inbound and outbound TLS for my cluster of two C-class machines. There are some very good TAC articles and a number of threads on the subject of TLS, but I've run into an apparent problem over the correct choice of certificate name.

 

I currently have two certificates, one for each machine. That doesn't really work for clustering which requires that one particular certificate be chosen. This means that either one machine or the other will be trying to use the "wrong" certificate. I can override the clustering and set individual settings per machine, but I'm nervous about the impact that would have. In an override, I have the choice of starting with default settings (factory?) or copying from my existing cluster. If I elect to copy, have I effectively broken the cluster for the purposes of configuration?


No, you aren't breaking the cluster... that just sets the page you're on to "Machine mode" with the current configuration of the cluster.  In this case that's just the Listener config page for the specific listener.  (that's where you pick which cert to use).

 


I'd much sooner continue running as a full cluster. Several of the discussion threads mention the use of a SAN certificate that would presumably include node1.my-domain and node2.my-domain, but I've also seen references to a certificate profile. Is there a generic third name that must be included in the SAN and then used in the cluster configuration?


No, you don't need a "third name".  But depending upon the SAN cert you pick, you could probably get one with both external names, and both of the management interface names, and use it in all of those places...

 

We use a wildcard cert for our external interfaces. 

 

Ta, Ken. I'll give that a spin and see how it does.

 

I don't think I could get any certificate for our internal name that isn't self-signed (and therefore relatively worthless) as our internal domain space name isn't fit for public consumption.

Ah...yes... right, forgot that CAs aren't issuing for non-live names anymore...




Mathew Huynh
Cisco Employee
Cisco Employee

Hello,

 

Ken has hit the nail on the head here - that is one of the recommended ways to go around it.

If your certificates are unique on the CN name - then you would need to override either at the certificate level, or listener level - whichever makes more sense for you.

 

IF your certificate has a name that is the same. For example: 

On ESA1 - machine override
Certificate profile name is "Mail_cert" but the common name is : esa1.testdomain.com
on ESA2- Machine override

Certificate profile name is "Mail_cert" but the common name is : esa2.testdomain.com


Then you can keep your listener on Cluster level and just make it reference "Mail_cert" and it'll use the unique cert per machine itself.

 

If your cert profile name is unique, at the certificate level - then you will also need to do a machine override at the listener level to meet this requirement.

 

I hope this clears it up a bit more :)

 

Regards,

Matthew

Currently I have TLS working (inbound and outbound) on my old certificates, but with config variation pages for my listeners and the destination controls to accommodate my machine-unique certificates. It's a little more fiddly than I should have liked, as it's easy to do work in the wrong mode when using the GUI but the rest of the cluster configuration is definitely behaving itself, with other changes being duly replicated.

 

My management is keen to return to full clustering so I'll be shopping for a SAN in the near future. Does the certificate profile name have to match the cluster name, or is it sufficient for the SAN to contain CNs matching my hostnames?

 

I've also seen the clusterconfig setname command. Is this really just going to rename the entire cluster, or does it effectively tear down the existing cluster and require the administrator to add the nodes back in again? 

the profile name is for YOUR consumption, as a human....  the SMTP/TLS connection doesn't see it...

 

Assuming that the other end verifying cert and host name (not everyone does) the cert just has to have a subject or subject alternative name that matches the host name the listener has.

Hey exmsw4319,

As Ken shared as well - the certificate profile name is for your reference only - it will not be mentioned anywhere within your TLS/SSL traffic.

Generally it is recommended to have the Certificate Profile name the same across the board of all machines, from machine overrides or just at the cluster. This consistency makes it easier to keep settings at the same level across the board.

However as you're looking at moving certificates to complete cluster level and to keep listeners also at a cluster level (unless machine is required), keep the certificate profile name static - Profile names can be anything for your own reference - the important part of the certificate for TLS/SSL is the CN (common name).
As you're using a SAN; the CN should be for port 25 TLS traffic, the MX record names of your devices.
For HTTPS traffic, you should include the internal hostname that you're connecting to for full validation.

clusterconfig setname is just renaming your cluster.

I hope this helps,
Matthew

Thanks to everyone who contributed to this and earlier threads on TLS and clustering. We're now back up on a single SAN certificate and my TLS charts are turning a pleasing shade of blue. Deleting the local config variation pages for our old certificates was also a breeze; I'm very impressed with the clustering on Asyncos.

 

 

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: