Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support multiple ACME challenge types at the same time #3378

Closed
EugenMayer opened this issue May 24, 2018 · 16 comments
Closed

Support multiple ACME challenge types at the same time #3378

EugenMayer opened this issue May 24, 2018 · 16 comments

Comments

@EugenMayer
Copy link
Contributor

@EugenMayer EugenMayer commented May 24, 2018

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

This comment has been minimized.

Copy link

@verglor verglor commented Jun 2, 2018

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

@xiaods

This comment was marked as off-topic.

Copy link

@xiaods xiaods commented Jul 1, 2018

cool feature. anyone can do me a favor.

@zeeshanjamal16

This comment has been minimized.

Copy link

@zeeshanjamal16 zeeshanjamal16 commented Nov 5, 2018

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

@ldez ldez self-assigned this Nov 12, 2018
@nocgp

This comment has been minimized.

Copy link

@nocgp nocgp commented Nov 28, 2018

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

could be acme.domain.httpChallenge option

@kajmagnus

This comment has been minimized.

Copy link

@kajmagnus kajmagnus commented Dec 22, 2018

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

This comment has been minimized.

Copy link
Member

@ldez ldez commented Dec 22, 2018

I'm working on that, so stay tuned 😉

@kj3slyn

This comment has been minimized.

Copy link

@kj3slyn kj3slyn commented Dec 24, 2018

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

@benz0li

This comment was marked as off-topic.

Copy link

@benz0li benz0li commented Jan 27, 2019

Would be great to have this feature.

@adriaanh

This comment was marked as off-topic.

Copy link

@adriaanh adriaanh commented Feb 26, 2019

Would be great to have this feature.

Love to have this feature as well!

@andrealmar

This comment was marked as off-topic.

Copy link

@andrealmar andrealmar commented Feb 27, 2019

eagerly wanting this feature =)

@Jeskz0rd

This comment was marked as off-topic.

Copy link

@Jeskz0rd Jeskz0rd commented Feb 27, 2019

This feature would be great! Can't wait for that! ;)

@bruno12mota

This comment has been minimized.

Copy link

@bruno12mota bruno12mota commented Mar 7, 2019

@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

This comment has been minimized.

Copy link

@moqmar moqmar commented Mar 10, 2019

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

This comment has been minimized.

Copy link
Member

@ldez ldez commented Mar 10, 2019

@moqmar take a look to #2773

@maxencehenneron

This comment has been minimized.

Copy link

@maxencehenneron maxencehenneron commented Mar 15, 2019

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.

moqmar added a commit to moqmar/traefik that referenced this issue Apr 26, 2019
Fix containous#2773 and containous#3378, and make environment variables for the providers configurable from the configuration provider

Example:

[acme.dnsChallenge]
  provider = "route53"
  environment = ["AWS_ACCESS_KEY_ID=abcd", "AWS_SECRET_ACCESS_KEY=efgh"]

[[acme.domains]]
  main = "*.example.org"
  sans = ["example.org"]
  challenge = "dns" # dns/http/tls
  dnsProvider = "cloudflare"
  dnsEnvironment = ["CF_API_EMAIL=mail@example.org", "CT_API_KEY=1234"]
moqmar added a commit to moqmar/traefik that referenced this issue Apr 26, 2019
Fix containous#2773 and containous#3378, and make environment variables for the providers configurable from the configuration provider

Example:

[acme.dnsChallenge]
  provider = "route53"
  environment = ["AWS_ACCESS_KEY_ID=abcd", "AWS_SECRET_ACCESS_KEY=efgh"]

[[acme.domains]]
  main = "*.example.org"
  sans = ["example.org"]
  challenge = "dns" # dns/http/tls
  dnsProvider = "cloudflare"
  dnsEnvironment = ["CF_API_EMAIL=mail@example.org", "CT_API_KEY=1234"]
moqmar added a commit to moqmar/traefik that referenced this issue Apr 29, 2019
Fix containous#2773 and containous#3378, and make environment variables for the providers configurable from the configuration provider

Example:

[acme.dnsChallenge]
  provider = "route53"
  environment = ["AWS_ACCESS_KEY_ID=abcd", "AWS_SECRET_ACCESS_KEY=efgh"]

[[acme.domains]]
  main = "*.example.org"
  sans = ["example.org"]
  challenge = "dns" # dns/http/tls
  dnsProvider = "cloudflare"
  dnsEnvironment = ["CF_API_EMAIL=mail@example.org", "CT_API_KEY=1234"]
@ldez

This comment has been minimized.

Copy link
Member

@ldez ldez commented May 14, 2019

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

@ldez ldez closed this May 14, 2019
@containous containous locked and limited conversation to collaborators Sep 1, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
You can’t perform that action at this time.