martinsuchan opened a new issue, #11960: URL: https://github.com/apache/ignite/issues/11960
We've discovered a bug in Ignite 2.15-2.17 if `EnableClusterDiscovery` property is set in .NET Client when connecting to a cluster with HTTPS enabled on each host. If we try to connect form .NET Thin client in this configuration, it works without any certificate issues, but then if the **Automatic Server Node Discovery** is enabled (IgniteClientConfiguration.EnableClusterDiscovery), it fails on `RemoteCertificateMismatch`. Interestingly this error is only logged in the background, we can stilll connect to the cluster. We've tried to debug it and we discovered, that requests in the server discovery background process are done by targeting IP addresses of our nodes, rather than using host names or DNS aliases of nodes. Because of that these requests fail via HTTPS, because the IP address is not inlcluded in our host certificates in the SAN list. Including IP addresses in node certificates is not an option in our case. Expected behavior: Automatic Server Node Discovery over HTTPS should not fail if each host has a trusted certificate with proper host name in the SAN list. **Node Discovery requests should use hostnames instead of IP addresses for connections.** See this line in `ClientFailoverSocket.cs` where this behavior starts: https://github.com/apache/ignite/blob/be1f4bc6378c0ceb75a16c286a1a6ee00875d624/modules/platforms/dotnet/Apache.Ignite.Core/Impl/Client/ClientFailoverSocket.cs#L133 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@ignite.apache.org.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
