Comment 1:

It appears that the same problem (always using config.Certificates[0] as the
certificate) affects the OCSP stapling functionality, but i have not verified this. I'm
working on patch with with a fix & test for this as well.

Comment 3:

Yea, we do indeed use the wrong private key. Nobody has tried using SNI support before
because not enough client support it, but we should fix it none the less.
But I'll wait until after the initial Go 1 release.

Labels changed: added priority-later, packagebug, removed priority-triage.

Owner changed to @agl.

Status changed to Accepted.

Comment 4:

in that case, would you consider removing and/or deprecating the server implementation
of SNI before 1.0? The existing API is inelegant and diverges from the pattern
implemented in OpenSSL and followed by other languages.

Comment 5:

What would you like the API to be? If the existing API worked as expected I believe that
it would cover most use cases.

Comment 6:

I would like to see a callback based API that can change the tls.Config used per client.
Something similar to this: https://gist.github.com/2161321
I believe this could be further simplified by removing tls.Config.NameToCertificate and
tls.Config.BuildNameToCertificate, and switching tls.Config.Certificates back to
tls.Config.Certificate tls.Certificate.
This would be more inline with OpenSSL's SSL_CTX_set_tlsext_servername_callback API
where the callback can return a SSL_CTX (analogous to tls.Config) or null, in which case
it uses the existing SSL_CTX.

Comment 7:

There are plenty of odd cases where a callback can be nice (enabling client auth only on
some hostnames etc), but the crypto libraries deliberately only aim to solve the 90%
case. And I think the 90% case is that you have several certificates on the same IP and
want to serve the right one.
That doesn't preclude adding the callback in the future, but it would need a firm reason.
If you're doing something odd then there's no shame in forking the code.

Comment 8:

very true, thanks for the quick response!

Comment 9:

This issue was closed by revision e6e8b72.

Status changed to Fixed.

Comment 10:

This issue was closed by revision 018462b9df95.