[ 
https://issues.apache.org/jira/browse/IGNITE-24906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18041781#comment-18041781
 ] 

Pavel Tupitsyn commented on IGNITE-24906:
-----------------------------------------

As discussed in the original [GitHub 
issue|https://github.com/apache/ignite/issues/11960], this is likely not a bug. 
The user has to set *IgniteConfiguration.localhost* to the proper host name for 
this scenario to work (I have tested that .NET client will use the configured 
host name in this case). Otherwise Ignite has no way of knowing the correct 
host name to use.

> .NET: Client Node Discovery fails with HTTPS enabled
> ----------------------------------------------------
>
>                 Key: IGNITE-24906
>                 URL: https://issues.apache.org/jira/browse/IGNITE-24906
>             Project: Ignite
>          Issue Type: Bug
>          Components: platforms, thin client
>    Affects Versions: 2.15, 2.16, 2.17
>            Reporter: Pavel Tupitsyn
>            Assignee: Pavel Tupitsyn
>            Priority: Major
>              Labels: .NET
>             Fix For: 2.18
>
>
> Automatic Node Discovery fails in .NET Thin Client with HTTPS enabled due to 
> certificate validation issues.
> *Steps to Reproduce:*
> * Set up a cluster where each node has HTTPS enabled and a trusted 
> certificate with both the hostname and DNS alias in the SAN list.
> * Connect to the cluster using the .NET Thin Client.
> * Enable Automatic Server Node Discovery 
> (IgniteClientConfiguration.EnableClusterDiscovery).
> * Observe that the discovery process fails with a 
> *RemoteCertificateNameMismatch* error.
> *Observed Behavior:*
> * The error occurs because discovery requests target IP addresses instead of 
> hostnames.
> * Since the IP addresses are not included in the certificate's SAN list, 
> certificate validation fails.
> * The error is logged in the background, but the client is still able to 
> connect.
> *Expected Behavior:*
> * Automatic Server Node Discovery should not fail when each host has a valid, 
> trusted certificate.
> * Discovery requests should use hostnames instead of IP addresses for HTTPS 
> connections.
> *Log output:*
> {code}
> [11:16:49] [Error] [ClientFailoverSocket] Failed to update topology 
> information (exception: 
> System.Security.Authentication.AuthenticationException: The remote 
> certificate was rejected by the provided RemoteCertificateValidationCallback.
>    at 
> System.Net.Security.SslStream.CompleteHandshake(SslAuthenticationOptions 
> sslAuthenticationOptions)
>    at 
> System.Net.Security.SslStream.ForceAuthenticationAsync[TIOAdapter](Boolean 
> receiveFirst, Byte[] reAuthenticationData, CancellationToken 
> cancellationToken)
>    at 
> System.Net.Security.SslStream.ProcessAuthenticationWithTelemetryAsync(Boolean 
> isAsync, CancellationToken cancellationToken)
>    at 
> System.Net.Security.SslStream.AuthenticateAsClient(SslClientAuthenticationOptions
>  sslClientAuthenticationOptions)
>    at Apache.Ignite.Core.Client.SslStreamFactory.Create(Stream stream, String 
> targetHost)
>    at Apache.Ignite.Core.Impl.Client.ClientSocket.GetSocketStream(Socket 
> socket, IgniteClientConfiguration cfg, String host)
>    at 
> Apache.Ignite.Core.Impl.Client.ClientSocket..ctor(IgniteClientConfiguration 
> clientConfiguration, EndPoint endPoint, String host, Nullable`1 version, 
> Action`1 topVerCallback, Marshaller marshaller)
>    at 
> Apache.Ignite.Core.Impl.Client.ClientFailoverSocket.TryConnect(ClientDiscoveryNode
>  node)
>    at Apache.Ignite.Core.Impl.Client.ClientFailoverSocket.InitSocketMap()
>    at 
> Apache.Ignite.Core.Impl.Client.ClientFailoverSocket.<OnAffinityTopologyVersionChange>b__40_0(Object
>  _))
> {code}
> Potential cause: *ClientFailoverSocket* in the .NET client uses IP endpoints 
> instead of hostnames.
> Reference: 
> [ClientFailoverSocket.cs#L948|https://github.com/apache/ignite/blob/be1f4bc6378c0ceb75a16c286a1a6ee00875d624/modules/platforms/dotnet/Apache.Ignite.Core/Impl/Client/ClientFailoverSocket.cs#L133]



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to