crypto/tls.ClientConfig: Set Config.Certificates for backwards compat #552
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What this PR does:
A recent change in
crypto/tls.ClientConfig.GetTLSConfig
that allows for reloading of client certs, turned out to breakmemberlist/kv.NewTCPTransport
. Apparently the latter usesClientConfig
for a server, which then fails since there's no longer any certificate config for servers.I propose working around the problem by again setting
crypto/tls.Config.Certificates
, as it used to be prior to the aforementioned change. However, since we now also setGetClientCertificate
, clients will prefer the latter:I've tested that this change fixes the broken integration test in Mimir (
TestSingleBinaryWithMemberlist/tls
).Which issue(s) this PR fixes:
Checklist
CHANGELOG.md
updated - the order of entries should be[CHANGE]
,[FEATURE]
,[ENHANCEMENT]
,[BUGFIX]