Automatic Node Discovery fails in .NET Client with HTTPS enabled

[martinsuchan]

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:

ignite/modules/platforms/dotnet/Apache.Ignite.Core/Impl/Client/ClientFailoverSocket.cs

Line 133 in be1f4bc

_endPoints = GetIpEndPoints(config).ToList();

[ptupitsyn]

Thank you for the detailed report, ticket created: https://issues.apache.org/jira/browse/IGNITE-24906

[martinsuchan]

Update, the same error is also logged when using this property in .NET Thin client and using HTTPS on server:
IgniteClientConfiguration.EnableHeartbeats = true
even when automatic node discovery and partition awareness is set to false.