[Loadbalancing] Redirecting all acme-challenges with NGINX to main SSL certificate generating server

This can become very confusing fast, please read carefully
Domain and IP Addresses are examples.

I am setting up load balancing, I am trying to solve where I have to create many SSL certificates dynamically and will allow me to create a letsencrypt certificate from my main SSL certificate generating server for any domain that is pointed my load balancer.

I have two back end slave servers that both run on NGINX.

SVR1 - ( Main SSL certificate generating server )
SVR2 - ( Where domain is pointed at in this example and has NGINX redirect config for acme-challenges )

On SVR1 I am running

letsencrypt certonly -a webroot --agree-tos --email=myemail@gmail.com --noninteractive --webroot-path=/home/forge/ myproject/public -d blue.com


I am trying to create a SSL certificate for blue.com which is pointed to SVR2 IP.
I am generating the SSL Certificate from SVR1.

When generating the SSL certificate from SVR1 for the domain thats pointed to SVR2 I get a trip saying

  Failed authorization procedure. blue.com (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Could not connect to\n
     - The following errors were reported by the server:\n
       Domain: blue.com\n
       Type:   connection\n
       Detail: Could not connect to\n

The NGINX catch-all site config on SVR2 contains ( This is where its failing )

location /.well-known {
allow all;
return 301$uri;

The NGINX catch-all site config on SVR1 contains

location /.well-known {
allow all;

Basically, I am redirecting all challenges for letsencrypt to my selected choice of server that does all my ssl certificate generating.

My assumption is perhaps letsencrypt doesn't account for redirects or doesn't like it when checking for acme-challenges.

I can connect to both SVR1 and SVR2 through my browser, and there is no ip whitelist / blacklist.

You know there's a space in the middle of that, right?

Redirects are totally fine. The existence of a redirect in and of itself is not the problem you're running into.

I just gave it a try, and redirecting to an IP address seems to fail with the above error message. Try creating a hostname like svr1.example.net or svr1-acme-challenge.example.com or something and redirecting to that. (Or using an existing acceptable hostname, if you have one, i guess.)

You could also use proxy_pass instead of redirecting.

1 Like

You are 100% right.

The solution for the few people that ever come up with this problem is


location /.well-known {
allow all;

instead of

location /.well-known {
allow all;
return 301$uri;

Mnordhoff, if you have a skype or email, I would love to compensate you a little for the hours of times you have just saved me. I can't figure out how to private message people haha.


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