Ok, I get a 404 with no download which suggests either you’ve deleted the file or that video.leylan.com is not the same IP/service externally.
If you also leave test.txt in there I should be able to get it if the paths are all working… If I can’t that would prove there’s a difference externally.
I had renamed test.txt. It is back. So there is a test and a test.txt and even a test.html. I was able to request and get back the html file for some time.
I’ve made a mod to set the content-type to text/html if there is no extension. It takes one second to get that running
Thanks Tom,
I can confirm that:
http://video.leylan.com/.well-known/acme-challenge/test
http://video.leylan.com/.well-known/acme-challenge/test.txt
http://video.leylan.com/.well-known/acme-challenge/test.html
All return the same 404 error for me. This probably means that either we’re both requesting different URLs (do these work by copy/paste for you?) or your locally resolved DNS for video.leylan.com is a different IP or server to the one I see externally [199.119.163.189].
I added the text for no extensions and request file test (no ext) no displays.
I see the difference I am not using the entire path. ExpressJS knows to check that folder.
So I think we know the cause at this point I just need to get ExpressJS to permit requests made to that folder.
Yes, if you can get /.well-known/acme-challenge to serve extensionless test files then it should work. You could also have just not used an ExpressJS port 80 listener on that IP, freeing it up for the certify http challenge process to use, then the standard http challenge response should have worked ok from certify.
I will give that a try… much better than adding a listener on port 80.
1 Like
Ok, see how you get on. You can still go the route of serving the challenge via Express is you allow the extensionless text files from ./well-known/acme-challenge
As background for the whole process:
The http challenge is a file Let’s Encrypt ask you to create with a specific location, name and content. It must appear under http://<yourdomain>/.well-known/acme-challenge/<challenge file name> when Let’s Encrypt checks for it. It’s a text file (application/text mime type) with no .txt extension. The lack of extension causes problems for many different web servers as it obviously looks like a directory name instead of a file.
To circumvent the problem of configuring the web server we use our http challenge server process by default. This listens (via an http.sys http listener) on all IPs during a certificate order attempt. It intercepts http://<anydomain>/.well-known/acme-challenge/ requests and looks up the correct answer from our Certify background service, then serves that back. It forwards any other request to the reset of http.sys (which in turn means IIS can handle requests).
In case this custom challenge listener is unavailable (usually because port 80 is in use by a process that doesn’t use http.sys, but sometimes because the machine need a reboot) we also write out the challenge response folder and file to the /.well-known/acme-challenge/<filename> of the website. We auto-detect this website root path for IIS and inject a web.config to configure the extensionless file handling, but for other server types it needs to be specified manually and those servers need to be configured manually to serve the file type properly from that path.
And finally, the most important part is that the full required URL resolves externally when using http, it can redirect to https but something must initially respond on http.
Our “Test” mode writes out a test file and checks it locally via http and optionally via our proxy API (asking our API if it can resolve the URL), this is optional under Settings. If either one passes it assumes the test is OK but really if something resolves locally but not externally then it will still fail. So in your case, the Test was correctly failing because your server was not able to respond with the required file at the required URL.
We need to expand our docs HTTP Validation (http-01) | Certify The Web Docs to cover more for non-IIS scenarios.
Well that was crazy BUT… I have a renewed certificate.
I had to modify things a bit on the ExpressJS service to recognize the .well-known folder and to handle the incoming request for the file. Finally found examples on the net that outlined both with one route entry I would never have guessed.
Interestingly (I tested stuff for hours) I found a certbot example. It didn’t work as it was laid out but it provided a few steps to follow and I could see what did and didn’t work. Their example placed the .well-known folders in a folder named “static”. I wouldn’t matter what it was called just that it should hold static files and folders with static files. I have one named “public” for the index.html page for instance.
In any case the “test” mode on CTW seemed to find the folder (I’m guessing because I had a route designated). The actual renewal didn’t, insisting that the .well-known folder be where it thinks it should be. Which leads me to “what if you had an option to specify where the .well-known folder was”?
At this point I’m using my port 80 server and I’ll see if it can be tidied up / made smaller but it works and once again “I have my certificate renewed”.
Thanks for all your help. I really read all the explanations you provide. I am a firm believer in understanding a process rather than following some instructions.
Hooray!
1 Like