crypto/tls: GetClientCertificate is not preserved by Clone

[bhiggins]

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?

1.8 (this feature was introduced in 1.8)

What operating system and processor architecture are you using (go env)?

Linux (but it doesn't matter here)

What did you do?

Used tls.Dial (or tls.DialWithDialer) without setting ServerName in Config.

What did you expect to see?

A successful connection.

What did you see instead?

"remote error: tls: bad certificate" on the client and "tls: client didn't provide a certificate" on the server.

Workaround: set ServerName so that the config isn't cloned by tls.DialWithDialer.

(BTW, maybe it would be useful in unit tests to clone configs immediately before use.)

[bradfitz]

I thought I replied to this already, but I can't find it.

What makes you think this is not being cloned? The source code and this snippet sure suggests it is:

https://play.golang.org/p/Hk6eSLa4-l

Please share some minimal code you expect to work and what it does instead. Thanks.

[bhiggins]

@bradfitz, this is regarding GetClientCertificate (added in 1.8), not GetCertificate. I took a look at Clone and GetClientCertificate was not included.

Here is an example: https://play.golang.org/p/6zbpqxY6U1

I expect it to print "Works for me" but instead line 16 panics.

[bradfitz]

Hey @agl, if you'd have accepted an earlier version of my CL (patchset 3: https://go-review.googlesource.com/c/28075/3/src/crypto/tls/tls_test.go#471) with the robust regexp-based test, we wouldn't be here. :-)

But our existing test for Config.Clone lets things slip through the cracks, like this.

[gopherbot]

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

[FiloSottile]

Ah, I had this in my TODO because it was encountered recently at Cloudflare.

Any chances this could be considered for 1.8.1?

[jefferai]

And in that vein any idea when such a release might be? This sadly makes this (otherwise exciting) new feature fairly unusable in real code, especially for any code wanting to use the http2 package.

[mikedanese]

The kubernetes team was also greatly anticipating this feature in 1.8. As far as patches go, this one seems fairly safe. Any chance we could get it into 1.8.1? Otherwise we will likely have to build kubernetes with a patched go toolchain.

cc @cjcullen @jcbsmpsn

[bradfitz]

Would've been nice if Kubernetes had helped test Go 1.8 sooner back when I was asking (kubernetes/kubernetes#38228) and maybe found this bug before Go 1.8. Oh, well. Better late than never, I guess.

[bradfitz]

Reopening for Go 1.8.1.