mTLS on wildcard also enables mTLS on specific subdomain

[TheStaticTurtle]

Issue Details

Hi,

I'm trying to set up mTLS on *.example.com while keeping public.example.com without mTLS.

My config looks like this:

(wildcard_proxy) {
	tls {
		on_demand
		issuer internal
		
		{blocks.tls}
	}
	route {
		reverse_proxy {
			to {args.0}
		}
	}
}

public.example.com {
	import wildcard_proxy https://10.10.15.50 {
		tls {
		}
	}
}

*.example.com {
	import wildcard_proxy https://10.10.15.50 {
		tls {
			client_auth {
				mode require_and_verify
				trust_pool file {
					pem_file /etc/caddy/ca/root_ca_infra.crt
				}
			}
		}
	}
}

As expected, accessing private.example.com does request the client certificate; however, so does public.example.com.
Looking at the adapted json it's clear why, there's nothing about the public domain so it matches to the wildcard:

"tls_connection_policies": [
	{
        "match": {
            "sni": [
                "*.example.com"
            ]
        },
        "client_authentication": {
            "ca": {
                "pem_files": [
                    "/etc/caddy/ca/root_ca_infra.crt"
                ],
                "provider": "file"
            },
            "mode": "require_and_verify"
        }
    },
    {}
]

The current "fix" I found is to also add mTLS on public.example.com but with mode request.
This add a new policy before the wildcard which I guess matches first and doesn't block the request:

"tls_connection_policies": [
	{
        "match": {
            "sni": [
                "public.example.com"
            ]
        },
        "client_authentication": {
            "ca": {
                "pem_files": [
                    "/etc/caddy/ca/root_ca_infra.crt"
                ],
                "provider": "file"
            },
            "mode": "request"
        }
    },
	{
        "match": {
            "sni": [
                "*.example.com"
            ]
        },
        "client_authentication": {
            "ca": {
                "pem_files": [
                    "/etc/caddy/ca/root_ca_infra.crt"
                ],
                "provider": "file"
            },
            "mode": "require_and_verify"
        }
    },
    {}
]

Is this a bug? Intended behavior? Or am I missing something?

Thanks,

Assistance Disclosure

AI not used

If AI was used, describe the extent to which it was used.

No response

[mholt]

Ohh, interesting. Yeah, so I guess in the case of a wildcard, we need to "clear/reset" TLS config for explicitly-configured subdomains.

[VatsalGoel3]

Hi, I’d like to investigate this.

Based on the discussion, it sounds like the Caddyfile adapter may need to emit an explicit TLS connection policy for exact hostnames so they can clear/reset wildcard TLS settings, especially client_auth, instead of inheriting the wildcard policy.

I can start by adding a Caddyfile adapter test that reproduces this case:

• *.example.com has client_auth with require_and_verify
• public.example.com is explicitly configured without mTLS
• the generated JSON should ensure public.example.com does not match the wildcard mTLS policy

If that test confirms the current behavior, I’ll work on the smallest adapter change to make exact host TLS config override/reset the wildcard policy. Please let me know if that approach sounds right.

[steadytao]

Hi, I’d like to investigate this.
......

That approach sounds right to me. A failing Caddyfile adapter test first would be ideal because the important contract is that an explicitly configured hostname like public.example.com should not accidentally inherit wildcard client_auth from *.example.com. I would keep the first PR focused on the reproduction/test and the smallest adapter change needed to make the exact hostname clear/reset the wildcard TLS policy.

@VatsalGoel3, feel free to look into it if you want to take this one.

[VatsalGoel3]

I opened a PR for this: #7867

It keeps the first change focused on the adapter fixture plus the smallest adapter-side reset policy change, as discussed.

AI/LLM assistance was used via OpenAI Codex; I reviewed and verified the code and tests.