Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
crypto/tls: Missing attribute in tls.ConnectionState struct #11881
In some situations,
Illustrations of the problem
the context is a HTTPS offloader/reverse-proxy that have 2 differents certificates each for a different *.FQDN in CommonName ; precisely, cert-1 has *.FQDN-1 CommonName and cert-2 has *.FQDN-2 CommonName
Good case (easily produced with any browser)
a call to
Here, a call to
There are others way to mitigate this situation but are also more complicated.
Why's it a problem if the the ServerName doesn't match the Host header? If the client wants to reuse the connection, presumably it did so because it saw the cert from the first connection and knew that the server did FQDN-2 as well. Doesn't HTTP/2 actually encourage that behavior?
Leaving for @agl to fix or clarify for me.
I don't understand this either. If the client chooses to send a request with a different
If you really want to know what certificate was used for a connection you can control it yourself in Go 1.5 with the GetCertificate callback.