A lot of times I've seen questions about how this works when you have multiple nodes or a CDN, it can be quite tricky in theory if you have random IPs or several IPs.

The way certbot works at least for non-DNS challenges is that it will hit a random server that it resolves to, you have no control over which one it hits.

If certbot hits node 1 at first to tell it to create the well-known file, then checks node 2 or any other node, you will find auhorization fails.

Here is an example of this happening:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Requesting a certificate for yourdomain.com
Performing the following challenges:
http-01 challenge for yourdomain.com
Using the webroot path /var/www/haproxy for all unmatched domains.
Waiting for verification...
Challenge failed for domain yourdomain.com
http-01 challenge for yourdomain.com
Cleaning up challenges
Some challenges have failed.

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: yourdomain.com
   Type:   connection
   Detail: During secondary validation: 192.168.80.166: Fetching
   http://yourdomain.com/.well-known/acme-challenge/nUKlCCEWf-HzUgrnLvPXZLQjmXUCOi4gC74jtRYbqp4:
   Connection refused

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A/AAAA record(s) for that domain
   contain(s) the right IP address. Additionally, please check that
   your computer has a publicly routable IP address and that no
   firewalls are preventing the server from communicating with the
   client. If you're using the webroot plugin, you should also verify
   that you are serving files from the webroot path you provided.


Solution

The simplest solution is to just redirect ALL requests to a single node IP.  That means all node IPs but the "main IP" let's call it 1.2.3.4, it means all other node IPs that get an .acme-challenge/well-known need to be redirected to 1.2.3.4 and then your problem is solved.

Eg. in haproxy do this on all but the node with the 1.2.3.4 IP.

backend letsencrypt
    server letsencrypt 1.2.3.4:80
 

If you do something like above, then it now means all requests will work because they are transparently redirected to a single server.

Other solutions that may be more practical could be DNS if you control it, or if you really want to be fancy, you could use shared storage for the challenges that exist on all proxy/CDN nodes.

haproxy, nginx, certbot, ssl, issuesa, ve, multiple, nodes, cdn, tricky, ips, dns, challenges, server, resolves, node, auhorization, fails, debug, var, letsencrypt, plugins, selected, authenticator, webroot, installer, requesting, certificate, yourdomain, performing, http, www, unmatched, domains, verification, domain, errors, reported, secondary, validation, fetching, acme, nuklccewf, hzugrnlvpxzlqjmxucoi, gc, jtrybqp, correctly, aaaa, contain, ip, additionally, publicly, routable, firewalls, preventing, communicating, plugin, verify, provided, simplest, redirect, requests, quot, redirected, eg, backend, transparently, solutions, proxy,

Latest Articles