Hello.
I see that similar issues have been reported before, but I cannot solve my problem using them.
I'm using NEST 7.17.5 dotnet core client and with the following configurations.
var elasticSettings = new ConnectionSettings(new SingleNodeConnectionPool(new Uri("https://my-cloud-uri")))
.PrettyJson()
.BasicAuthentication("elasdtic", "password")
.DefaultIndex("my_index")
.EnableApiVersioningHeader();
I'm connecting the elastic cloud, and locally on my windows 10 environment, I can connect it successfully. But I when I run the client in the Ubuntu v22.04 container, a got the following error.
The client is unable to verify that the server is Elasticsearch due to an unsuccessful product check call. Some functionality may not be compatible if the server is running an unsupported product. Call: Status code unknown from: GET /?pretty=true
---> Elasticsearch.Net.PipelineException: The client is unable to verify that the server is Elasticsearch due to an unsuccessful product check call. Some functionality may not be compatible if the server is running an unsupported product.
---> System.Net.Http.HttpRequestException: The SSL connection could not be established, see inner exception.
---> System.Security.Authentication.AuthenticationException: The remote certificate is invalid because of errors in the certificate chain: UntrustedRoot
at System.Net.Security.SslStream.SendAuthResetSignal(ProtocolToken message, ExceptionDispatchInfo exception)
at System.Net.Security.SslStream.CompleteHandshake(SslAuthenticationOptions sslAuthenticationOptions)
at System.Net.Security.SslStream.ForceAuthenticationAsync[TIOAdapter](Boolean receiveFirst, Byte[] reAuthenticationData, CancellationToken cancellationToken)
Every single config is the same with windows environment.
What changes on Ubuntu, and how come I can connect successfully to elastic cloud with the same credentials?
The first thing I would try is a curl from the Ubuntu box with the same creds
curl -v -u elastic https://url
You may want to add :443 port there was a time a few of the clients would tack on the default 9200 if a port was not provided.. I don't think that is the issue though.
Curious why you are not using the recommended Cloud ID + API Key.
@Erdem_Sekerci This message is slightly misleading in your case. Looking at the stack trace, I see The SSL connection could not be established, which is the root cause. Something local to your container is causing the SSL handshake to fail to the cloud URL. What image are you using? If it's an older image, potentially, it uses unsupported TLS versions. If you SSH into your container, you will likely be unable to contact the server, even with CURL. You will need to diagnose that first, and then the client should function as expected.
As a side note, we provide a shortcut to configure the client to communicate with the cloud instances where you can provide the cloud ID in the constructor instead of a URL.
Hi Stephen, thanks for your response. Sorry it's a typo that I've done while changed my credentials to dummy text. I have tried Cloud ID + API Key previously and got the same result. I also tried to add certificate finger print I've got the same result as well.
I will try to do curl in the container and share the result shortly.
Hi everyone, thanks for your support. This problem is obviously caused by the old TLS versions of the container as you pointed too. It's been solved after I update the Ubuntu using the command apt-get -y update;
Now all is well. thanks for your quick support.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.