Certbot --nginx returns 404 on challenges but curl works

My domain is:


I ran this command:
certbot --nginx
It produced this output:

Domain: webdav.miki-jtk.r4ph43l.org Type: unauthorized Detail: Invalid response from http://webdav.miki-jtk.r4ph43l.org/.well-known/acme-challenge/1MwQzxBYY-BO-EMwI0Fgsvn1Oi0Rn_hDljZwvHUds2c []: "<html>\r\n<head><title>404 Not Found</title></head>\r\n<body bgcolor=\"white\">\r\n<center><h1>404 Not Found</h1></center>\r\n<hr><center>"

My web server is (include version):

nginx 1.14.2

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):


i already checked access to
by creating test.html and curl on it which has the content “alias works”:

└──╼ #curl http://webdav.miki-jtk.r4ph43l.org/.well-known/acme-challenge/test.html
alias works

I am currently unaware of further debugging options. I already tried --debug-challenges but without any success.

Is there a possibility to check the creation of challenge files?
Any ideas on further debuggings?

Python and Linux administration knowledge available.

--nginx does not create any challenge responses on the filesystem.

It directly injects a location /.well-known/acme-challenge/xxx block into the port 80 nginx virtual host for that domain, with the response directly embedded as a string.

Since you are using --debug-challenges already, you can try looking at your nginx config while Certbot is paused, which might give a hint as to why the configuration changes are not effective.

Hi @r4ph43l

I see, you have tested that folder and filename explicit ( https://check-your-website.server-daten.de/?q=webdav.miki-jtk.r4ph43l.org%2F.well-known%2Facme-challenge%2Ftest.html ).

With the correct http status 200

So you have found the correct webroot. Then use it:

certbot run -a webroot -i nginx -w yourRoot -d webdav.miki-jtk.r4ph43l.org
1 Like

Thanks for the input - just checked it with following result:
certbot run -a webroot -i nginx -w /srv/letsencrypt/ -d webdav.miki-jtk.dnsalias.com --debug-challenges

Domain: webdav.miki-jtk.dnsalias.com
Type: connection
Detail: Fetching
Error getting validation data

The file has been written, contains data - i cannot see what the error should be during fetching…

I already checked that the injection is passed correctly.
Unfortunately somehow it did not work as expected.


is port 80 closed ( https://check-your-website.server-daten.de/?q=webdav.miki-jtk.dnsalias.com ):

Domainname Http-Status redirect Sec. G
http://webdav.miki-jtk.dnsalias.com/ -14 10.027 T
Timeout - The operation has timed out
http://www.webdav.miki-jtk.dnsalias.com/ -14 10.026 T
Timeout - The operation has timed out
https://webdav.miki-jtk.dnsalias.com/ 200 3.543 N
Certificate error: RemoteCertificateNameMismatch, RemoteCertificateChainErrors
https://www.webdav.miki-jtk.dnsalias.com/ 200 2.006 N
Certificate error: RemoteCertificateNameMismatch, RemoteCertificateChainErrors
http://webdav.miki-jtk.dnsalias.com/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de -14 10.026 T
Timeout - The operation has timed out
Visible Content:
http://www.webdav.miki-jtk.dnsalias.com/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de -14 10.026 T
Timeout - The operation has timed out
Visible Content:

So that can’t work.

typo with the old domain - my bad - sorry for the confusion.
Will do the same again with the correct one…

@JuergenAuer: Thanks for the help, using webroot worked without any problems and I also figured out why --nginx did not work: My reverse proxy re-routes the ports, therefor no requests do reach port 80 on the target server.
Would there be the opportunity to have a parameter for nginx option that could get a port as value?

Best regards,

Certbot has a --http-01-port that controls what port it listens on. I think it works for the Nginx plugin.

Let’s Encrypt can’t let you choose which port the validator connects to.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.