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.
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.
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”
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.
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.
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?
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.