Certbot --nginx returns 404 on challenges but curl works


#1

My domain is:

webdav.miki-jtk.r4ph43l.org

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 [46.85.25.12]: "<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):

4.14.94-1-ARCH

My hosting provider, if applicable, is:

selfhost.de

I can login to a root shell on my machine (yes or no, or I don’t know):

yes

I’m using a control panel to manage my site (no, or provide the name and version of the control panel):

no

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot):

0.33.0.dev0

i already checked access to
http://webdav.miki-jtk.r4ph43l.org/.well-known/acme-challenge/1MwQzxBYY-BO-EMwI0Fgsvn1Oi0Rn_hDljZwvHUds2c
by creating test.html and curl on it which has the content “alias works”:

┌─[root@parrot]─[/home/r4ph43l]
└──╼ #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.


#2

--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.


#3

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

#4

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
http://webdav.miki-jtk.dnsalias.com/.well-known/acme-challenge/7y5djqo-IHZ2jwMwZqni2vDWck1A4OWI-gJwso1v0Sc:
Error getting validation data

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


#5

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


#6

There

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/
91.40.222.128 -14 10.027 T
Timeout - The operation has timed out
http://www.webdav.miki-jtk.dnsalias.com/
91.40.222.128 -14 10.026 T
Timeout - The operation has timed out
https://webdav.miki-jtk.dnsalias.com/
91.40.222.128 200 3.543 N
Certificate error: RemoteCertificateNameMismatch, RemoteCertificateChainErrors
https://www.webdav.miki-jtk.dnsalias.com/
91.40.222.128 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
91.40.222.128 -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
91.40.222.128 -14 10.026 T
Timeout - The operation has timed out
Visible Content:

So that can’t work.


#7

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


#8

@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,
r4ph43l


#9

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.


closed #10

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