Default Certificate Overridden by Team-Specific Secret with Same Cert but Incomplete Chain in IngressRoute

[rgarcia89]

Welcome!

• [X] Yes, I've searched similar issues on GitHub and didn't find any.
• [X] Yes, I've searched similar issues on the Traefik community forum and didn't find any.

What did you do?

We have defined a default TLS certificate in our TLSStore, which includes a full certificate chain (certificate, intermediate, and root CA) for all IngressRoutes that do not explicitly define their own certificate. This default setup works fine for us, as it includes a wildcard certificate that we use.

However, in my case someone has deploy the same wildcard certificate into a secret in the cluster, but without including the intermediate and root CA. He referenced this incomplete secret in an IngressRoute he defined.

After this incomplete secret was deployed and referenced, it became the certificate that was loaded for all IngressRoutes that were previously using the full chain provided by the default certificate in the TLSStore. Consequently, instead of providing the full certificate chain, only the certificate without the intermediate and root CA was provided, as defined by the team member.

This behavior was unexpected. It seems that loading the same certificate, even without explicitly referencing it in other IngressRoutes, is overriding the original default certificate we defined in the TLSStore.

Steps to reproduce:

1. Define a default TLS certificate with a full chain (certificate, intermediate, and root CA) in the TLSStore.
2. Deploy an IngressRoute without specifying a TLS secret and verify it uses the default certificate with the full chain.
3. Deploy the same wildcard certificate in a secret, but without the intermediate and root CA.
4. Reference this incomplete secret in a new IngressRoute using the tls.secretName field.
5. Observe that all IngressRoutes, including those that should use the default certificate, now use the incomplete certificate chain.

What did you see instead?

Expected Behavior: IngressRoutes that do not specify their own certificate should continue to use the default certificate defined in the TLSStore, even if another IngressRoute specifies the same certificate without the intermediate and root CA.

Actual Behavior: Referencing the same certificate without the intermediate and root CA in one IngressRoute causes it to be loaded for all IngressRoutes, overriding the default certificate defined in the TLSStore.

What version of Traefik are you using?

3.0.4

What is your environment & configuration?

...

If applicable, please paste the log output in DEBUG level

No response

[nmengin]

Hello @rgarcia89,

Thank you for reaching out.

From what I understand, you should find an answer to your questions in the FAQ section of the documentation.

I close this issue as a question, we'll re-open it later if necessary.

[rgarcia89]

Hi @nmengin thanks for the hint. I wasn't expecting that.

[nmengin]

Hello @rgarcia89,

I wasn't expecting that.

Could you explain your expectations, please?

[rgarcia89]

To be honest, I would have expected that certificate usage is coordinated differently. With the current behavior, the failure of one wrongly loaded certificate for the same domain can cause a lot of trouble. It is also quite hard to troubleshoot as you do not see which certificate is being used if a situation like mine occurs. In my opinion, if a certificate is not defined, the default one should always be loaded. Similarly, if a certificate is defined using secretName, it should always take precedence over every other certificate. This however would pretty sure cause trouble with some other use cases...

[nmengin]

Hey @rgarcia89,

Thank you for your feedback.

The behavior that currently exists in Traefik comes from the lifecycle of a TLS request in Traefik. The TLS handshake happens before the routing, for this reason, Traefik cannot rely on the routers’ configuration to serve a certificate attached to the Ingress.

That’s why, even if certificates in Kubernetes can be attached to Ingresses, they are shared in the TLS store.

However, you are not the first person to give this feedback, and be sure that improving the TLS certificates management is a task we have in mind. It’s a hard task requiring much thought, work, and probably a new major version.

[rgarcia89]

Understood. That's of course a very misleading approach as due to that one cannot be sure that the cert he has defined in his ingressroute is really the cert that is in use according to his definition. I would appreciate a change of that in the future.