Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

crypto/x509: a server with a self-signed certificate doesn't validate if that cert is in Roots #16763

Closed
agl opened this issue Aug 17, 2016 · 2 comments
Assignees

Comments

@agl
Copy link
Contributor

@agl agl commented Aug 17, 2016

(Just filing this for my own records.)

@agl agl self-assigned this Aug 17, 2016
@bradfitz bradfitz changed the title A server with a self-signed certificate doesn't validate if that cert is in Roots. crypto/x509: a server with a self-signed certificate doesn't validate if that cert is in Roots Aug 17, 2016
@gopherbot
Copy link

@gopherbot gopherbot commented Aug 19, 2016

CL https://golang.org/cl/27393 mentions this issue.

@ramoas
Copy link

@ramoas ramoas commented Aug 19, 2016

@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.

@gopherbot gopherbot closed this in 8ad70a5 Aug 19, 2016
@golang golang locked and limited conversation to collaborators Aug 19, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.