cloudflare: error getting certificate for sub-subdomain

When I try to get a certificate for an address like a.b.c.com instead of just b.c.com, it fails. I’m using v2.2.0-rc.1. Not sure if this is a bug or if I’m missing something in the configuration.

Caddyfile:

foo.bar.baz.com {
    tls me@baz.com {
        dns cloudflare my-api-key-goes-here
        ca https://acme-staging-v02.api.letsencrypt.org/directory
    }
}

Gives the error:

2020/08/12 23:33:19 [INFO] [foo.bar.baz.com] acme: use dns-01 solver
2020/08/12 23:33:19 [INFO] [foo.bar.baz.com] acme: Preparing to solve DNS-01
2020/08/12 23:33:20 [INFO] [foo.bar.baz.com] acme: Cleaning DNS-01 challenge
2020/08/12 23:33:20 [WARN] [foo.bar.baz.com] acme: cleaning up failed: no memory of presenting a DNS record for foo.bar.baz.com 
2020/08/12 23:33:20 [INFO] Deactivating auth: https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/93420171
2020/08/12 23:33:20 [ERROR] error: one or more domains had a problem:
[foo.bar.baz.com] [foo.bar.baz.com] acme: error presenting token: got error status: HTTP 403: [{Code:0 Message:Actor 'com.cloudflare.api.token.c8a1af1c44011cc50326adf273f7413c' requires permission 'com.cloudflare.api.account.zone.read' to list zones}]
 (challenge=dns-01 remaining=[])
2020/08/12 23:33:22 [ERROR] attempt 1: [foo.bar.baz.com] Obtain: [foo.bar.baz.com] error: one or more domains had a problem:
[foo.bar.baz.com] [foo.bar.baz.com] acme: error presenting token: got error status: HTTP 403: [{Code:0 Message:Actor 'com.cloudflare.api.token.c8a1af1c44011cc50326adf273f7413c' requires permission 'com.cloudflare.api.account.zone.read' to list zones}]
 - retrying in 1m0s (3.988028658s/720h0m0s elapsed)...

The API key I’m using has the required Zone.Zone and Zone.DNS permissions, and everything works as it should if I change the hostname to bar.baz.com in the Caddyfile. I can also use this same API key with another ACME client (acme.sh) and sucessfully get a certificate for foo.bar.baz.com.

On a side note, Caddy v1 also had problems with this config, it would print a message like:

[foo.bar.baz.com] [foo.bar.baz.com] acme: error presenting token: cloudflare: failed to find zone bar.baz.com.: Zone could not be found

p.s, thanks for Caddy, I haven’t used v2 much yet, but v1 has been wonderfully easy to configure and stable.

About this issue

Original URL
State: closed
Created 4 years ago
Comments: 15 (8 by maintainers)

Most upvoted comments

@mholt I’m glad you pointed me to the code. I’m still learning Go but the syntax made a million times more sense when I read through acmeissuer.go. User-error on my part.

I didn’t realize that the dns subdirective is a shortcut to an acme template (explained here). This Caddyfile worked to produce the correct JSON configuration, I just had to manually specify the acme parameters:

example.com {
    root * /var/caddy/example.com
    file_server
    tls {
        issuer acme {
            dir https://acme-staging-v02.api.letsencrypt.org/directory
            dns cloudflare <api_token>
            resolvers 1.1.1.1 1.0.0.1
        }
    }
}

This JSON is produced:

{
    "apps": {
      "http": {...},
      "tls": {
        "automation": {
          "policies": [
            {
              "subjects": ["example.com"],
              "issuers": [
                {
                  "ca": "https://acme-staging-v02.api.letsencrypt.org/directory",
                  "challenges": {
                    "dns": {
                      "provider": {
                        "api_token": "<api_token>",
                        "name": "cloudflare"
                      },
                      "resolvers": ["1.1.1.1", "1.0.0.1"]
                    }
                  },
                  "module": "acme"
                }
              ]
            }
          ]
        }
      }
    }
  }

Log output when DNS is using my internal DNS:

2020/11/21 20:39:54.266	ERROR	tls.obtain	will retry	{"error": "[example.com] Obtain: [example.com] solving challenges: presenting for challenge: adding temporary record for zone com.: expected 1 zone, got 0 for com. (order=https://acme-staging-v02.api.letsencrypt.org/acme/order/.../...) (ca=https://acme-staging-v02.api.letsencrypt.org/directory)", "attempt": 1, "retrying_in": 60, "elapsed": 0.886847867, "max_duration": 2592000}

Log output using above Caddyfile, successfully hitting 1.1.1.1 for the challenge:

2020/11/21 20:41:56.102	INFO	tls.issuance.acme.acme_client	trying to solve challenge	{"identifier": "example.com", "challenge_type": "dns-01", "ca": "https://acme-staging-v02.api.letsencrypt.org/directory"}
2020/11/21 20:41:59.483	INFO	tls.issuance.acme.acme_client	validations succeeded; finalizing order	{"order": "https://acme-staging-v02.api.letsencrypt.org/acme/order/.../..."}
2020/11/21 20:41:59.851	INFO	tls.issuance.acme.acme_client	successfully downloaded available certificate chains	{"count": 2, "first_url": "https://acme-staging-v02.api.letsencrypt.org/acme/cert/..."}
2020/11/21 20:41:59.852	INFO	tls.obtain	certificate obtained successfully	{"identifier": "example.com"}

will528 on Nov 21, 2020

Great! I’ll close the issue then but if it’s confirmed to still be an issue, we can reopen it… I hope not though.

mholt on Nov 21, 2020

I think so! I’m curious if @emfrias would have their issue resolved now on 2.2.1. They mentioned they were experiencing the issue on 2.2.0, and the related commits I see are tagged with 2.2.1. I’m on 2.2.1 and it’s working perfectly with the Caddyfile I included above.

Really appreciate the help!

will528 on Nov 21, 2020

@will528 Would you mind digging into the code and finding out why? It works for me, and I haven’t found anyone who can reproduce the issue and trace it down. Add some fmt.Println() statements to see what is going on.

mholt on Nov 21, 2020