Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
crypto/x509: a server with a self-signed certificate doesn't validate if that cert is in Roots #16763
@agl Thanks for making this change. It definitely makes a TLS client written in Go more consistent with other languages when setting explicit trust anchors and talking to TLS servers with self-signed certificates that you do not control.
Not sure if it's what you observed, but I had previously encountered verification errors with TLS servers whose self-signed certificates would fail x509.CheckSignatureFrom (in call to opts.Roots.findVerifiedParents from inside buildChains). For example, if a TLS server's self-signed cert was not marked as a CA with basicContraints = true or KeyUsage was present but missing keyCertSign. After your change, such CA / KeyUsage enforcement will no longer be checked in this scenario.
Previously, if you controlled the TLS server, you could modify your TLS server's self-signed cert to conform to the stricter requirements imposed by x509.CheckSignatureFrom. If you did not control the TLS server, your only option for a Go client would be to use InsecureSkipVerify and get zero verification or to use something like DialTLS and write your own verification logic.
I always want to do as much TLS verification as possible, so this change now makes that easier to achieve. Hopefully, more folks will stop using InsecureSkipVerify reflexively and just start setting the root explicitly when talking to TLS servers with self-signed certs.
I did not report this previously because I assumed Go was deliberately trying to be more strict even though RFC 5280 is a bit ambiguous for this scenario.