How to specify a subdomain to verify with (load balancing)

Help
1

I am trying to find which command / configuration would let me specify a specific verification subdomain. So instead of trying to find https://www.example.com/.well-known/acme-challenge/… I could specify https://server1.example.com/.well-known/acme-challenge/…

This would be really helpful, because I could set up the load balancer to send all traffic to the specific server generating the script via that subdomain - and would allow me to automatically update and run certbot on all the servers with unique subdomains for each server, without having to copy over certs. etc.

I’m using certbot 0.31.0, NGINX on Ubuntu 18.04, with Cloudflare as my DNS.

1 Like
2

Hi @carpool

you have to create a redirect

http://www.example.com/.well-known/acme-challenge/random-filename

to your destination.

Then you have to run Certbot on that “destination machine” with webroot.

Read

1 Like
3

The ACME servers will follow any redirect on the HTTP OSI layer (i.e., with the HTTP Location header).

4

Thanks Juergen. So how do I differentiate the different servers behind the load balancer? It’s random which server will be called to serve that page - unless I can specify some sort of variable in that URL.

1 Like
5

The redirect goes from every server to another domain name without using a load balancer.

Create one new subdomain, don't create a load balancer setup, then create redirects main domain -> new subdomain.

1 Like
6

I think I’m still confused. So every server needs a unique domain name?

It’s very straightforward to have a different subdomain for each back end server that skips the load balancer: sub1.example.com could point to server 1, sub2.example.com could point to server 2.

When I automatically renew / create the certificate on sever 1, how do I make sure it checks for the file on sever 1? I’m not sure where the other domain name fits into the equation.

7

###Load Balancing and SSL/TLS Offloading

If security considerations permit, it is possible to use a load-balancing ADC to offload SSL from the backend servers, freeing computing resources. In this situation, a signed SSL/TLS certificate is installed on the ACD. The client establishes an encrypted connection with the load balancer, which in turn uses unencrypted protocols with the server pool (e.g. HTTP on port 80)

I’d leave the work to the front end. But as often stated here, “Your Mileage may vary”
Rip

1 Like
8

Please - not. The idea is: Every server uses the same redirect destination, not different. So you can run Certbot / another client on that subdomain.

Read the basics:

Validating a domain Letsencrypt follows http + https redirects. Multiple servers -> one destination.

9

Sorry Juergen, I’m pretty new to this and running into challenges.

I understand the redirects - but the problem I am facing is that when I point all the different back end servers to same URL hosted on one server the renewal / installation works on that one server - but it fails on the others.

I imagine this is because let’s encrypt is generating new tokens and they cannot be found on the separate server.

Server1 -> redirect to static.server1.com, finds the file
Server2 -> redirect to static.server1.com, does not find the file

I have read that page you link to several times and I can’t find the section where it specifies how to deal with this situation.

10

Don’t use load balancing with the redirect destination static.server1.com. Then there is only one instance = always the same.

11

There is no load balancing on that subdomain.

The issue is I need to be able to generate the certificate on multiple servers.

I don’t want to have to manually turn on and off load balancing each time I generate a certificate.

12

That's wrong.

There is a rate limit, so you can't create too much certificates with the same domain name.

Create one certificate and deploy it.

13

Ah, ok I think I’m getting closer! Again, thank you for being so patient with me.

So the solution is creating the certificate on 1 server (which is working), and then copying it over to the other servers.

Is there a setting in certbot to do this, or should it be a manual process? My concern is the delay between the certificate generation and then the time it takes to move all the certificate data over.

EDIT:
On second thought, if I set up a cron job to check if the /etc/letsencrypt/ has changed, I assume the “old certificate” would still work on the deployed-to servers? So I can just periodically run an rsync on /etc/letsencrypt/ to make sure the new keys are moved over?

1 Like
14

Redirection can be to a completely different domain altogether.
[you may not need to go that drastic… but to best exemplify that functionality]

So you could assign one cluster member as the master replicant (i.e. master.domain.com = one IP)
and redirected all validations to it.
Give all cluster members access to the master’s shared authentication folder and viola! Authentication happens from any server at any time.

You could delegate renewals to that one specific renewal master and simply rsync the LE folders to all other cluster members…
You could share (NFS) the LE certs and just use them directly from that share without making local copies…
Do you see the limitlessness yet…?
Should I continue…?
Use DropBox to share new certs with all your contacts…LOL
So you are reading this.
There are many ways to skin this cat [ouch!] cert.

15

Right. :slightly_smiling_face: Issuing a certificate doesn't automatically revoke or otherwise invalidate existing certificates. You would only need to copy the certificates before the old ones expire.

You can use a Certbot hook in order to run rsync instantaneously, but it's not actually that time sensitive.

https://certbot.eff.org/docs/using.html#renewing-certificates

16

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