RequireAndVerifyClientCert has no efact when secret is missing

I noticed that "RequireAndVerifyClientCert" has no effect on "clientAuthType:" if the secret in "secretNames:" is missing. This means that if the secret is missing or misconfigured, the endpoint is no longer protected and accessible to the whole world. I consider this fallback behavior to be highly risky. Does anyone know how I can prevent that a missing secret leads to a security disaster?

Hintergrund: Ich verwende den traefik in k3s:

Hello @OlafRadicke,

Thanks for your interest in Traefik!

Traefik works with a default TLS option that is used in case no specific configuration is made.
The common advice is then to make the default TLS option the most secured one, and to opt-out on routers that need another configuration.

Without the exact configuration, I'm only making assumptions, though, it seems that you redefined the default TLS option with a CRD, as below:

apiVersion: traefik.containo.us/v1alpha1
kind: TLSOption
metadata:
  name: default
  namespace: default

spec:
  clientAuth:
    # the CA certificate is extracted from key `tls.ca` or `ca.crt` of the given secrets.
    secretNames:
      - secretCA
    clientAuthType: RequireAndVerifyClientCert

Can you confirm that it is indeed your situation?
Did you redefine the TLS option on the routers?
Can you share your configuration?

Hi @rtribotte,

thanks for the suggestion. This only shifts the problem. Because the problem in the default remains. If in the default "clientAuthType: RequireAndVerifyClientCert" is defined and the certificate has a misconfiguration (missing), exactly the same happens (for me): It lets all connections through without client certificate verification.

Here is my (helm) code: own_dog_food/helm/chart_src/tls_routing/templates at develop · OlafRadicke/own_dog_food · GitHub