New certificate fails to install with DNS error on the domain

how · April 8, 2018, 2:46pm

Hi, I’ve installed LE certificates for a while using the same technique and suddenly on this machine the process fails with the DNS. It seems that LE servers have cached a wrong response for too long. I retried a few times over the last two weeks but DNS resolution still seems to fail. Can someone help?

My domain is: federated.public-infrastructure.eu

I ran this command: letsencrypt certonly --agree-tos --webroot -w /var/www/certbot -d federated.public-infrastructure.eu

It produced this output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for federated.public-infrastructure.eu
Using the webroot path /var/www/certbot for all unmatched domains.
Waiting for verification...
Cleaning up challenges
Unable to clean up challenge directory /var/www/certbot/.well-known/acme-challenge
Failed authorization procedure. federated.public-infrastructure.eu (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://federated.public-infrastructure.eu/.well-known/acme-challenge/ieMTSS27LGpXnEe_YERTkwE1LpKOROoA6Leq4OEblM0: Timeout

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: federated.public-infrastructure.eu
   Type:   connection
   Detail: Fetching
   http://federated.public-infrastructure.eu/.well-known/acme-challenge/ieMTSS27LGpXnEe_YERTkwE1LpKOROoA6Leq4OEblM0:
   Timeout

   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.

Relevant log:

Content-Type: application/json
Content-Length: 1535
Link: <https://acme-v01.api.letsencrypt.org/acme/new-cert>;rel="next"
Replay-Nonce: nMS5LA-60TIWtRqDHlXjyR21k_fAobRACv_G2s_hock
X-Frame-Options: DENY
Strict-Transport-Security: max-age=604800
Expires: Sun, 08 Apr 2018 14:22:00 GMT
Cache-Control: max-age=0, no-cache, no-store
Pragma: no-cache
Date: Sun, 08 Apr 2018 14:22:00 GMT
Connection: keep-alive

{
  "identifier": {
    "type": "dns",
    "value": "federated.public-infrastructure.eu"
  },
  "status": "invalid",
  "expires": "2018-04-15T14:21:47Z",
  "challenges": [
    {
      "type": "http-01",
      "status": "invalid",
      "error": {
        "type": "urn:acme:error:connection",
        "detail": "Fetching http://federated.public-infrastructure.eu/.well-known/acme-challenge/ieMTSS27LGpXnEe_YERTkwE1LpKOROoA6Leq4OEblM0: Timeout",
        "status": 400
      },

Checklist:

DNS record:

$ host federated.public-infrastructure.eu
federated.public-infrastructure.eu has address 195.201.114.143
federated.public-infrastructure.eu has IPv6 address 2a01:4f8:1c0c:7ab0::
$ dig A federated.public-infrastructure.eu
...
federated.public-infrastructure.eu. 798 IN A    195.201.114.143

Web responds: here is a test curl output to return a simple plain text file containing ‘ok’:

curl -ikL http://federated.public-infrastructure.eu/.well-known/acme-challenge/REJtGMMjSnP_1MxrwPBwzAHwiKV0Zm3VJGq1tvHKe0E
HTTP/1.1 200 OK
Server: nginx/1.10.3
Date: Sun, 08 Apr 2018 14:13:34 GMT
Content-Type: text/plain
Content-Length: 3
Last-Modified: Mon, 02 Apr 2018 20:36:46 GMT
Connection: keep-alive
ETag: "5ac2945e-3"
Accept-Ranges: bytes

ok

Home page responds: http://federated.public-infrastructure.eu/
Challenge file is properly written and accessible during letsencrypt run.

My web server is: nginx version: nginx/1.10.3

The operating system my web server runs on is: Debian GNU/Linux 9 (stretch)

My hosting provider is: Hetzner cloud

I can login to a root shell on my machine: yes

I’m using a control panel to manage my site: no

sahsanu · April 8, 2018, 2:59pm

Hi @how,

Let’s Encrypt prefers IPv6 over IPv4 and your domain is advertising an AAAA record but it is not possible to connect to your domain using that IPv6 address:

Using IPv4:

$ curl -4ikL -m10 http://federated.public-infrastructure.eu/.well-known/acme-challenge/REJtGMMjSnP_1MxrwPBwzAHwiKV0Zm3VJGq1tvHKe0E
HTTP/1.1 200 OK
Server: nginx/1.10.3
Date: Sun, 08 Apr 2018 14:53:49 GMT
Content-Type: text/plain
Content-Length: 3
Last-Modified: Mon, 02 Apr 2018 20:36:46 GMT
Connection: keep-alive
ETag: "5ac2945e-3"
Accept-Ranges: bytes

ok

Using IPv6:

$ curl -6ikL -m10 http://federated.public-infrastructure.eu/.well-known/acme-challenge/REJtGMMjSnP_1MxrwPBwzAHwiKV0Zm3VJGq1tvHKe0E
curl: (28) Connection timed out after 10001 milliseconds

Also, the IPv6 address advertised for your domain does not seem a right one. You should fix the IPv6 issue or remove the AAAA record for your domain.

Cheers,
sahsanu

how · April 8, 2018, 3:48pm

Ha! That explains it. Thank you very much @sahsanu, I'll fix that.

Hmm, the nginx is configured to listen [::]:80 and listen [::]:443, and the network seems fine.

root@federated ~ # nginx -V | grep ipv6
nginx version: nginx/1.10.3
built with OpenSSL 1.1.0f  25 May 2017
TLS SNI support enabled
configure arguments: ... --with-ipv6 ...
root@federated ~ # netstat -nlp | grep nginx
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      14863/nginx: master
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      14863/nginx: master
tcp6       0      0 :::443                  :::*                    LISTEN      14863/nginx: master
tcp6       0      0 :::80                   :::*                    LISTEN      14863/nginx: master

sahsanu · April 8, 2018, 3:59pm

@how, could you please show the output of ip a command?

how · April 8, 2018, 4:03pm

root@federated ~ # ip -6 r
2a01:4f8:1c0c:7ab0::/64 dev eth0 proto kernel metric 256  pref medium
fe80::/64 dev eth0 proto kernel metric 256  pref medium
default via fe80::1 dev eth0 metric 1024  pref medium
root@federated ~ # ip -6 addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 2a01:4f8:1c0c:7ab0::1/64 scope global deprecated
       valid_lft forever preferred_lft 0sec
    inet6 fe80::9400:ff:fe08:f21c/64 scope link
       valid_lft forever preferred_lft forever

Maybe the ‘deprecated’ tells me something.

sahsanu · April 8, 2018, 4:08pm

The problem, as I said above is that the AAAA record for your domain is using a wrong IPv6 address.

The right one is 2a01:4f8:1c0c:7ab0::1 but in your AAAA record you are using 2a01:4f8:1c0c:7ab0::, you forgot the last 1. Change the AAAA record, check it is propagated to all your authoritative dns servers and try again.

Cheers,
sahsanu

how · April 8, 2018, 4:11pm

Yes, I just did this. Sorry for misreading you. The validation should happen soon.

how · April 8, 2018, 5:26pm

Thank you @sahsanu for figuring out the wrong AAAA record in the DNS!

system · May 8, 2018, 5:26pm

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

Topic		Replies	Views
Certificate Install Trouble Help	12	1442	April 23, 2018
DNS challenge keeps failing Help	14	3658	November 28, 2020
Trouble verifying domains Help	17	24240	December 2, 2015
Letsencrypt failing on _acme_challenge error Help	8	375	July 23, 2024
Certbot Verification Issue (Challenge failed for domain) Help	5	17969	January 10, 2020

New certificate fails to install with DNS error on the domain

Related topics