Can't get a certificate, ACME fails oddly

Help
1

1. My Caddy version (caddy -version):

v2.0.0-beta10 h1:MkLEoR4kj30H90sZ4YBg9O7sd4Zrl77H0m3mW9gyEmE=

2. How I run Caddy:

sudo caddy start

It’s listening on all ports:

~> sudo netstat -tulpn | grep caddy
tcp        0      0 127.0.0.1:2019          0.0.0.0:*               LISTEN      1889923/caddy
tcp6       0      0 :::443                  :::*                    LISTEN      1889923/caddy
tcp6       0      0 :::444                  :::*                    LISTEN      1889923/caddy
tcp6       0      0 :::80                   :::*                    LISTEN      1889923/caddy
tcp6       0      0 :::81                   :::*                    LISTEN      1889923/caddy

a. System environment:

Archlinux, no Docker, no anything.

b. Command:

I’ve started caddy and set my config as the following:

{
  "apps": {
    "http": {
      "servers": {
        "example": {
          "listen": [
            ":443"
          ],
          "routes": [
            {
              "match": [
                {
                  "host": [
                    "x.bigsun.xyz"
                  ]
                }
              ],
              "handle": [
                {
                  "handler": "reverse_proxy",
                  "upstreams": [
                    {
                      "dial": "localhost:6187"
                    }
                  ]
                }
              ]
            }
          ]
        }
      }
    }
  }
}

3. The problem I’m having:

Apparently Caddy gets an error when trying to browse some Letsencrypt HTTP endpoint, https://acme-v02.api.letsencrypt.org/directory. However I can browse that. I can curl that. All works.

4. Error messages and/or full log output:

A big stream of this:

2019/12/19 06:55:03 [ERROR] Making new certificate manager: get directory at 'https://acme-v02.api.letsencrypt.org/directory': Get https://acme-v02.api.letsencrypt.org/directory: dial tcp: lookup acme-v02.api.letsencrypt.org on [::1]:53: read udp [::1]:37996->[::1]:53: read: connection refused (attempt 1/3)
2019/12/19 06:55:04 [ERROR] Making new certificate manager: get directory at 'https://acme-v02.api.letsencrypt.org/directory': Get https://acme-v02.api.letsencrypt.org/directory: dial tcp: lookup acme-v02.api.letsencrypt.org on [::1]:53: read udp [::1]:48850->[::1]:53: read: connection refused (attempt 2/3)
2019/12/19 06:55:05 [ERROR] Making new certificate manager: get directory at 'https://acme-v02.api.letsencrypt.org/directory': Get https://acme-v02.api.letsencrypt.org/directory: dial tcp: lookup acme-v02.api.letsencrypt.org on [::1]:53: read udp [::1]:33932->[::1]:53: read: connection refused (attempt 3/3)
2019/12/19 06:55:06 [ERROR] x.bigsun.xyz: obtaining certificate: get directory at 'https://acme-v02.api.letsencrypt.org/directory': Get https://acme-v02.api.letsencrypt.org/directory: dial tcp: lookup acme-v02.api.letsencrypt.org on [::1]:53: read udp [::1]:33932->[::1]:53: read: connection refused - backing off and retrying (attempt 8/29)...
2

This is a curious one I’ve seen a few times in the past, and once recently, if I recall.

For some reason, Caddy is trying to use its own host server ([::1]:53) for DNS resolution.

I’m guessing you don’t run a DNS resolver on your Caddy host server - hence, when it tries to connect to do a DNS lookup, it the connection is rejected.

I don’t know if it was definitively resolved as to the cause of this issue. In the most recent case, we talked a bit about how Go programs do DNS resolution, specifically in the net/http module. The person with the issue eventually reinstalled Caddy and the systemd unit file they were using, but that was with v1.

1 Like
3

Thank you for identifying my problem. Indeed it was a DNS issue. Turns out my /etc/resolv.conf was empty because I’m using ArchLinux and forgot to symlink it to the resolv.conf stub file generated by systemd-resolved. Because of that I think Caddy was trying to search its own DNS server which didn’t exist also.

The solution was to follow the manual and create the symlink:

sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf

I think it would be solved (too depending on the system) by manually editing /etc/resolv.conf (at least temporarily).

3 Likes
4

Thank you for following-up! This is an obscure error, so I think this will help a lot of future searchers.

5

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