Traefik should not serve TRAEFIK DEFAULT CERT when there is a matching custom cert #5849
Comments
More detailsThis is HAPROXY Controller serving the exact same ingresses: As you can see, there is no default cert being served in addition to the matching server_name host(only one cert) which is the correct behavior. |
|
Can confirm the same is happening when using traefik from docker-compose directly with ACME. Its getting the letsencrypt certificate fine and serving it but traefik keeps serving the default cert for requests not specifying a hostname. I would expect traefik to simply fail hard if the hostname is not known when using SNI not serve a default cert. I would also not expect traefik to serve its default certificate while loading the ACME certificates from a store. |
dduportal
added
area/tls
kind/bug/possible
|
I think there's a chance Traefik might be returning the certificates in the wrong order randomly, so in some requests it sometimes returns the matching SNI certificate first and then the default while some other times it returns the default certificate first and then the matching certificate SNI second. In any case, it should not serve the default certificate if there is a matching certificate. |
|
Hi @bithavoc , could you provide a reproduction case (let's say with a script using |
|
@bithavoc, By default, if a non-SNI request is sent to Traefik, and it cannot find a matching certificate (with an IP SAN), it will return the default certificate, which is usually self signed. If you are required to pass this sort of SSL test, you may need to either:
Please let us know if that resolves your issue. |
|
@dtomcej I shouldn't need Strict SNI checking since there is a matching certificate for the domain, should I? |
|
beware that that URL I first posted is already using Haproxy, not Traefik. I can restore the traefik environment so you can try again though, lmk what you want to do. |
|
As I mentioned earlier: SSL Labs tests SNI and Non-SNI connection attempts to your server. It will attempt to connect via the domain name AND the IP address, which is why you get the non-match due to the IP address connections. If your certificate is for |
|
I switched to ha proxy briefly, will be trying the strict tls option soon. Don't close yet. |
|
I ran into this in my traefik setup as well. Specifying The comment above about this being sporadic got me looking through the code and I see a couple It would be nice to have an option to disable the DEFAULT CERTIFICATE and error/warn in cases where no certificate is usable for a route. There's no reason (in production) to serve the default. I didn't try strict SNI checking, but my problem seems solved without it. I've got a LB and some requests without hostnames in my setup that I didn't want to change to fix this issue. |
|
Hi! I'm Træfiker 🤖 the bot in charge of tidying up the issues. I have to close this one because of its lack of activity 😞 Feel free to re-open it or join our Community Forum. |
Do you want to request a feature or report a bug?
Bug
What did you do?
I have a deployment for my workload served by an ingress with a custom Let's Encrypt certificate I added manually to the kubernetes cluster. The website works fine in Chrome most of the time, however, some users reports that Firefox sometimes does not work.
What did you expect to see?
Traefik serves ONLY ONE certificate matching the host of the ingress path all the time.
What did you see instead?
Traefik serves TWO certificates, one matching my host of the ingress path and also a non SNI certificate with Subject TRAEFIK DEFAULT CERT.
This one was hard to catch because I guess most of the time browsers such as Firefox, Safari and Chrome latest version are able to figure out what certificate to pick from the ones Traefik serves via TLS and ignore the unmatching non SNI default cert, however, the same browsers some time stutter and pick the wrong one which is why some users sometimes see a page flagged as non-secure.
Output of
traefik version: (What version of Traefik are you using?)What is your environment & configuration (arguments, toml, provider, platform, ...)?
If applicable, please paste the log output in DEBUG level (
--log.level=DEBUGswitch)Here's a report from SSL Checker reporting that secondary certificate, check Certificate #2 the one that says non-SNI:
SSL Server Test: sample-custom-dc2.widemeshstaging.net (Powered by Qualys SSL Labs).pdf
For comparison, here's a SSL checker report but using HAPROXY Controller serving the exact same ingresses:
HAPROXY SSL Server Test: sample-custom-dc2.widemeshstaging.net (Powered by Qualys SSL Labs).pdf
As you can see, there is no default cert being served.
The text was updated successfully, but these errors were encountered: