I don’t want to create additional noise on top of the current security issue but my understanding is that the http-01 challenge is supposed to work normally? If so then I don’t know what to do anymore.
My domain is: sittenkammer.de
My web server is: apache2 [2.4.10-10+deb8u11] (also tested on nginx [1.6.2-5+deb8u5] which made no difference) on raspbian 8
I ran this command (among many many others): certbot certonly --webroot -w /var/www/html/ -d sittenkammer.de --staging
certbot always fails with
- The following errors were reported by the server:
Domain: sittenkammer.de
Type: connection
Detail: Fetching
http://185.142.180.85/sittenkammer/.well-known/acme-challenge/RfW8Z7Cwe89s3Zk7LQkQXwutbc84xeMYdmm3y0teo4c:
Error getting validation data
To fix these errors, please make sure that your domain name was
entered correctly and the DNS A record(s) for that domain
contain(s) the right IP address. Additionally, please check that
your computer has a publicly routable IP address and that no
firewalls are preventing the server from communicating with the
client. If you're using the webroot plugin, you should also verify
that you are serving files from the webroot path you provided.
I quadrupelchecked the A Records several times, asking different DNS servers, even from different hosts.
Something weird is going on with the resolution though - I don’t know why it is trying to fetch /sittenkammer/.well-known/acme-challenge instead of /.well-known/acme-challenge (this is where certbot actually places the file). I did not set up this hosting environment, but looking at all the relevant configuration files leaves me clueless about this. However I tried to work around the issue by symlinking: lrwxrwxrwx 1 root root 15 Jan 12 17:54 /var/www/html/sittenkammer/.well-known -> ../.well-known/
Thanks for the suggest. However it does not really change anything because of the symlink in place. If I replace the symlink with an actual folder the outcome also is the same.
The files are there, at any location. I can GET them. I can also curl them from a remote box. I don’t think root path is the problem.
To clarify: there is a difference for your command, that is the challenge file will be placed in /sittenkammer/.well-known/acme-challenge instead of /.well-known/acme-challenge
there you go for the output. It’s the same as always
# certbot certonly --webroot -w /var/www/html/sittenkammer/ -d sittenkammer.de --staging
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Starting new HTTPS connection (1): acme-staging.api.letsencrypt.org
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for sittenkammer.de
Using the webroot path /var/www/html/sittenkammer for all unmatched domains.
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. sittenkammer.de (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://185.142.180.85/sittenkammer/.well-known/acme-challenge/xe33jczhshkVDXZ6sHJ31eHhP5-xzOPYGGPEDKorRWg: Error getting validation data
IMPORTANT NOTES:
- The following errors were reported by the server:
Domain: sittenkammer.de
Type: connection
Detail: Fetching
http://185.142.180.85/sittenkammer/.well-known/acme-challenge/xe33jczhshkVDXZ6sHJ31eHhP5-xzOPYGGPEDKorRWg:
Error getting validation data
To fix these errors, please make sure that your domain name was
entered correctly and the DNS A record(s) for that domain
contain(s) the right IP address. Additionally, please check that
your computer has a publicly routable IP address and that no
firewalls are preventing the server from communicating with the
client. If you're using the webroot plugin, you should also verify
that you are serving files from the webroot path you provided.
/var/www/html is the document root. From my extensive digging around it seems to be still a very standard apache config. Also I thought a certificate is for a domain, not for a website?
Anything specific? I’m afraid putting ‘the config’ (webserver, certbot, ip tables, systemd, network, whatnot…?) up here completely would dillute the problem more.
Your domain advertises IPv4 and IPv6 addresses, Let’s Encrypt prefers IPv6 over IPv4 so it tries to validate your domain using the IPv6 address but you have a redirection that Let’s Encrypt won’t follow.
So, trying to reach the challenge using IPv4 it works, no problem:
But trying to reach it using IPv6 you have 2 problems:
$ curl -ikL6 http://sittenkammer.de/.well-known/acme-challenge/RfW8Z7Cwe89s3Zk7LQkQXwutbc84xeMYdmm3y0teo4c
HTTP/1.1 301 Moved Permanently
Server: nginx
Date: Fri, 12 Jan 2018 19:02:05 GMT
Content-Type: text/html
Content-Length: 178
Connection: keep-alive
Location: http://185.142.180.85/sittenkammer/.well-known/acme-challenge/RfW8Z7Cwe89s3Zk7LQkQXwutbc84xeMYdmm3y0teo4c
HTTP/1.1 404 Not Found
Date: Fri, 12 Jan 2018 19:02:05 GMT
Server: Apache/2.4.10 (Raspbian)
Content-Length: 363
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL /sittenkammer/.well-known/acme-challenge/RfW8Z7Cwe89s3Zk7LQkQXwutbc84xeMYdmm3y0teo4c was not found on this server.</p>
<hr>
<address>Apache/2.4.10 (Raspbian) Server at 185.142.180.85 Port 80</address>
</body></html>
1.- You are not serving the same content as using IPv4, using IPv6 I can’t reach the same challenge I can reach using IPv4.
2.- Let’s Encrypt follows redirections but doesn’t follow them if the redirection is an ip instead of a domain so this redirection won’t work:
