I run the certbot renew --dry-run and I can see the challenge files written into the /var/lib/letsencrypt/http_challenges. I can also see via the access.log that those files were successfully served by the web server:
Yet certbot still says it times out (see error below). I also placed a file in the http_challenges folder with the same permissions/owner as the challenge files and pulled it up externally (from another network) to verify that the rewrite is working and files from that folder can be served externally.
My domain is:www.leeburch.com
I ran this command:certbot renew --dryu-run
It produced this output:
1 renew failure(s), 0 parse failure(s)
It looks like requests were timing out -- each validation normally results in 4 HTTP requests in the staging environment, but those validations only logged 1-2.
I am not so sure it is me. I during testing to capture how long service took, without any changes suddenly it succeeded. Perhaps the servers are very busy (mine isn’t) and it only appears to be timing out due to busy servers on the Lets Encrypt end?
Excellent catch, I will check my DNS records. I may well have updated one and not the other when they changed my IP a while back. Thanks for the feedback.
Yet 1/10 times or so, it actually works. with no config change on my part.
I even see the request from the certbot servers and see that I am serving a 200 return code on the request, yet the certbot still usually reports timeout.
I am wondering, is this a problem on my end or that I can pull up files in the challenge directory and that sometimes certbot can too mean the problem is happening elsewhere?
FYI, the validation servers are operated by Let’s Encrypt, not the Certbot development team.
Like I said, Let’s Encrypt sends multiple validation requests. If you’re only receiving one, that is evidence that something is wrong.
(Though, in the production environment, only one validation request matters.)
The validation servers run in Let’s Encrypt’s two data centers and three(?) Amazon regions. It’s most likely that the problem is with your infrastructure, or a regional issue affecting your ISP.
Edit:
I cannot access the URL you posted from four ISPs in five locations (including one of the Amazon regions Let’s Encrypt uses). Attempting to connect times out.
FWIW, I don’t think the AAAA record with the ::ffff:0:0/96 IP will be used by clients. And connecting to the IPv4 IP in that AAAA record also seems to time out.
How do you test with the other ISPs? For me I was testing “external access” by VPNing out and then making calls back knowing they originate from the VPN endpoint. Maybe if I could test some alternate locations I might find the issue.
Still it is weird that it works sometimes, and just about 2 hours ago I did get the validation to work - again no changes on my end.
Definitely seems to be something happening in between me and others. This output is from a server I have shell access to in California (I am in Chicago IL)
100%[===========================================================================================================================================================================================>] 22 --.-KB/s in 0s
2019-08-23 16:49:42 (3.71 MB/s) - written to stdout [22/22]