To assist with debugging there is a great place to start is Let's Debug.
And when you get to this point
Can you see if the answer is available with curl or a we browser?
Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
My domain is:
I ran this command:
It produced this output:
My web server is (include version):
The operating system my web server runs on is (include version):
My hosting provider, if applicable, is:
I can login to a root shell on my machine (yes or no, or I don't know):
I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
Create a test text file with no file extension at the location where you are expecting win-acme to write the acme-challenge response files. Browse to that using a web browser, if that doesn't work get that working first. If it does work, test it from outside your network and ensure that works too. Once that's all working try win-acme again.
Remember to forward tcp port 80 from your router to your server so that external requests are being directed to the correct machine and not just being dropped/blocked by the router. You would also have to ensure that your ISP allows you to host stuff on TCP port 80, so confirm that your basic website loads over http (not https) externally.
If you can't get http validation to work you can look at dns validation instead.
Hello @Bruce5051 ,
Thank you for your reply.
Starting with Let's Debug helped us to find the problem.
For those who might find it helpful, we had initially hosted our project at OVH and then we changed our mind to host it locally on our internal server (windows server + ngnix). However, we had not removed the entry on the OVH server and our sub-domain was pointing to two IP addresses: that of OVH and that of our local server. This problem of double IP addressing blocked the creation of certificates for this sub-domain.
Let's Debug helped us identify the problem, thanks to (@Bruce5051) and we were able to solve it and create our certificate.
Thank you all for your help.