Letsencrypt DNS Challenge not working for subdomain

[pstreef]

Do you want to request a feature or report a bug?

Bug

What did you do?

Using: dnsProvider = "cloudflare"
when I use a top level domain "example.com" the challenge works. However when using a domain like "sub.example.com" it does not.

What did you expect to see?

A certificate securing my app.

What did you see instead?

No certificate

Output of traefik version: (What version of Traefik are you using?)

v1.3.5 / raclette docker image

What is your environment & configuration (arguments, toml, provider, platform, ...)?

traefikLogsFile = "/var/log/traefik/traefik.log"
accessLogsFile = "/var/log//traefik/access.log"
logLevel = "DEBUG"

defaultEntryPoints = ["http","https"]
[entryPoints]
  [entryPoints.http]
  address = ":80"
    [entryPoints.http.redirect]
      entryPoint = "https"
  [entryPoints.https]
  address = ":443"
    [entryPoints.https.tls]

[acme]
email = "ict@example.com"
storage = "acme.json"
entryPoint = "https"
acmeLogging = true
onDemand = true
dnsProvider = "cloudflare"
[[acme.domains]]
   main = "sub1.example.com"
   sans = ["sub2.example.com", "sub3.example.com"]

[docker]
endpoint = "unix:///var/run/docker.sock"
domain = "example.com"
watch = true
exposedbydefault = false
swarmmode = true

[web]
address = ":8080"
  [web.auth.basic]
    users = ["admin:thisisnotapassword"]

Obviously I do not really use example.com

If applicable, please paste the log output in debug mode (--debug switch)

legolog: 2017/08/14 07:25:11 [INFO] acme: Registering account for ict@example.com
legolog: 2017/08/14 07:25:12 [INFO][sub1.example.com, sub2.example.com, sub3.example.com] acme: Obtaining bundled SAN certificate
legolog: 2017/08/14 07:25:13 [INFO][sub1.example.com] AuthURL: https://acme-v01.api.letsencrypt.org/acme/authz/bla
legolog: 2017/08/14 07:25:13 [INFO][sub2.example.com] AuthURL: https://acme-v01.api.letsencrypt.org/acme/authz/bla
legolog: 2017/08/14 07:25:13 [INFO][sub3.example.com] AuthURL: https://acme-v01.api.letsencrypt.org/acme/authz/bla
legolog: 2017/08/14 07:25:13 [INFO][sub1.example.com] acme: Could not find solver for: tls-sni-01
legolog: 2017/08/14 07:25:13 [INFO][sub1.example.com] acme: Trying to solve DNS-01
legolog: 2017/08/14 07:25:13 [INFO][sub2.example.com] acme: Trying to solve DNS-01
legolog: 2017/08/14 07:25:13 [INFO][sub3.example.com] acme: Could not find solver for: http-01
legolog: 2017/08/14 07:25:13 [INFO][sub3.example.com] acme: Trying to solve DNS-01
legolog: 2017/08/14 07:25:23 [INFO][sub1.example.com] acme: Obtaining bundled SAN certificate
legolog: 2017/08/14 07:25:24 [INFO][sub1.example.com] AuthURL: https://acme-v01.api.letsencrypt.org/acme/authz/bla
legolog: 2017/08/14 07:25:24 [INFO][sub1.example.com] acme: Trying to solve DNS-01
2017/08/14 07:25:24 server.go:2753: http: TLS handshake error from 10.255.0.4:65088: Cannot obtain certificates map[sub1.example.com:Error presenting token: Zone sub1.example.com. not found in CloudFlare for domain _acme-challenge.sub1.example.com.]+v

The bug itself seems to be in the way Lego is used/Lego itself:

the function getHostedZoneID() tries to get a cloudflare zoneId (id for example.com) but in stead it uses sub1.example.com and fails on getting the zoneId.

[pstreef]

Diving deeper into lego it seems that it should return the correct domain on a SOA record response, but apperantly this goes wrong somehow. Am I doing something wrong here, do I need to change something from the default cloudflare setup? I'm currently forced to go back to self signed certs with my own CA which I would really like to avoid.

[pstreef]

It turns out our internal dns returns a SOA record for the subdomain. returning the name of the subdomain in stead of the root domain.

[EugenMayer]

@sjintas did you subdomain match you search/domain path of the server? because that is what i just ran into.

so basically if search/domain is foo.bar.tld ( of the traefik server) and you try to issue any subdomain of that so sub.foo.bar.tld it will fail. Removing the search/domain from the /etc/resolv.conf fixes this again.

We have an own DNS server to, which traefik is using, so maybe its the same issue?

[pstreef]

I can't say I remember exactly but I do not think so. However it might still be the same issue. Just check out the SOA response manually.

[EugenMayer]

Well digging arround, its exactly the same, just in my case, not SOA is returned and @mmatur was explainting that the lega go acme library queries its current DNS for the SOA record to be able to poll for the TXT record being created..

Since i run a unbound server that SOA record is not present ( its the default unbound in opnsense/pfsense ) and i am right now expecting this being an issue for every isolated network .. which would be the DNA scenario of DNS01 i guess.

No idea how to proceed with that

[mylesagray]

Just a note to anyone else who comes across this - when using the helm chart I was able to overcome the SOA problem by setting the below params:

acme:
  resolvers:
  - abby.ns.cloudflare.com
  - sid.ns.cloudflare.com