I have configured traefik for TCP and HTTP routes. Both routes are configured to apply TLS using Let's Encrypt. openssl s_client -connect ... -servername shows me valid certificates on both routes and it displays the Let's Encrypt certificate. So far, so good.
But here comes the strange thing: While the traefik dashboard CORRECTLY shows distinct domain names in the TLS section of both routes, according to openssl's output the TCP route is NOT using the certificate for the TCP route's domain, but instead BOTH routes (TCP and HTTP) apparently use the same certificate -- to one defined at the HTTP route. This is pretty weird!
How can it happen that the dashboard shows the correct TLS domain, but then the TCP route actually is using a DIFFERENT certificate?
LetsEncrypt validation only works with ports 80 (HttpChallenge) and 443 (TlsChallenge). If you need a different port or wildcard cert, you need to use DnsChallenge.
In you case I would try to add the additional domain via .rule=Host() || Host() to a service on the standard ports to get the domain validated.
How does this answer my original question? The above configuration performs Let's Encrypt valildation on port 80 quite well and produces the wanted certificates.
As nobody found a failure in our configuration, it would be nice if a member of the Traefik core team could confirm that this is a actually a bug in Traefik OR clearly point out what our fault was.
That won't work. None of the services shall be reachable from multiple domains. SANS shall only allow the certificate to be usable by multiple domains.
Don't get me wrong, I am not searching a workaround ("trick"), what I am searching for is a solution.
This is a community forum. If you want a professional solution, you might think about getting official (paid) support from Traefik and open a ticket with them.
Can you explain what you use the SANS for? I am here to learn, too. To me it seems like you want to „trick“ Traefik to generate certs for different purposes.
For the LetsEncrypt validation the SANS domains need to be available in external DNS and point to Traefik. With DNSChallenge you can get wildcard certificates.
A community forum is not by definition unprofessional. Check my original posting, last sentence. Do not want more than an answer on the original question: Did I find a bug in Traefik OR is there a failure in my config. Not more. Not less. In particular I did not ask for any workarounds or tricks.
SANS is needed to get an additional DNS name registered in your let's encrypt certificate. It has nothing to do with Traefik at all. We are using DNS CNAMES to manage our domain namespace, which must reflect in SANS entries or otherwise the browser would reject the certificate when connecting using such a CNAME instead of the canonical A name. That is not a "trick" but simple DNS / TLS base knowledge.
I do not see what your last sentence, which is quite obvious, has to do with my original question. I already explained that the certificate generation already works quite well but my problem solely is that Traefik selects the wrong certificate out of the set of certificates it received from let's encrypt. Not more, not less. I explicitly did not ask "how to create a wildcard" certificate, and no, a wildcard certificate is not an answer on my original question, it is just a very unsecure patch on the bug I detected in Traefik. And I already explained that I am NOT searching for any workaround, I just want to get a confirmation by the Traefik team that this IS a bug in Traefik.
I do not want feedback. I just want to get the question answered if this is a bug or not, as the Traefik team (as every open source team) is happy to get this sorted out before uselessly opening a Github issue. Reddit is the wrong place for this, as the Traefik team explicitly asks for such discussions to go on in this forum.
Hi @mkarg , Indeed I don't see anything wrong with your configuration, and at the same time this is not a bug at all. See Traefik does not bind certificates to routers directly, instead it just uses the information on the router configuration (tls section) to request certificates, but once the certificate is stored it will be used for host matching during the TLS handshake.
That means it most certainly got a certificate with a Main and SANS as specified on your config here:
Since this is a match and valid for both matrix.ijug.eu and chat.ijug.eu both routers can end up serving the same certificate, no matter if you specify only one domain in its router configuration because there will be a certificate in the store that is valid for both.
Unfortunately this behavior is not thoroughly documented and there is definitely room for improvement here.