How to "enable the DNS challenge" for Wildcard domain names

Help
1

Hello, another problem with my migration to the v2 :frowning:

1. My Caddy version (caddy version):

v2.0.0-beta.20

2. How I run Caddy:

Following the V2 documentation

a. System environment:

VPS Ubuntu 18.x with systemd
I start with systemctl start caddy

d. My complete Caddyfile or JSON config:

stage.example.com, *.stage.example.com {
        root * /var/www/html

        php_fastcgi / unix//var/run/php/php7.4-fpm.sock

        encode gzip
        file_server

        tls {
                dns digitalocean
        }
}

My caddy.service file

[Unit]
Description=Caddy Web Server
Documentation=https://caddyserver.com/docs/
After=network.target

[Service]
User=caddy
Group=caddy
ExecStart=/usr/bin/caddy run --config /etc/caddy/Caddyfile --resume --environ
ExecReload=/usr/bin/caddy reload --config /etc/caddy/Caddyfile
TimeoutStopSec=5s
LimitNOFILE=1048576
LimitNPROC=512
PrivateTmp=true
ProtectSystem=full
AmbientCapabilities=CAP_NET_BIND_SERVICE

; Letsencrypt-issued certificates will be written to this directory.
Environment=CADDYPATH=/etc/ssl/caddy DO_AUTH_TOKEN=xxxxxxxxxxxx

[Install]
WantedBy=multi-user.target

3. The problem I’m having:

I use a droplet from Digital Ocean, but the domain name is from another provider (it redirects to the DO IP address).

On a droplet, I want to have stage.example.com serving a page, and *.stage.example.com pattern such
host1.stage.example.com
host2.stage-example.com
…

=> Wildcard Attribution

4. Error messages and/or full log output:

systemctl status caddy

Mar 30 18:22:56 myVPS caddy[7873]: 2020/03/30 18:22:56 [INFO] [*.stage.example.com] acme: Obtaining bundled SAN certificate given a CSR
Mar 30 18:22:57 myVPS caddy[7873]: 2020/03/30 18:22:57 [INFO] [*.stage.example.com] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz-v3/3657295xxx
Mar 30 18:22:57 myVPS caddy[7873]: 2020/03/30 18:22:57 [INFO] [*.stage.example.com] acme: Could not find solver for: dns-01
Mar 30 18:22:57 myVPS caddy[7873]: 2020/03/30 18:22:57 [INFO] Deactivating auth: https://acme-v02.api.letsencrypt.org/acme/authz-v3/3657295xxx
Mar 30 18:22:57 myVPS caddy[7873]: 2020/03/30 18:22:57 [ERROR] acme: Error -> One or more domains had a problem:
Mar 30 18:22:57 myVPS caddy[7873]: [*.stage.example.com] [*.stage.example.com] acme: could not determine solvers
Mar 30 18:22:57 myVPS caddy[7873]:  (challenge=http-01 remaining=[])
Mar 30 18:22:59 myVPS caddy[7873]: 2020/03/30 18:22:59 [ERROR] attempt 1: [*.stage.example.com] Obtain: [*.stage.example.com] acme: Error -> One or more domains had a problem:
Mar 30 18:22:59 myVPS caddy[7873]: [*.stage.example.com] [*.stage.example.com] acme: could not determine solvers
Mar 30 18:22:59 myVPS caddy[7873]:  - retrying in 1m0s (6.904590157s/720h0m0s elapsed)...

I really don’t get how to solve this.

Thanks for reading :slight_smile:

2

Hi @Aster,

You will need to build Caddy with a DNS provider module if you haven’t already done so.

To build with modules, you’ll need to follow these steps: GitHub - caddyserver/caddy: Fast, multi-platform web server with automatic HTTPS

The DNS provider modules currently available are Cloudflare, DigitalOcean, and DNSimple. Instructions on using them are over here at their repository: https://github.com/caddyserver/tls.dns#using-them-in-caddy

Note that you will need to configure Caddy with JSON as this functionality is not exposed in the Caddyfile at the moment.

3

Annnd the config for those plugins might be changing, so be aware of that. The reason there aren’t more is because some things need to be changed upstream first.

1 Like
4

(Hey @matt, shouldn’t the Caddyfile parser have spat out an error for attempting to use tls { dns digitalocean } in a v2 Caddyfile?)

5

Eek, nope – good catch… technically that’s implemented but it’s just undocumented for right now because the DNS provider integration is still incomplete!

6

First thanks for your answer :slight_smile:

