Support multiple ACME challenge types at the same time

[EugenMayer]

What did you expect to see?

I tried to use both ACME challenge types, dns-01 and http to cover the following needs:

The traefik instance maintains several different domains, from which some:

a) are not controlled by our DNS ( and cannot be controlled by our DNS ): http only
b_ most are part of our DNS: http or dns-01 could be done

No, one could argue i can simply use http for both cases - solved. The problem is, most of the domains in b) are used internally ( public tld ) and have no public DNS entry, so http would not be possible.

I end up being in a deadlock where i can either validate a) or b) - not both. I used some trickery and created more traefik instances to cover with only that - different ACME challenges.

It would be really great to actually handle both.

Propsal

To simplify the development and "decision"

• Offer a default challenge type in the ACME namespace like acme.default_challenge which can be http or dns_<provider>
• make it possible to override the default in the frontend, so

  # sets just the type and uses the default implementation. for http its obvious, for dns uses the first 
  defined provider
  frontends.<frontend>.acme_challenge_type=<http/dns>
  # could be an option later, not in this FR, to select one of the providers if several are defined ( 
  optional )
  frontends.<frontend>.acme_challenge_integration=<provider>
  

[verglor]

It should be also possible to specify challenge type in docker label.

[zeeshanjamal16]

Any update on this topic please as this has become a crucial feature in our application.

[nocgp]

Meet same issue need to have both dns and http challenge in traefik instance

could be acme.domain.httpChallenge option

[kajmagnus]

In my case, this is needed for 1) a wildcard cert, *.mydomain.com, whose DNS server I control (only DNS challenges work for wildcard certs, right). Plus 2) certificates for my users' custom domains, some.other-domain.com, elsewhere.com, elsewhere2.com etc, whose DNS servers I do not have access to — so DNS challenge wouldn't work? only HTTP challenges works, right. That is, in this case, both DNS and HTTP challenges needed.

[ldez]

I'm working on that, so stay tuned 😉

[kj3slyn]

In my case, this is needed for 1) a wildcard cert, *.mydomain.com, whose DNS server I control (only DNS challenges work for wildcard certs, right). Plus 2) certificates for my users' custom domains, some.other-domain.com, elsewhere.com, elsewhere2.com etc, whose DNS servers I do not have access to — so DNS challenge wouldn't work? only HTTP challenges works, right. That is, in this case, both DNS and HTTP challenges needed.

I'm in the same boat as you

[bruno12mota]

@ldez any progress on this? It's been a while. I bumped into this same issue and since I'm using kubernetes I ended up creating a separate ingress controller (nginx one) for the wildcard domains.

[moqmar]

Another problem I found that I think should be taken into account when allowing for multiple challenge types: it should be possible to use multiple DNS challenges (or generally multiple challenges of the same type for different domains), and especially multiple DNS challenges on the same provider (so, the environment variables would have to be specified in the configuration file).

This is especially needed for providers like hosting.de, which requires a HOSTINGDE_ZONE_NAME environment variable, which in most cases corresponds to a single domain name. It's probably possible to work around that issue with CNAME records, but it's not exactly the most beautiful solution - another example where this would be required are multiple accounts with the same provider.

[ldez]

@moqmar take a look to #2773

[maxencehenneron]

In my case, this is needed for 1) a wildcard cert, *.mydomain.com, whose DNS server I control (only DNS challenges work for wildcard certs, right). Plus 2) certificates for my users' custom domains, some.other-domain.com, elsewhere.com, elsewhere2.com etc, whose DNS servers I do not have access to — so DNS challenge wouldn't work? only HTTP challenges works, right. That is, in this case, both DNS and HTTP challenges needed.

I'm also in the same boat, and I found a temporary hacky workaround until @ldez finishes his feature:

Start Traefik with the following config :

[acme]
email = "email@example.com"
storage = "/etc/traefik/acme/acme.json"
entryPoint = "https"
acmeLogging = true
onHostRule = true
[acme.dnsChallenge]
  provider = "route53"
  delayBeforeCheck = 0

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

and let it generate the acme.json file for the wildcard domain. Once the file gets generated, comment out the following code:

[acme.dnsChallenge]
  provider = "route53"
  delayBeforeCheck = 0

and restart traefik. You will get the expected behaviour, but you might have issues with renewal 3 months later (can anyone confirm?) I suppose reverting to dnsChallenge every 3 month to renew the wildcard will work. Until the feature is released, I'll just just create an iPhone notification to renew the certificate every 88 days.

[ldez]

Close in favor of #4872 - Feel free to subscribe there for updates.