Caddy client_auth works for punycode but not IDN hostnames

[hackysphere]

Issue Details

Version: Caddy v2.11.2 on Arch Linux, and base Caddy v2.11.3 from the download page on Arch Linux

If using an internationalized hostname instead of its punycode version, Caddy will ignore tls client_auth rules when accessing the domain and allow requests without a mTLS certificate.

Example config:

つ.localhost

tls {
	client_auth {
		mode require
	}
}

respond {time.now}

If the hostname is instead set to xn--k9j.localhost, Caddy will correctly deny requests without mTLS.
I could not find any important differences in the logs.

Assistance Disclosure

AI not used

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

No response

[steadytao]

Rough code area: modules/caddytls/matchers.go has MatchServerName.Match() comparing the configured SNI matcher directly against hello.ServerName and modules/caddytls/connpolicy.go also indexes policies by raw hello.ServerName. HTTP host matchers and automation policy subjects appear to go through IDNA normalisation but I do not see equivalent normalisation for TLS SNI matchers.

So my guess is that つ.localhost produces a connection policy matcher stored as Unicode while the ClientHello SNI is the A-label form xn--k9j.localhost; that policy does not match so Caddy falls through to a policy without client_auth. If so, the fix is probably IDNA normalisation for tls.handshake_match.sni / generated TLS connection policy matchers, plus a regression test that the Unicode and punycode forms enforce the same client_auth policy.

If I get the time I will come back to this. Legitimate bug.

[steadytao]

Working on this now.

[mholt]

Thanks @steadytao !