Note: I don't think this is a bug in Go crypto/tls, but its strict handling may cause interoperability issues.

Go version

go1.21.1, probably earlier too.

What did you do?

Start a crypto/tls-based webserver. Browse to it with a popular browser (firefox, chromium, safari) with a URL that has a trailing dot, e.g. https://www.xmox.nl./

What did you expect to see?

You may expect to see a website.

What did you see instead?

A TLS handshake error.

It looks like the popular browsers do not remove the trailing dot from the SNI name used in their TLS handshake. Crypto/tls correctly (according to the TLS RFC) refuses the connection. See https://github.com/golang/go/blob/go1.21.1/src/crypto/tls/handshake_messages.go#L447

For firefox, see: https://bugzilla.mozilla.org/show_bug.cgi?id=1008120
For chromium, see: https://bugs.chromium.org/p/chromium/issues/detail?id=593952

Curl does strip the trailing dot from SNI, so curl https://www.xmox.nl./ can get to the HTTP response (though in this case the domain with trailing dot is not configured).

For most websites I tried to access with an absolute domain name (that are likely not running a crypto/tls-based HTTPS-webserver) the connections do work, e.g.: https://www.google.com./ https://www.amazon.com./

Some more examples that don't work: https://caddyserver.com./, https://nu.nl./ (appears to use skipper).

From memory (about 6 months ago), I first ran into this when using a crypto/tls-based webserver to offer email account autodiscovery to Microsoft Outlook. The incoming autodiscovery HTTPS connections had a trailing dot in the SNI name, so autodiscovery failed. Outlook seems to have made up the absolute URL itself.

To summarize: I don't think this is a bug in crypto/tls, and I like its correct/strict behaviour, but that may cause interoperability issues. I'm mostly filing this bug for future reference and possible discussion and after a hint from @FiloSottile.