I’m using AutoACME to use Let’s Encrypt on Windows Server 2016 and IIS 10. At other sites this has worked flawlessly however at this particular site I’m having the strange issue that AutoACME and therefore LE is returning 503 as the result when getting a challenge response or a timeout however I can access the challenge externally without any issues so I can’t see why LE servers wouldn’t be able to access it too.
It’s possible but unlikely. The server logs show that Let’s Encrypt isn’t even touching the server so I thought it might be a DNS issue but it’s s fresh DNS record with a short TTL.
blob seems to work.
…
I’d check the firewall logs for blocks to port 80.
If that leads nowhere, open the challenge folder and watch it while you run the script.
new files should be created in it.
If not… then the files are not going into the correct folder.
Yup checking the firewall logs when I load the blob file I see a record but when I run Let’s Encrypt nothing is generated in the firewall logs.
Yup I’ve checked the folder whilst running the script and it is creating the challenge responses in the right folder and in the right format.
Really running out of options unless there is an issue with the specific endpoint I’m trying to use with Let’s Encrypt although it is just looking at the default acme-v01.api.letsencrypt.org endpoint.
In this case the 503 error appears to be coming from Let’s Encrypt, not from your service. This might be a problem in Let’s Encrypt’s infrastructure, including with the CDN that we use. @jple, who could help investigate whether this is a CDN issue?
@joshftw Just caught up on this. Are you still having an issue? I can confirm that currently from the production servers we are able to reach ra.holybrookacademy.co.uk on 80 and 443.
I’ve verified that I can pull that challenge from the production and staging validation servers just fine with a curl.
Looking in the logs at recent attempts via the API I see validation getting a 403 with the following text instead of the validation record: \"\u003c!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0 Strict//EN\" \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd\"\u003e \n\u003chtml xmlns=\"http\""
To make that a little more helpful, the validation attempt appears to be happening. Let’s Encrypt is getting the request and attempting to reach the server. DNS resolution appears to succeed, but it gets an invalid response from the webserver.
At this point, everything seems to be working right from the LE side, but the response from the server is not the expected challenge.
To update on this. I found the solution by monitoring the local firewall logs. The AutoACME application that I was using performed a DNS lookup and I think this was before requesting from the LE servers. The firewall and multiple layers of NAT complicated this by setting the incorrect source IP of the incoming packets from LE. By adding a zone file to the local DNS server for the FQDN of the server’s external address that pointed to the internal IP it resolved correctly and allowed LE to access the server and create a certificate.
Thanks for everyone’s contributions to this, certainly helped get to the right answer.