[davewritescode]

This isn’t true at all and I’ve complained about it before but the go maintainers introduced a big breaking change in the x.509 standard library that caused a lot of scrambling.

https://github.com/golang/go/issues/39568

As far as I know every other language standard library still allows CN to be used to validate the hostname when the SAN field doesn’t exist.

[ericbarrett]

I disagree that TLS is a good example of a breaking change, since this is a specific library dealing with a developing and dynamic area of security. If this weren’t changed, it would compromise PKI cert integrity by allowing obsolete fields. Also you can get the old behavior back with a flag. The fact that other languages are lagging here reflects badly on them.

As discussed in the link, CommonName has been deprecated in x.509 serverAuth certificates for decades, and all major browsers dropped support for the field (even as a fallback) years ago.

[davewritescode]

You can’t get the old behavior back with a flag as of 1.17 and if you could I wouldn’t be complaining.

Also, the reason CN is deprecated has nothing to do with security but the maximum length of the field in the spec. Chrome ignores it but every cert I’ve seen recently still includes it for legacy compatibility.

It’s not a huge dealbreaker but it forced me to go make 3rd parties regenerate their certs before I could upgrade my version of go.