-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Connection with multiple TLS brokers fails to negotiate #1700
Comments
The problem in this ab525ed conf is a pointer to sarama.Config, so it set ServerName for the first broker and the remaining brokers try to use tls with wrong ServerName |
🤔 weird, we don't have that issue, I left running in one test app, and it's been running fine, that app connects to a 80 brokers cluster with no issues. |
The code can be modified to create a copy/clone |
but it does work for us 🤷 |
@dselyuzhitskiy Can you try #1701 branch |
@d1egoaz i checked it and it works well. i left a comment about code improvement in PR |
I looked at #1666 and i could not understand what is wrong with tls.DialWithDialer that solves all problems. For proxy support we just need get correct dialer from config.getDialer and send it to DialWithDialer, i think.
|
@dselyuzhitskiy I was trying to do the same actually, but broker.… 159 43 error compiler: cannot use &dialer (value of type *proxy.Dialer) as *net.Dialer value in argument to tls.DialWithDialer (lsp)
and |
Thanks for the explanation, i missed it. |
We are also having trouble publishing on 1.26.3, downgrading to 1.26.1 fixes for us. We are using 3 tls servers. Looking forward to a 1.26.4 with a fix. Also happy to test any potential fixes. |
@joelschopp can you try #1701? |
Added this to my go.mod at it works for me... note
|
Versions
Configuration
broker01 has certificate with cn=broker01
broker02 has certificate with cn=broker02
Logs
Problem Description
Server name for TLS connection inferred incorrectly when multiple brokers are used.
We beleive, the bug is in the code below (
broker.go
)When, in the first iteration of the cycle the cfg is changed, ServerName is never empty again. So all other connections will have incorrect ServerName and therefore fail the TLS negotiation.
The text was updated successfully, but these errors were encountered: