404 on --webroot verification


#1

My domain is: condivi.so

I ran this command: sudo certbot certonly --webroot -d condivi.so -w /usr/local/ispconfig/interface/acme --dry-run

It produced this output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for condivi.so
Using the webroot path /usr/local/ispconfig/interface/acme for all unmatched domains.
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. condivi.so (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://condivi.so/.well-known/acme-challenge/tsaSCsqkguJDahpLXnXuKRqnKIK49aCmjyAGBat2kC4 [2001:4b98:dc0:45:216:3eff:fe4b:f154]: “\r\n404 Not Found\r\n<body bgcolor=“white”>\r\n

404 Not Found

\r\n

IMPORTANT NOTES:

  • The following errors were reported by the server:

    Domain: condivi.so
    Type: unauthorized
    Detail: Invalid response from
    http://condivi.so/.well-known/acme-challenge/tsaSCsqkguJDahpLXnXuKRqnKIK49aCmjyAGBat2kC4
    [2001:4b98:dc0:45:216:3eff:fe4b:f154]: “\r\n404
    Not Found\r\n<body
    bgcolor=“white”>\r\n

    404 Not
    Found

    \r\n

    To fix these errors, please make sure that your domain name was
    entered correctly and the DNS A/AAAA record(s) for that domain
    contain(s) the right IP address.

My web server is (include version):

nginx version: nginx/1.10.3

The operating system my web server runs on is (include version):

Debian GNU/Linux 9 \n \l

My hosting provider, if applicable, is:

n/a

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

n/a as I run the command via shell

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

certbot 0.28.0


So I try to create a certificate, the nginx configuration of the vhost of our concern is:

    location ^~ /.well-known/acme-challenge/ {
                    root /usr/local/ispconfig/interface/acme/;
    }

infact: http://condivi.so/.well-known/acme-challenge/hello.txt -> shows “pippo” which is correct:

cat /usr/local/ispconfig/interface/acme/.well-known/acme-challenge/hello.txt 
pippo

I’m not sure what’s happening here, I run the command as root so it should be able to write there, there are no symlinks in place and the fact that I can reach http://condivi.so/.well-known/acme-challenge/hello.txt suggests that I’m using the right paths.

Ideas?


#2

Hi @tbasilici

you have ipv4 - and ipv6 - addresses (via https://check-your-website.server-daten.de/?q=condivi.so ):

Host T IP-Address is auth. ∑ Queries ∑ Timeout
condivi.so A 92.243.30.156 yes 1 0
AAAA 2001:4b98:dc0:45:216:3eff:fe4b:f154 yes
www.condivi.so A 92.243.30.156 yes 1 0
AAAA yes

But it looks like your ipv6 has a different configuration:

Domainname Http-Status redirect Sec. G
http://condivi.so/
92.243.30.156 200 0.760 H
http://condivi.so/
2001:4b98:dc0:45:216:3eff:fe4b:f154 200 0.070 H
http://www.condivi.so/
92.243.30.156 200 0.067 H
https://condivi.so/
92.243.30.156 200 5.734 N
Certificate error: RemoteCertificateNameMismatch
https://condivi.so/
2001:4b98:dc0:45:216:3eff:fe4b:f154 -2 1.103 V
ConnectFailure - Unable to connect to the remote server No connection could be made because the target machine actively refused it [2001:4b98:dc0:45:216:3eff:fe4b:f154]:443
https://www.condivi.so/
92.243.30.156 200 5.360 N
Certificate error: RemoteCertificateNameMismatch
http://condivi.so/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de
92.243.30.156 404 0.063 A
Not Found
http://condivi.so/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de
2001:4b98:dc0:45:216:3eff:fe4b:f154 404 0.070 A
Not Found
http://www.condivi.so/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de
92.243.30.156 404 0.067 A
Not Found

I don’t see if the content of the ipv4 - not found is the same as the content of the ipv6 - not found. The https configuration is different, so is your http - ipv6 configured?

Perhaps add a listen:

listen [::]:80;

Letsencrypt prefers ipv6, your error

shows the ipv6 address.


#3

Your evaluation is absolutely correct, ipv6 and ipv4 did return different content. Fixed thah, certbot worked.

Thanks a lot!


#4

Happy to read that:

Now there is a new certificate:

CN=condivi.so
	25.02.2019
	26.05.2019
expires in 90 days	condivi.so, www.condivi.so - 2 entries

so both connections are secured.

A few minutes ago I had rechecked your domain, after adding an internal save-command to store the content of the /.well-known/acme-challenge - check. But the content of ipv4 and ipv6 is ~~ the same.


#5

I’m not really sure what you mean :slight_smile:

Now the content of the website should be the same if reached via ipv4 and ipv6, the problem I had was that the server returned the default vhost via ipv6, which of course didn’t have any rule for .well-known


#6

There are sometimes problems with different configurations ipv4 / ipv6. But my tool ( https://check-your-website.server-daten.de/?q=condivi.so ) checks only the http status.

Seeing your result -> both /.well-known/acme-challenge/unknown-file (ipv4 and ipv6) had the same http status 404. So it looked good. But I couldn’t check the content because it wasn’t saved.

So the idea: Save the content and compare the content if it is ~~ the same. If it is completely different -> show an additional warning.


closed #7

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