Hi @schoen,
I didn’t find any official reference but the other day, @mnordhoff pointed me out this behaviour Certbot error while obtaining certificate using webroot plugin
I did a test and I got the same conclusion… just to be sure I’ve made another test a few minutes ago.
Two servers, server 1 serves domain redirect.27a.net (163.172.166.61) and it has a redirect rule pointing /.well-known/acme-challenge/ requests to another server (server 2) using an ip (198.98.49.246) as redirection.
$ curl -ikL http://redirect.27a.net/.well-known/acme-challenge/test
HTTP/1.1 301 Moved Permanently
Server: nginx
Date: Tue, 30 May 2017 21:49:49 GMT
Content-Type: text/html
Content-Length: 178
Connection: keep-alive
Location: http://198.98.49.246/.well-known/acme-challenge/test
HTTP/1.1 200 OK
Server: nginx/1.12.0
Date: Tue, 30 May 2017 21:49:49 GMT
Content-Type: application/octet-stream
Content-Length: 26
Last-Modified: Tue, 30 May 2017 21:40:58 GMT
Connection: keep-alive
ETag: "592de6ea-1a"
Accept-Ranges: bytes
server 2 - challenge test
And now, I tried to get a certificate (using --dry-run) from server 2.
./certbot-auto certonly --webroot -w /usr/share/nginx/html/ -d redirect.27a.net --register-unsafely-without-email --dry-run
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for redirect.27a.net
Using the webroot path /usr/share/nginx/html for all unmatched domains.
Waiting for verification...
Cleaning up challenges
Unable to clean up challenge directory /usr/share/nginx/html/.well-known/acme-challenge
Failed authorization procedure. redirect.27a.net (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Could not connect to 198.98.49.246
IMPORTANT NOTES:
- The following errors were reported by the server:
Domain: redirect.27a.net
Type: connection
Detail: Could not connect to 198.98.49.246
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.
- Your account credentials have been saved in your Certbot
configuration directory at /etc/letsencrypt. You should make a
secure backup of this folder now. This configuration directory will
also contain certificates and private keys obtained by Certbot so
making regular backups of this folder is ideal.
Here is the letsencrypt.log https://gist.github.com/sahsanu/f0993ac953dd1beee5e780f8e250bcd4
So, we can’t get our certificate.
Now, instead of using the ip 198.98.49.246 for the redirect, I’ve used a domain pointing to the same ip 198.98.49.246.dnsip.xyz
$ curl -ikL http://redirect.27a.net/.well-known/acme-challenge/test
HTTP/1.1 301 Moved Permanently
Server: nginx
Date: Tue, 30 May 2017 21:53:08 GMT
Content-Type: text/html
Content-Length: 178
Connection: keep-alive
Location: http://198.98.49.246.dnsip.xyz/.well-known/acme-challenge/test
HTTP/1.1 200 OK
Server: nginx/1.12.0
Date: Tue, 30 May 2017 21:53:09 GMT
Content-Type: application/octet-stream
Content-Length: 26
Last-Modified: Tue, 30 May 2017 21:40:58 GMT
Connection: keep-alive
ETag: "592de6ea-1a"
Accept-Ranges: bytes
server 2 - challenge test
So lets try to get our cert again from server 2.
./certbot-auto certonly --webroot -w /usr/share/nginx/html/ -d redirect.27a.net --register-unsafely-without-email --dry-run
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for redirect.27a.net
Using the webroot path /usr/share/nginx/html for all unmatched domains.
Waiting for verification...
Cleaning up challenges
Unable to clean up challenge directory /usr/share/nginx/html/.well-known/acme-challenge
IMPORTANT NOTES:
- The dry run was successful.
Here is the letsencrypt.log https://gist.github.com/sahsanu/773de6c00958107b1fdb7e31c5985a2c
So, this time it validated correctly and I could get my cert ;).
If you check the logs, when using the ip redirection we get this:
"validationRecord": [
{
"url": "http://198.98.49.246/.well-known/acme-challenge/4Zl8HupWU_1bE6Hg3LsG2thRo3aH1umKRHd_b-ZgDUE",
"hostname": "198.98.49.246",
"port": "80",
"addressesResolved": [],
"addressUsed": "",
"addressesTried": []
},
{
"url": "http://redirect.27a.net/.well-known/acme-challenge/4Zl8HupWU_1bE6Hg3LsG2thRo3aH1umKRHd_b-ZgDUE",
"hostname": "redirect.27a.net",
"port": "80",
"addressesResolved": [
"163.172.166.61"
],
"addressUsed": "163.172.166.61",
"addressesTried": []
}
So it can’t resolve the ip "addressesResolved": [], "addressUsed": "", and seems Let’s Encrypt needs to resolve all redirections.
Using the domain in the redirection, we get this:
"validationRecord": [
{
"url": "http://198.98.49.246.dnsip.xyz/.well-known/acme-challenge/5dwvKomtuF-VLXWjXYviOvIbhDSM-I5TiqCxYfoyi1Q",
"hostname": "198.98.49.246.dnsip.xyz",
"port": "80",
"addressesResolved": [
"198.98.49.246"
],
"addressUsed": "198.98.49.246",
"addressesTried": []
},
{
"url": "http://redirect.27a.net/.well-known/acme-challenge/5dwvKomtuF-VLXWjXYviOvIbhDSM-I5TiqCxYfoyi1Q",
"hostname": "redirect.27a.net",
"port": "80",
"addressesResolved": [
"163.172.166.61"
],
"addressUsed": "163.172.166.61",
"addressesTried": []
}
So in this case it can resolve the redirection and will use that info to follow it "addressesResolved": ["198.98.49.246"], addressUsed": "198.98.49.246",
I don’t know the reason for this behaviour but I suppose there is some good reason ;).
Cheers,
sahsanu