Cert Signing for Common SAN Entry on Two servers

Help
1

Hi Folks, need some help in understanding something about singing the certificates for a clustered (Active - Active) environment.

Scenario:

example.com (service domain).

Server 1 Certificate details
CN= server1.example.com
SAN Entries Needed (collab.example.com)

Server 2 Certificate details
CN= server2.example.com
SAN Entries Needed (collab.example.com)

SAN collab.example.com is important for hosted service to work as the clients will verify this SAN entry when the certificate is presented by server to the client. Also as mentioned its an Active-Active Cluster hence client can land on any of the server.

For Certificate Sign In to work, i know that all SAN entries has to be resolvable from External and LE’s should be able to reach this servers over port 80.

I can get the certificate SIGNED on one of the server as normal, however as mentioned some SAN Entries are common and its important to have it on both the servers certificate which are running in the cluster.

So i can create a an entry on DNS (for e.g.) as below:

server1.example.com 192.168.1.100
collab.example.com 192.168.1.100

And then get the Server 1 CSR signed.

After this i change the DNS entry something like below:

server1.example.com 192.168.1.100
server2.example.com 192.168.1.101
collab.example.com 192.168.1.100
collab.example.com 192.168.1.101

Question
When i get the second server certificate signed, LE’s can connect to any of the server (after DNS Resolution) for validation of (collab.example.com). How to make sure that LE server connect to the Originator server, which in this case is server2.example.com.

If not, what is the best practice for such environments? and how one can overcome if its an limitation?

Regards,
Alok

2

You can't.

Have a look at Stateless Mode · acmesh-official/acme.sh Wiki · GitHub . You don't necessarily need to use acme.sh or nginx, just make sure each of your originators uses the same ACME account key.

Besides that, you can try use DNS authentication instead, but stateless HTTP is a lot simpler and requires less privilege.

3

Well, the issue i don’t have an privilege on my end to modify anything. The product uses certbot with hard-coded (customized) validation with HTTP only. But if its not possible then probably it calls for an enhancement on the code at our end to allow to choose different validation modes, For e.g. DNS based.

4

i would recommend you go down the wildcard certificate path

You will need to use the DNS challenge for this

Your servers currently resolve to internal IP ranges (not reachable by internet)

With a wildcard *.example.com you can protect all your servers (server1.example.com server2.example.com collaboration.com) even if some of them are not internet reachable

5

Hi, Thanks for the response. The ip’s i posted are just for an example.

In reality this ip’s would be publicly reachable as this servers will be hosted in DMZ.

6

Hi,

I did some reading i found that creating a CNAME record might help in this situation.

I also verified it seems the certbot client we use on software code is able to do DNS record validation.

so I believe this should resolve the issue.

Regards,
Alok

7

I don’t think that CNAMEs are useful to you in this case.

You can just use the normal DNS challenge.

As long as each master is able to create and remove _acme-challenge TXT records in your zone, you’re all set.

8

Thanks for the response. I am not very good at DNS except knowing the basic components of basic component of Zones and records etc.

Whatever i read for DNS validation you need to manually create TXT Record for domain validation. I also read and you also mentioned about Creating/Removing the _acme-challenge TXT records although not sure how it is done automatically. If you can throw some light on that or point to a doc where it is mentioned in detailed?

I also came across to the below thread, and it seems this person has done same requirement and using the same Cisco Product as me and used CNAME to make it work.

I appreciate all your responses. +5

Thanks & Regards,
Alok

9

Doing it manually is a last resort. Usually it's done completely automatically, and can scale to a practically infinite number of servers.

But it depends on who hosts your DNS. For example, if you use Cloudflare for DNS hosting, you'd use certbot-dns-cloudflare, if it was AWS Route53, you'd use certbot-dns-route53 and so on.

10

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.