2

I'm having some issues setting up Let's Encrypt for a couple websites that are setup on two different servers, and have the traffic distributed to them via HAProxy.

The servers have a number VHosts/domains on them, all of which are going to need SSL certificates. For the sake of this post, lets say they're:

  1. foo.some-site.com
  2. bar.some-site.com

Both of these A records are setup with two IP addresses. I can verify with nwtools.com or just nslookup that both of the A records foo.some-site.com and bar.some-site.com resolve the same two IP addresses. And I know that Let's Encrypt requires the vhost to have a valid record used so it can do a lookup.

I planned on running the Lets Encrypt setup on both servers for all the vhosts, and it worked fine for one of them, but when I moved onto the second one, I got an error:

[root@server httpd]# /opt/letsencrypt/letsencrypt-auto --apache -d foo.some-site.com
Checking for new version...
Requesting root privileges to run letsencrypt...
   /root/.local/share/letsencrypt/bin/letsencrypt --apache -d foo.some-site.com
Failed authorization procedure. foo.some-site.com (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Failed to connect to host for DVSNI challenge

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

   Domain: foo.some-site.com
   Type:   connection
   Detail: Failed to connect to host for DVSNI challenge

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A 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.

Could this possibly be because it's doing a lookup or trying to curl foo.some-site.com, and it may be getting directed to the other server? I'm not sure how that would really matter, since both have the same VHosts on them, unless LetsEncrypt is actually listening for the connection that its making itself...

Whats throwing me off is it worked for one of them just fine (say bar.some-site.com), so why would it work for one site, but fail for another one with the exact same setup?

If anyone knows of a way to get Lets Encrypt setup for the same vhosts on two different servers, the help would be much appreciated!

5

Could this possibly be because it's doing a lookup or trying to curl foo.some-site.com, and it may be getting directed to the other server?

Yes, most definitely.

LE needs to connect back to the server you're running the LE client on, as part of the domain verification challenge-response process. Without getting into details, the LE client actually makes a certain file available in your webserver temporarily that the LE server needs to be able to consume to verify domain ownership.

Running this command on all of the back-end servers is un-necessary and cumbersome. Run it once, and then copy the key and certificate chain to the rest of the back-end servers.

Whats throwing me off is it worked for one of them just fine (say bar.some-site.com), so why would it work for one site, but fail for another one with the exact same setup?

Because you got lucky? :) It is possible that by chance your load balancer directed the LE requests to the right location once, but didn't do it the second time.

11
  • Its absolutely cumbersome! Not sure why I didn't think of that before, thats what I did with the regular SSL, guess I figured that LetsEncrypt required it to be ran on the server that will be using it. I got this to work though, but question about when I renew the certs... will I have to do the same thing? Its a bigger pain than you think, because the servers dont share the same web root, and I dont control the DNS.
    – Justin
    Apr 25 '16 at 23:10
  • So just write a little wrapper script to copy the items around after renewal, then run the whole thing via from.
    – EEAA
    Apr 25 '16 at 23:47
  • @Justin: Was writing a comment that in those cases DNS verification is the way to go, before noticing that you finished your comment saying that you do not control the DNS. Either way, copying the verification token across all servers before doing the verification request is going to be quite the pain, so good luck with that. Apr 26 '16 at 1:10
  • This is actually less cumbersome than traditional web-based domain verification. It puts the key there for you so that's one less step. The only thing you need to do is copy the chain around after verification. If your website is load-balanced, just make sure that the LE script writes to the source so it proliferates to all servers. Apr 26 '16 at 1:11
  • 1
    That can be handled at the load balancer, forcing LE requests to a specific back end.
    – EEAA
    Apr 26 '16 at 1:22
1

There are several approaches to scenarios involving multiple web/app servers/load balancers. You can read about some of them in the Official Let's Encrypt Integration Guide for larger environments.

There are some neat ways of doing it, like:

  • redirecting all validation requests to a single validation host/host pool
  • doing all certificate management off-line (i.e. requesting, renewing, and distributing keys from your management host rather than on your web servers)

What makes sense for you will depend on your preferences and various environment specific requirements.

1
  • Your first idea is actually the one I ended up going with after I posted the thread. I just set HAProxy to redirect all traffic to one server, then once I got the SSL setup, I used the files generated by LetsEncrypt on all servers.
    – Justin
    Jun 15 '16 at 19:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.