You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We use Rancher 1.6 (cattle) to host our services, and we use Rancher auto-discovery option in Traefik: the domain of each service is then decided by a label on the service itself.
We're in the common scenario where we have lots of services exposed on ourdomain.org and some of them exposed (also) on a customer subdomain, like ourservice.customerdomain.com.
This typically leads to Let's Encrypt rate limits for ourdomain.org, that should be solveable with a wildcard certificate.
Trying to work around this waiting for #3378 resolution, we managed to have two different Traefik services, one (let's call it traefik-wildcard) which just generates and renews the wildcard certificate with DNS valdiation, and the other one that actually serves (traefik-real). The two containers share the acme directory.
I started traefik-wildcard and it actually generated the wildcard certificate for *.ourdomain.org, creating the acme.json file I could also see from traefik-real container. Then, I started traefik-real and here happened what I didn't expect: Traefik discovered all of the services and generated all the specific certificates (mailhog.ourdomain.org, nginx.ourdomain.org, ...), ignoring the fact that a good certificate for them was already existing.
I'm wondering if it would be better not to generate a specific certificate in that case.
The text was updated successfully, but these errors were encountered:
I have the exact same configuration and in my case, Traefik uses the correct wildcard certificate if I do not add multiple hosts to the frontend configuration.
ie:
Host:ourservice.ourcustomer.com,ourcustomer.ourservice.com
would generate new certificate containing the two domains.
But if I only use one host like this one:
Host:ourcustomer.ourservice.com
it will correctly pick the wildcard certificate *.ourservice.com. I'm using traefik 1.7.
It would be great to have a way to only generate certificates for which we do not have a wildcard setup and dynamically selecting the good certificate depending on the request host name
Do you want to request a feature or report a bug?
Feature
What did you expect to see?
We use Rancher 1.6 (cattle) to host our services, and we use Rancher auto-discovery option in Traefik: the domain of each service is then decided by a label on the service itself.
We're in the common scenario where we have lots of services exposed on ourdomain.org and some of them exposed (also) on a customer subdomain, like ourservice.customerdomain.com.
This typically leads to Let's Encrypt rate limits for ourdomain.org, that should be solveable with a wildcard certificate.
Trying to work around this waiting for #3378 resolution, we managed to have two different Traefik services, one (let's call it traefik-wildcard) which just generates and renews the wildcard certificate with DNS valdiation, and the other one that actually serves (traefik-real). The two containers share the acme directory.
I started traefik-wildcard and it actually generated the wildcard certificate for *.ourdomain.org, creating the acme.json file I could also see from traefik-real container. Then, I started traefik-real and here happened what I didn't expect: Traefik discovered all of the services and generated all the specific certificates (mailhog.ourdomain.org, nginx.ourdomain.org, ...), ignoring the fact that a good certificate for them was already existing.
I'm wondering if it would be better not to generate a specific certificate in that case.
The text was updated successfully, but these errors were encountered: