traefik: LetsEncrypt DNS-01 fails when mixing domains with wildcard subdomains.

This may be a bug with ACME, but I’m not technical enough to know, and I’m using Traefik, so reporting it here.

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

Bug

What did you do?

I’m using the traefik docker image. I configured and run it, and immediately the certificates are rejected only when mixing wildcard domains.

What did you expect to see?

Wildcard subdomains to be allowed.

What did you see instead?

time="2018-06-10T21:15:43Z" level=error msg="Unable to obtain ACME certificate for domains \"*.EVERYDOMAIN.com,EVERYDOMAIN.com\" : cannot obtain certificates: acme: Error -> One or more domains had a problem:\n[EVERYDOMAIN.com] acme: Error 403 - urn:ietf:params:acme:error:unauthorized - Incorrect TXT record \"HASH HERE\" found at _acme-challenge.EVERYDOMAIN.com\n"

Points of interest: This only happens if the wildcard domains is listed with the main domain. Setting a delay of 5s did not fix this. It is apparently able to set the TXT record; I’m not getting a permission error. I believe the provider (Cloudflare) has to verify that TXT record is set before ACME even checks?

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

Version:      v1.6.3
Codename:     tetedemoine
Go version:   go1.10.2
Built:        2018-06-05_03:29:01PM
OS/Arch:      linux/amd64

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

defaultEntryPoints = ["http", "https"]

[acme]
  email = "..."
  entryPoint = "https"
  onHostRule = true
  storage = "acme.json"
  [acme.dnsChallenge]
    delayBeforeCheck = 0
    provider = "cloudflare"

[[acme.domains]]
  main = "*.MYDOMAIN.com"
  sans = ["MYDOMAIN.com"]

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

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

The environment has cloudflare email and cloudflare api key in it.

When I set the wildcard subdomains to be their own main entry and the domain to be its own main entry, it works without error.

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Comments: 33 (12 by maintainers)

Most upvoted comments

Hello @anatolinicolae , as said previously, the issue comes from the TXT record names needed by ACME (the domain *.foo.com and the domain foo.com need the same TXT record name). That’s why you can generate successfully the certificate if the root domain is not a SAN of the wildcard domain.

@dimm0 , as @leebenson said, it’s not the only issue. If you need ACME by using multiple instances of Træfik, you may take a look to the way share configuration and ACME certificates between multiple instances of træfik here.

Note that, it’s possible to generate a certifcate for a wildcard domain and its root domain but, the results are flaky. This flakyness is due to the different timeouts to manage and, sometimes, to the time for ACME to get a response…

For the moment, as a workaround, you can:

  • Set the wildcard domain and the root domain in 2 different certificates (not the best thing due to the rate limiting but, in lot of cases that can help)
  • Set the option acme.dnschallenge.provider to manual and check that the first TXT record has been cleared before to create the second one (thanks to a dig command for example).

Sure these solutions are not perfect but we are currenlty looking for a better one. I’ll give you some feedbacks in function of the advancement of the task.

I set mine up back when this was still an issue, I havent tried it since this issue was fixed and closed. Mine is still set with no sans and multiple main

so my config is like so:

[[acme.domains]]
  main = "*.example.com"
[[acme.domains]]
  main = "example.com"

I just removed my acme.json file and changed my config to be this style and it successfully repulled my certificates with the sans url

[[acme.domains]]
  main = "*.example.com"
  sans = ["example.com"]

So for me it worked both ways

Do you have any log info? Can you verify what version you are running.

@nmandery I guess I’ll stick with the bugfix, thanks for all the hard works!

@BirkhoffLee

I guess I found the problem, as described below, if you can reset your æcme.json file it can be a work-around.

If you cannot delete this file, you can add the field KeyType: "4096", instead of KeyType: "" in the file.

PR is coming soon.