Go version
go version go1.23.0 darwin/arm64
Output of go env
in your module/workspace:
GO111MODULE='on'
GOARCH='arm64'
GOBIN=''
GOCACHE='/Users/influx/Library/Caches/go-build'
GOENV='/Users/influx/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='arm64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMODCACHE='/Users/influx/.gvm/pkgsets/go1.23/global/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='darwin'
GOPATH='/Users/influx/.gvm/pkgsets/go1.23/global'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/Users/influx/.gvm/pkgsets/go1.22/global/pkg/mod/golang.org/toolchain@v0.0.1-go1.23.0.darwin-arm64'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/Users/influx/.gvm/pkgsets/go1.22/global/pkg/mod/golang.org/toolchain@v0.0.1-go1.23.0.darwin-arm64/pkg/tool/darwin_arm64'
GOVCS=''
GOVERSION='go1.23.0'
GODEBUG=''
GOTELEMETRY='local'
GOTELEMETRYDIR='/Users/influx/Library/Application Support/go/telemetry'
GCCGO='gccgo'
GOARM64='v8.0'
AR='ar'
CC='clang'
CXX='clang++'
CGO_ENABLED='1'
GOMOD='/Users/influx/Documents/GitHub/telegraf/go.mod'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/g6/d6l6tpq15kjg4j12mp_bz80m0000gn/T/go-build74057246=/tmp/go-build -gno-record-gcc-switches -fno-common'
What did you do?
After updating https://github.com/influxdata/telegraf to Go 1.23, we received issues related to a change in the crypto/x509 library related to negative serial numbers, such as https://github.com/influxdata/telegraf/issues/16309. After investigating we learned that a change occurred in the library which made negative serial numbers no longer accepted by default.
What did you see happen?
This caused failures for some of our users. We found the go debug x509negativeserial
option, which we have enabled in telegraf for now as a workaround. However due to the nature of go debug options, we are not confident in this being a long-term solution.
What did you expect to see?
In RFC 5280, it states:
Note: Non-conforming CAs may issue certificates with serial numbers that are negative or zero. Certificate users SHOULD be prepared to gracefully handle such certificates.
Go should provide graceful handling of this situation without the need for a godebug option. One option would be to revert the behavior. Another option could be to flip the godebug option, allowing negative serial by default and treating it like a feature flag. Another option would be to keep this new behavior but add a new more permanent option than godebug to opt-in to legacy behavior
Comment From: gabyhelp
Related Issues
- crypto/x509: unable to parse certificate with a negative serial number #8265 (closed)
- crypto/x509: CreateCertificate creates invalid serial number field #33310 (closed)
- crypto/x509: malformed signature algorithm identifier error while version and serialNumber swapped #70269
Related Code Changes
- crypto/x509: don't create certs with negative serials
- crypto/x509: permit serial numbers to be negative.
- crypto/x509: reject negative serial numbers
- crypto/x509: don't allow too long serials
Related Discussions
(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)
Comment From: seankhliao
Given Go's focus on Web PKI, the godebug will be the only option.
Comment From: srebhan
@seankhliao so what you want to say is that excluding everyone facing this issue, which seems to be common for MS issued certificates, and ignoring the recommendation from the RFC is okay for Golang? I was of the impression that Go is a general language and not only for web-development!?!? This breakage was introduced in v1.23, how long will the godebug workaround last?
Comment From: raphaelfff
Negative serial have no security implications, go is well-known for its backward compatibility, and this is a hard breakage on everyone who unknowingly relied on that behaviour. Specs clearly says: Certificate users SHOULD be prepared to
gracefully handle such certificates.
the go std lib qualifies as a "certificate user", and should provide at minimum a viable long term way to bypass that validation, GODEBUG doesnt provide that long-term viability.