Okay, so I followed the steps here GitHub - caddyserver/caddy: Fast, multi-platform web server with automatic HTTPS
And have a custom build with digitalocean module.

Now I want to use the JSON file instead of caddyfile, as you said.

Should I export the config caddy adapt --config ./Caddyfile | jq, copy the output to caddy.json and then add the tls part?
Where to add it exactly? Because the 2 links in “Using them in Caddy” https://github.com/caddyserver/tls.dns#using-them-in-caddy are dead :confused:

I would add it in a config.json such:

{
  "apps": {
    "https": {
      <my config from "caddy adapt --config ./Caddyfile | jq">
    },
    "tls": {
      "automation": {
        "policies": [{
          "hosts": ["*.subdomain.domain.com"],
          "issuer": {
            "module": "acme",
            "challenges": {
              "dns": {
                "provider": "digitalocean",
                "auth_token": "token"
              }
            }
          }
        }]
      }
    }
  }
}

Is it normal that I don’t have tls.provider.digitalocean when I run caddy list-modules?

7

Yep, this looks correct to me!

Link is indeed dead because we changed a JSON key name, so the config path went from apps/tls/automation/policies/management/acme to apps/tls/automation/policies/issuer/acme (management → issuer). There was another dead link I noted higher up the page that I passed along to @matt but I didn’t catch those ones.

Not sure. I think they should be there. I know there was some discussion a while back about pluggable config adapters also not showing up. Another cc @matt for this question, I think.

8

Might be a bug in the docs generator, hopefully will be fixed with rc1, as it should no longer thing beta 9 is the most recent version…

This would be unrelated. If the module is plugged in, it will be in that list. If it’s not in that list, it is not plugged in…

1 Like
9

Is the README for the caddyserver/tls.dns repo generated?

10

Oh, that’s what you meant… no… it’s not. Oops.

1 Like
11

Thanks for your help but didn’t succeed to make it works.

I will try again later when the beta will be over I think :slight_smile:

Have a nice day

12

will the Production Version have this baked in OR we still have to compile?

13

There’s a few concerns that make this question hard to answer. Size is one; I remember in v1 the question was raised of whether we effectively wanted to double (?) the binary size by baking them in.

I think there’s also some ongoing questions regarding how the providers are wrapped and how the upstream library handles things.

@matt, do you wanna weigh in on this question?

1 Like
14

Basically, lego’s current exported API doesn’t accommodate Caddy 2’s requirements, so while I did port a few providers over and a few more are in a PR queue, they’re just not satisfactory.

There’s a library called StackExchange/dnscontrol which is kind of neat, where you say “I want my zone file to look like this – make it so”, and their DNS provider implementations (and there are many, but not nearly as many as lego has, because these are more involved) figure out which changes need to happen and just do them. But, this essentially requires that you maintain a master list of DNS records, which Caddy obviously doesn’t have.

While lego’s DNS providers can only “Present” and “CleanUp” ACME challenges (basically a single TXT record), the providers in StackExchange/dnscontrol can only reset the entire zone! Lego’s API is too limited and inflexible, and StackExchange’s API is also too narrow, but on the opposite end of the spectrum in that it makes too many changes.

I need an API that allows us to be able to Append, Set, Get, and Delete records, as well as doing Set+Delete in transactional batches. This will allow Caddy modules to do things that can’t currently be done. For example, I’m writing an experimental dynamic DNS app for Caddy that updates A records to stay pointed at the beacon (server).

Oh, and I want the library to not bundle in every DNS provider known to man in the core repo/Go module, so that go.sum isn’t 1000+ lines. Simply importing lego or dnscontrol currently increases binary sizes by about 20 MB, even without needing any of the DNS provider implementations!

And whatever DNS API is used, needs to be flexible enough to meet Caddy’s rigorous configuration requirements.

Since no library that meets these criteria currently exists, I will have to write one.

I’ve forked lego and am writing my own DNS provider library (inspired by StackExchange/dnscontrol) which has an all-new, more flexible API. It should allow existing DNS providers in lego to be grandfathered in pretty easily, while providing the right granularity for other features down the road.

It might be a while, definitely not within the next week. More on the order of months. And I’ll need the community’s help to add providers. I will design the core library and port one or two providers as a starting point, but this is a huge undertaking: Lego has, like, 70+ providers now? And dnscontrol has a couple dozen I think. The community will have to help port them over and maintain this code base instead.

3 Likes
15

Just kidding - all 75 DNS providers are available already, as a temporary shim, and the new interfaces are ready to be ported to: Caddy 2 can support all 75+ DNS providers - #3

1 Like
16

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