How-to: Nginx configuration to enable ACME Challenge support on all HTTP virtual hosts


#22

I was using the guide at https://pestmeester.nl/index.html#10.0, it seems to call it with the auto options…will have to go poking around looking for an .ini file or a .conf to put that entry. The folder /etc/letsencrypt/renewal is empty…


#23

OK…

  • read the manuals (always helps)
  • installed the nginx specific client
  • created a cli.ini that contains webroot-path = /data/test/www
  • ran sudo certbot --nginx and selected the working webserver, dummy.com and www.dummy.com

It created the certificates, then:

Waiting for verification…
Cleaning up challenges
Failed authorization procedure. dummy.com (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Timeout, Failed authorization procedure. www.dummy.com (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Timeout

IMPORTANT NOTES:

  • The following errors were reported by the server:

    Domain: dummy.com
    Type: connection
    Detail: Timeout

    Domain: www.dummy.com
    Type: connection
    Detail: Timeout

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.

Obviously, the domain isn’t dummy.com…but it is available, it has real records, it is accessible from the internet, nginx webserver is running and serving pages to the real world.

So, what doesn’t certbot like? The cli.ini specifies a webroot path that is real and accessible but is not where the pages are held.


#24

Is there a firewall or anything blocking access to port 443 ( for the tls challenge ) ?

What’s your domain name, so we can check from external locations and DNS etc ?


#25

Just realised…443 isn’t open (and nginx isn’t setup for SSL yet…oops)

Changed the firewall so 443 is open, configured nginx.conf with listen 443 ssl; in the same server-block as listen 80…and restarted nginx.

Port is open to the internet according to grc.com, but…

Same problem…can’t connect

Sorry, as a new user, the forum won’t let me reply any more…for some undisclosed timeout period :frowning:

I would prefer to keep the real domain anonymous, for several reasons.


#26

What’s your domain ? - it’s publicly available in transparency reports on the issue of all certificates anyway. PM me with it if you really object.

I’ve edited your user so you should be able to reply.


#27

cfz.com.au is one of the domains


#28

You aren’t currently providing a connection on 443 for that domain - what’s your nginx config like ? can you reach your domain via https ?


#29

I’m not…I may have to put this on hold for a bit. I am working between a production and testing server and one is SSL, the production not…and swapping them in and out is causing problems. I have an idea of what is happening…I may wait until the weekend and take the production server offline to test this properly, otherwise I will screw up a live file!


#30

Always best not to mess up the live system :wink:

I’d suggest either using the http validation to obtain the certificate ( since http on port 80 is fine at the moment, or you could even use the DNS challenge, since that doesn’t need to touch the live server at all).


#32