Mixture of self-signed wildcard and LetsEncrypt certificates


in our setup we have multiple domains resolving to the same IP with the same Traefik instance running responding there:

  • *.awesome-app.com is a public DNS entry resolving to public IP
  • *.awesome-app-1.my-company.internal is an company-internally DNS entry resolving to public IP
  • *.awesome-app-2.my-company.internal is an company-internally DNS entry resolving to public IP

Maybe we'll change the IP of the internal ones to an internal IP in the future, but this does not really make a difference here, as we'd keep them on a single Traefik instance.

For the external domain we have setup certificates from LetsEncrypt (using CertManager). This is the domain the users use to get to our awesome app.

The internal domains are used for management stuff, like management endpoints of the user applications, or internal applications like monitoring and logging dashboards. As the domain does not resolve from the internet we cannot use LetsEncrypt here. Also we don't need to, as we have an internal CA available to use on all our companies machines. To not have the necessity to generate a new certificate for each internal application, we generated wildcard certificates.

Our Traefik setup now does the following:

We have a Certificate resource with the respective secret generated by CertManager/LetsEncrypt in the public applications namespaces and use that secret in the Ingresses.

For the internal wildcard certificates we generated the certificates ourselves. But instead of adding the secrets to each ingress individually, we mounted them to the Traefik container and added them to the default TLS Store through the dynamic configuration:

    - certFile: "/ssl/internal/wildcard.awesome-app-1.company.internal.crt"
      keyFile: "/ssl/internal/wildcard.awesome-app-1.company.internal.key"
    - certFile: "/ssl/internal/wildcard.awesome-app-2.company.internal.crt"
      keyFile: "/ssl/internal/wildcard.awesome-app-2.company.internal.key"

So much for the setup. Now my questions:

This works pretty well! The external Ingresses are working with the LetsEncrypt certificate. Both internal ones show their respective certificate in the browser.

But I don't really understand how good, if it is a good idea to do it this way or if there is potential for errors here.

Does Traefik know which of the two certificates is for which domain and only uses the correct certificate when responding to requests? Or is this more like in SSH where just all available public keys are used? If so, might this create a problem when we add additional certificates? How about the external ingresses? Are they only using the configured secrets? Or do they then also use all three certificates and the browser "on the other side" has to decide which the correct one is?

Would it make more sense to let the Certificate resource (or even CertManeger) also handle the internal wildcard certificates? Then how do I distribute the certificates in multiple namespaces?

Would be great if someone could help me out here. Also links to the parts of the documentation would be greatly appreciated! I could not find any. In case there is none and we can clear this up here, I will gladly help providing this documentation :slight_smile:

Thanks in advance!


Hi @razr

Traefik will create a map of the valid certificates it knows about, certificate files and acme, any tls enabled router that is discovered will check for a matching certificate and use it. In the case one is not found the certificate provider will be used to create a new one or serve the default certificate.

Hey @cakiwi ,

thanks for the explanation!

So I'd guess the map will be something like domain --> certificate. And it will use that map on a tls enabled router if no specific secret is specified, right?

So from my understanding this also means, that setting in up the way I did here is totally ok, right?

As I said, it works like a charm :slight_smile:

I'm currently trying to create a matching Certificate resource for my wildcard certificates, so I can easily see expiring certificates in one place (the overview of all Certificate resources in the cluster). But that's only something for a bit more convenience :slight_smile:

Thanks so far!

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.