Multiple backend servers renewal

I have a domain (e.g. example.com) which is resolved to different IPs (depends on client location). E.g. from America it’s seen as 1.1.1.1, from Europe it’s seen as 2.2.2.2. Due to this setup it’s quite tricky to pass domain validation in non-american location, as validation letsencrypt servers are in America region and resolve my domain to 1.1.1.1 only.

For initial setup I got certificate on American server and manually copied it to European. Though it’s really painful process (especially if it’s a bit more than just 2 servers).

So I’m trying to find the way to make it more smooth.

The only idea is to configure region subdomains (e.g. europe.example.com which will always be resolved as 2.2.2.2) and request certificate mainly for it (and include there a main domain as well, but not as a main one).

E.g. execute from European server:

certbot certonly  --standalone --d europe.example.com -d example.com -d www.example.com

and from American server:

certbot certonly  --standalone --d america.example.com -d example.com -d www.example.com

Though I’m not sure if that is the right way to do and if this will work at all (will it?).

I can’t be the only one with such setup. How it was supposed to be configured?

Take a look at this section of the Integration Guide:

If you want to use the http-01 challenge anyhow, you may want to take advantage of HTTP redirects. You can set up each of your frontends to redirect /.well-known/acme-validation/XYZ to validation-server.example.com/XYZ for all XYZ. This delegates responsibility for issuance to validation-server, so you should protect that server well.

Central Validation Servers

Related to the above two points, it may make sense, if you have a lot of frontends, to use a smaller subset of servers to manage issuance. This makes it easier to use redirects for http-01 validation, and provides a place to store certificates and keys durably.

Basically, you would have all your servers redirect requests that match /.well-known/acme-challenge/* to a special validation server that has the correct challenge file ready to be served. This can be something like certbot in standalone mode with --standalone-supported-challenges http-01. You then push the certificate and private key from that server to all your backend servers (they can be used on any number of servers at the same time). --renew-hook might be an interesting flag for you in that scenario.

Alternatively, use the DNS-01 challenge.

Enter another use case where being able to generate certs from a validated root domain would make life easier for implementation…

DNS-01 probably won’t work because I doubt that either of these two servers have access to auto-magically modify DNS…

You don't need to run it from those servers :wink: you could run it from somewhere secure which does allow modification of the DNS.

You can’t manage to copy a cert to another server automatically? What are you even doing near a server?

A cert certifies a name belonging to a single public key. If that name is supported by multiple IP addresses, it follows that each server on each address must have access to the same private key and certificate. That’s basically the end of the story. You need to copy the cert to every server involved, unless you do unnecessary gymnastics like you suggested.

Copying some file around should really be a no-brainer.

@TCM, it’s not about being able to script it. It’s about to check if there is already a solution for it. I prefer to use standard solutions instead of introducing own bicycles. And it looks like there is no “standard” solution. So yes, probably I have to script it on my own.

I rather think of it as “how much third-party code is this going to require and can I better do it myself?”

With the other solution you would come closer to the rate limit for your domain needlessly, you’d have to run multiple copies of the client etc.

If the setup is sound, don’t overthrow it to accomodate a tiny problem. The correct solution should be clear.

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