proposal: crypto/x509: remove x509sha1 GODEBUG in Go 1.24

[rsc]

Go 1.18 disabled the use of SHA1 in most X.509 certificates by default but added a GODEBUG for re-enabling them, to accommodate private CAs that might not have updated yet. https://go.dev/crypto/x509#InsecureAlgorithmError

Per https://go.dev/doc/godebug#go-118 we can remove that GODEBUG in Go 1.22 or later. The GKE team, which is the only team that reached out about needing to keep SHA1, has gathered metrics about their own dependence (via customers) on this setting, and they believe that they won't need it anymore after Go 1.23.

Unless there are other users who need us to keep the setting around longer, I propose that we retire the x509sha1 GODEBUG in Go 1.24. We would pre-announce this in the release notes for both Go 1.22 and Go 1.23.

[liggitt]

looks like this isn't mentioned in the tip release notes for 1.22 at https://tip.golang.org/doc/go1.22 ... should it be?

[SnowmanCharles]

Hi, just wondering was this proposal finally executed? Are we still supporting SHA1 in in Go 1.24?

[gbunt]

We've got a use case of verifying chains of certificates we don't have direct control over, and we still see root and intermediate certificates out there provided by CA's (Comodo, GoDaddy), signed with SHA1. We do currently depend on setting GODEBUG to use the Verify method.

[AGWA]

@gbunt this proposal doesn't impact SHA-1-signed root certificates, since root certificate signatures are not validated.

Publicly-trusted CAs like Sectigo (formerly Comodo) and GoDaddy haven't been using SHA-1 intermediates for TLS certificates since ~2015. Is your use case for non-TLS certificates?

[gopherbot]

Change https://go.dev/cl/586718 mentions this issue: doc: add note about x509sha1 removal in 1.24

[gbunt]

@AGWA I guess there are still SHA-1 intermediate's out there, for example see https://ssl-tools.net/subjects/53b54f6e16a815187849c176725823579954799e

That's just one example, we've seen more. I presume we can point our end-users to using a chain that doesn't include SHA-1, though it would be inconvenient if that'd require requesting a renewal (i'd think it would)

[AGWA]

@gbunt: that's a root certificate, not an intermediate, and doesn't require GODEBUG=x509sha1 to use.

[gbunt]

@AGWA thanks for pointing that out, i think we've been misguided by end-users mixing up root and intermediates, even in filenames. That explains a few things! Withdrawing now...