I ran this command: sudo /opt/letsencrypt/letsencrypt-auto renew
It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
-------------------------------------------------------------------------------
Processing /etc/letsencrypt/renewal/home.maartenstaa.com.conf
-------------------------------------------------------------------------------
Cert is due for renewal, auto-renewing...
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for home.maartenstaa.com
Waiting for verification...
Cleaning up challenges
Attempting to renew cert from /etc/letsencrypt/renewal/home.maartenstaa.com.conf produced an unexpected error: Failed authorization procedure. home.maartenstaa.com (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Could not connect to home.maartenstaa.com. Skipping.
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/home.maartenstaa.com/fullchain.pem (failure)
1 renew failure(s), 0 parse failure(s)
IMPORTANT NOTES:
- The following errors were reported by the server:
Domain: home.maartenstaa.com
Type: connection
Detail: Could not connect to home.maartenstaa.com
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.
My operating system is (include version): Ubuntu 16.04.2
My web server is (include version): nginx 1.10.0 (Ubuntu)
My hosting provider, if applicable, is: self hosted
I can login to a root shell on my machine (yes or no, or I don’t know): yes
I’m using a control panel to manage my site (no, or provide the name and version of the control panel): no
Really not sure what’s going on here. The debug log (let me know if I should post it) shows it has the right IP address, the location where it places the challenges is correct (/var/www/html/.well-known/). I verified that if I place a file under that directory, I get that file when I open it in my browser. I have tried restarting nginx, rebooting the server, but everything seems like it should work.
Have you tried surfing to your site http://home.maartenstaa.com ? My Chromium tries to download a small file, just 57 bytes in length, with aparently random binary stuff in it.
Seems to me your nginx isn’t serving HTTP on port 80.
I’m not sure I’m missing something, but how did you reach that conclusion? Ah, I understand now, home.maartenstaa.com is a CNAME for maartenhome.ddns.net, missed that
Interesting… I’m in The Netherlands as well, and can reproduce the telnet problem… yet in the browser it works fine, e.g. http://home.maartenstaa.com/.well-known/test.txt (redirects to HTTPS and then serves the file correctly). Any idea what could be causing this?
Are you sure? Because I checked with WireShark and all clients (telnet, wget, curl, Chromium) get the same result on a network level: binary garbage.
It’s just curl just outputs the binary stuff on the CLI, wgetthinks he’s getting test.txt and saves the result as such, but in reality he’s getting junk as well. And the browser assumes the binary stuff would probably be test.txt, so it also offers to save the file, while this file too is just binary garbage.
Could you check the contents of your downloaded test.txt? I’m sure it’s not containing the words/letters you were planning it to be
Your nginx is doing TLS on port 443, so I’m quite certain your nginx configuration for the “main” HTTP server block on port 80 is somehow corrupt.
The test.txt file contains the text “test”, which is the same thing I see in my browser. Clearly from what you’re saying the fact that Let’s Encrypt reports that it can’t connect is correct, though so far I’m confused as to why it works for me.
The obvious answer would be that I’m at home and that makes some difference, but I tested this from the office as well, with the same result.
Well, it’s what www.watismijnip.nl reports: “Uw IP-Adres: 77.162.3.217”, and it’s also listed as the WAN IP-address in my router status page. So it sure seems that way.
However, http://77.162.3.217/.well-known/test.txt produces the garbage file like you say. Maybe there’s some sort of NAT issue going on on the ISP end, though I have no idea how to verify that.
There were cases previously when IP resolved internally would be different from the one resolved externally. Hence the suggestion to double-check Seeing though that it appears valid but the requests are producing binary garbage, that would be interesting to find out why … Any odd compression enabled in server configuration, supported by the browser but not by curl or verification agents?
Actually, you seem to be running HTTPS on port 80 … Double-check your server configuration.
Weird. Though it has been checked via another service, which might simply strip the port in my case. Plot thickens …
@MaartenStaa, when you said you are seeing the text in your browser, are you sure you are looking at HTTP and not HTTPS (especially that you have HSTS there)? If HTTPS version works as expected but not HTTP version, I would try to make sure that port 80 is in use by Nginx and not something else first (for example with lsof -i). If it is Nginx - check its configuration. If it’s not, kill/move whatever process sits on 80 or use verification other than HTTP.
Ok, I found the problem. So my nginx config was set up to redirect all port 80 requests to https, and then the server block for port 443 was configured to handle requests correctly.
However, I incorrectly defined the first server block with…
server {
listen 80 default_server http2;
listen [::]:80 default_server http2;
Not realising that http2 is only supported on ssl servers (unless configured appropriately). To be honest, I’m still not sure why it did work in my browser but not for you guys, but after removing the http2 part, it works correctly.
Thanks everyone for your help in trying to figure this out!
Seeing though that it appears valid but the requests are producing binary garbage, that would be interesting to find out why … Any odd compression enabled in server configuration, supported by the browser but not by curl or verification agents?
: