02-08-2018 08:06 AM - edited 03-08-2019 07:33 PM
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.
Solved! Go to Solution.
02-19-2018 04:00 PM
02-08-2018 08:21 AM
@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.
02-08-2018 08:49 AM
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.
02-08-2018 08:52 AM
02-09-2018 08:12 PM
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
02-19-2018 07:37 AM
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?
02-19-2018 07:46 AM
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.
02-19-2018 04:00 PM
03-21-2018 09:23 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide