# Client did not trust this server's certificate, closing connection Netty4TcpChannel **URL:** \ **Category:** Elasticsearch\ **Tags:** elastic-stack-security\ **Created:** [June 5, 2019, 11:29am UTC](https://discuss.elastic.co/t/client-did-not-trust-this-servers-certificate-closing-connection-netty4tcpchannel/184342 "2019-06-05T11:29:51Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![sureshrupnar](https://avatars.discourse-cdn.com/v4/letter/s/edb3f5/32.png) [@sureshrupnar](https://discuss.elastic.co/u/sureshrupnar)\ **Post date:** [June 5, 2019, 11:29am UTC](https://discuss.elastic.co/t/client-did-not-trust-this-servers-certificate-closing-connection-netty4tcpchannel/184342/1 "2019-06-05T11:29:51Z")
Hi Team, I want to connect Eleasticsearch 6.8.0 via TransportClient vs 6.8.0, while connecting transport client I am getting below error on elasticsearch - [2019-06-05T15:52:56,827][WARN][o.e.x.c.s.t.n.SecurityNetty4Transport] [node-1] client did not trust this server's certificate, closing connection Ne tty4TcpChannel{localAddress=0.0.0.0/0.0.0.0:9300, remoteAddress=/10.2.242.185:58362} I want to use file/native security by basic license mode. Below are configuration used in elasticsearch.yml - xpack.security.enabled: true xpack.security.transport.ssl.enabled: true xpack.security.transport.ssl.verification\_mode: certificate xpack.security.transport.ssl.keystore.path: certs/certificate.p12 xpack.security.transport.ssl.truststore.path: certs/certificate.p12 xpack.license.self\_generated.type: basic Also below are properties added in JAVA client program - TransportClient client = new PreBuiltXPackTransportClient(Settings.builder() .put("cluster.name", "myClusterName") .put("xpack.security.user", "test\_user:x-pack-test-password") .put("xpack.ssl.certificate\_authorities", "/path/to/ca.crt") .put("xpack.security.transport.ssl.enabled", "true") I am using company/organization provided P12 trustore/keystore. I am able to successfully connect Logstash and Kibana with basic userid and password. But not able to connect our client program to elasticsearch. Basically we want to connect our client transport program like-wise kibana and logstash are connected with different urserid and role. We are not looking for SSL connectivity between transport client, we want to connect it via HTTP communication with userid and password. Please let us know, if we have missed any configuration. ---
**Author:** ![ikakavas](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ikakavas/32/34430_2.png) [@ikakavas](https://discuss.elastic.co/u/ikakavas)\ **Post date:** [June 5, 2019, 1:15pm UTC](https://discuss.elastic.co/t/client-did-not-trust-this-servers-certificate-closing-connection-netty4tcpchannel/184342/2 "2019-06-05T13:15:55Z")
> [@sureshrupnar](#): > > We are not looking for SSL connectivity between transport client, we want to connect it via HTTP communication with userid and password. > [@sureshrupnar](#): > > I want to use file/native security by basic license mode. You can't enable security without also enabling TLS for the transport layer. Also, while username and password is used for authenticating your client to Elasticsearch, but if you don't enable TLS for this communication channel, all data (including the passwords) are sent in plaintext from your client to elasticsearch and can be sniffed. Is there any specific reason that you don't want to use TLS for client communication ? > [@sureshrupnar](#): > > we want to connect it via HTTP communication with userid and password. Transport client doesn't communicate over http either way. Is there any specific reason for using the transport client instead of the [High Level Rest Client](https://www.elastic.co/guide/en/elasticsearch/client/java-rest/7.1/java-rest-high.html) ? The transport client is deprecated in 7.0.0 and will be removed in 8.0.0. That said, the errors you get above are because you have enabled TLS for the transport layer and you have tried to enable TLS in the transport client also, although unsuccessfully. I can see you have copied the configuration from [Java Client and security | Elasticsearch Guide [7.1] | Elastic](https://www.elastic.co/guide/en/elastic-stack-overview/7.1/java-clients.html#transport-client) but you haven't shared with us how you have created the `ca.crt` Once you tell us a little more about what you want to achieve, we ca guide you better. For now, there are too many alternatives to know what to suggest solutions for. ---
**Author:** ![sureshrupnar](https://avatars.discourse-cdn.com/v4/letter/s/edb3f5/32.png) [@sureshrupnar](https://discuss.elastic.co/u/sureshrupnar)\ **Post date:** [June 6, 2019, 9:00am UTC](https://discuss.elastic.co/t/client-did-not-trust-this-servers-certificate-closing-connection-netty4tcpchannel/184342/3 "2019-06-06T09:00:32Z")
Our existing application is based on TranportClient, hence we want to go ahead with TransportClient instead of High Level Rest Client at this moment. we have a plan to migrate it to High Level Rest Client. From 6.8.0, we want to leverage basic authentication feature with existing infrastructure setup. As such we don't have any issue to switch to TLS based client communication. But if it is possible that transport client can communicate to elasticsearch without TLS, then by simply passing user id and password, how it will communicate it with elasticsearch? We are currently using our organization specific CA certificate and P12 trustore/keystore. Yes, your are right. I have tried to follow steps which are mentioned in [https://www.elastic.co/guide/en/elasticsearch/reference/6.8/configuring-tls.html](https://www.elastic.co/guide/en/elasticsearch/reference/6.8/configuring-tls.html) for enabling security feature at elasticsearch. And for transport client, I have followed steps which are mentioned in [https://www.elastic.co/guide/en/elastic-stack-overview/6.8/java-clients.html](https://www.elastic.co/guide/en/elastic-stack-overview/6.8/java-clients.html) Looks like we have enabled TLS at both places. Is it possible without enabling TLS feature I can use basic security feature in transport client as well? We don't have any issues while communicating with Logstash and Kibana, but we are struggling with transport client communication. Also I have tried to enable TLS at elasticsearch, but still I am getting same error which was mentioned in the beginning. Also if I remove below line from JAVA client program .put("xpack.security.transport.ssl.enabled", "true") , then getting below error - [2019-06-06T14:41:25,741][WARN][o.e.t.TcpTransport] [node-1] exception caught on transport layer [Netty4TcpChannel{localAddress=0.0.0.0/0.0.0. 0:9300, remoteAddress=/10.2.242.185:53780}], closing connection io.netty.handler.codec.DecoderException: io.netty.handler.ssl.NotSslRecordException: not an SSL/TLS record: 455300000069000000000000000208004d3603010d 417574686f72697a6174696f6e2e42617369632064484a68626e4e7762334a3058324e736157567564463931633256794f6b316b625541784d6a4d3d0016696e7465726e616c3a7463702f 68616e647368616b650004e38cf302 ---
**Author:** ![ikakavas](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ikakavas/32/34430_2.png) [@ikakavas](https://discuss.elastic.co/u/ikakavas)\ **Post date:** [June 6, 2019, 9:08am UTC](https://discuss.elastic.co/t/client-did-not-trust-this-servers-certificate-closing-connection-netty4tcpchannel/184342/4 "2019-06-06T09:08:16Z")
> [@sureshrupnar](#): > > But if it is possible that transport client can communicate to elasticsearch without TLS, then by simply passing user id and password, how it will communicate it with elasticsearch? I'm not sure I understand your question, can you please rephrase it ? > [@sureshrupnar](#): > > Is it possible without enabling TLS feature I can use basic security feature in transport client as well? I'd strongly suggest against this for reasons shared above. You have done most of the configuration already either way, the only problem with your setup now feels to be that this `"/path/to/ca.crt"` is wrong. This needs to contain the CA certificate, that is also the one that signed the certificates that are used in the `certificate.p12` you have in ES. Did you get both `certificate.p12` and `ca.crt` from somwhere in your company, or did you export the `ca.crt` from the `certificate.p12` yourself ? If so, how did you do this ? > [@](#): > > Also if I remove below line from JAVA client program > > .put("xpack.security.transport.ssl.enabled", "true") > > , then getting below error - > > ```auto > [2019-06-06T14:41:25,741][WARN][o.e.t.TcpTransport] [node-1] exception caught on transport layer [Netty4TcpChannel{localAddress=0.0.0.0/0.0.0. > 0:9300, remoteAddress=/10.2.242.185:53780}], closing connection > io.netty.handler.codec.DecoderException: io.netty.handler.ssl.NotSslRecordException: not an SSL/TLS record: 455300000069000000000000000208004d3603010d > 417574686f72697a6174696f6e2e42617369632064484a68626e4e7762334a3058324e736157567564463931633256794f6b316b625541784d6a4d3d0016696e7465726e616c3a7463702f > 68616e647368616b650004e38cf302 > > ``` This is expected behavior. Elasticsearch is expecting a connection over TLS, your client attempts to communicate without TLS, and the connection fails. ---
**Author:** ![sureshrupnar](https://avatars.discourse-cdn.com/v4/letter/s/edb3f5/32.png) [@sureshrupnar](https://discuss.elastic.co/u/sureshrupnar)\ **Post date:** [June 6, 2019, 9:45am UTC](https://discuss.elastic.co/t/client-did-not-trust-this-servers-certificate-closing-connection-netty4tcpchannel/184342/5 "2019-06-06T09:45:03Z")
certificate.p12 and ca.crt both files, I have received from company. ---
**Author:** ![ikakavas](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ikakavas/32/34430_2.png) [@ikakavas](https://discuss.elastic.co/u/ikakavas)\ **Post date:** [June 6, 2019, 10:16am UTC](https://discuss.elastic.co/t/client-did-not-trust-this-servers-certificate-closing-connection-netty4tcpchannel/184342/6 "2019-06-06T10:16:00Z")
> [@sureshrupnar](#): > > certificate.p12 and ca.crt both files, I have received from company. It looks like that the certificate that is contained in `certificate.p12` (which is the one used by Elasticsearch for TLS on the transport layer) is _not_ signed by the CA certificate that is contained in the `ca.crt` file. Can you speak to someone at your company and get the correct CA certificate ? > [@sureshrupnar](#): > > We don't have any issues while communicating with Logstash and Kibana, but we are struggling with transport client communication. Logstash and Kibana both communicate with elasticsearch on the HTTP layer and not the transport layer. ---
**Author:** ![sureshrupnar](https://avatars.discourse-cdn.com/v4/letter/s/edb3f5/32.png) [@sureshrupnar](https://discuss.elastic.co/u/sureshrupnar)\ **Post date:** [June 6, 2019, 11:00am UTC](https://discuss.elastic.co/t/client-did-not-trust-this-servers-certificate-closing-connection-netty4tcpchannel/184342/7 "2019-06-06T11:00:51Z")
The ca.crt and certificate.p12 files were received from our certificate registry portal where everyone is getting from that portal only. We are using these certificates in across the company for different application. I don't think, there is an issue with ca.crt and certificate.p12 file. Meanwhile I have did some testing around this - 1. firstly I disabled verficate mode in elasticsearch.yml file - xpack.security.transport.ssl.verification\_mode: none getting same error - client did not trust this server's certificate, closing connection 1. Then I tried with removing below two properties from transport client program - .put("xpack.security.user", "transport\_client\_user:Pass@123") .put("xpack.ssl.certificate\_authorities", "ca.crt") even I am getting same error - client did not trust this server's certificate, closing connection Only I am getting different error, whenever I am removing - .put("xpack.security.transport.ssl.enabled", "true") getting error as -not an SSL/TLS record Looks like something wired configuration or settings. please guide here how to proceed further. ---
**Author:** ![ikakavas](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ikakavas/32/34430_2.png) [@ikakavas](https://discuss.elastic.co/u/ikakavas)\ **Post date:** [June 6, 2019, 2:48pm UTC](https://discuss.elastic.co/t/client-did-not-trust-this-servers-certificate-closing-connection-netty4tcpchannel/184342/8 "2019-06-06T14:48:47Z")
> [@sureshrupnar](#): > > Meanwhile I have did some testing around this - > > 1. firstly I disabled verficate mode in elasticsearch.yml file - > xpack.security.transport.ssl.verification\_mode: none **Your problem is that the client doesn't trust the certificate of Elasticsearch**. What you configured here is Elasticsearch to not validate the certificate of the client, this shouldn't have any effect to the problem you have and it doesn't, as you observed. > [@sureshrupnar](#): > > Then I tried with removing below two properties from transport client program - > .put("xpack.security.user", "transport\_client\_user:Mdm@123") > .put("xpack.ssl.certificate\_authorities", "ca.crt") **Your problem is that the client doesn't trust the certificate of Elasticsearch.** What you tried here is to a) have your client make requests to Elasticsearch without a username and password , which is unrelated to your problem b) Remove the configuration setting that would allow your client to trust the Elasticsearch certificate, which - as expected - didn't change anything. > [@sureshrupnar](#): > > Only I am getting different error, whenever I am removing - > .put("xpack.security.transport.ssl.enabled", "true") > > getting error as -not an SSL/TLS record **Your problem is that the client doesn't trust the certificate of Elasticsearch.** What you tried to do here is to have your client not connect via SSL to Elasticsearh, which as expected, did not work. I already explained before why you get this. Elasticsearch is expecting TLS connections on the transport layer and you go and configure your client to not use TLS, so Elasticsearch fails with a clear message - as expected. > [@](#): > > The ca.crt and certificate.p12 files were received from our certificate registry portal where everyone is getting from that portal only. We are using these certificates in across the company for different application. I don't think, there is an issue with ca.crt and certificate.p12 file. Can't you at least verify this is the truth, instead of dismissing the idea ? Export the elasticsearch certificate from the certificate.p12: ```auto openssl pkcs12 -in certificate.p12 -clcerts -nokeys > elasticsearch.crt ``` Try to validate that `ca.crt` is the CA that has signed the `elasticsearch.crt` and share the output : ```auto openssl verity -CAfile ca.crt elasticsearch.crt ``` ---
**Author:** ![sureshrupnar](https://avatars.discourse-cdn.com/v4/letter/s/edb3f5/32.png) [@sureshrupnar](https://discuss.elastic.co/u/sureshrupnar)\ **Post date:** [June 7, 2019, 6:08am UTC](https://discuss.elastic.co/t/client-did-not-trust-this-servers-certificate-closing-connection-netty4tcpchannel/184342/9 "2019-06-07T06:08:55Z")
Thanks for the detailed description, and correcting the approaches on reaching out exact root cause. By execution of above openssl commands, I am getting below error on root and group root CA certificates - 1. Root CA - error 2 at 1 depth lookup:unable to get issuer certificate 2. Group Root CA - error 20 at 0 depth lookup:unable to get local issuer certificate ---
**Author:** ![ikakavas](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ikakavas/32/34430_2.png) [@ikakavas](https://discuss.elastic.co/u/ikakavas)\ **Post date:** [June 7, 2019, 6:26am UTC](https://discuss.elastic.co/t/client-did-not-trust-this-servers-certificate-closing-connection-netty4tcpchannel/184342/10 "2019-06-07T06:26:36Z")
It is more helpful when you post the command and the whole output instead. The result reinforces my assumption that the ca.crt is not the correct one as the certificate in certificate.p12 cannot be verified by it. Please talk to your company and get the correct certificates, we cant help you any more until you do that. ---
**Author:** ![sureshrupnar](https://avatars.discourse-cdn.com/v4/letter/s/edb3f5/32.png) [@sureshrupnar](https://discuss.elastic.co/u/sureshrupnar)\ **Post date:** [June 7, 2019, 7:15am UTC](https://discuss.elastic.co/t/client-did-not-trust-this-servers-certificate-closing-connection-netty4tcpchannel/184342/11 "2019-06-07T07:15:57Z")
Now I have created CA file from below openssl command - openssl pkcs12 -in certificate.p12 -cacerts -nokeys -chain | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' \> cacerts.cer And I have verified CA file as per command you have given - C:\Users\Downloads\elasticsearch-6.8.0\config\certs\>openssl OpenSSL\> verify -CAfile cacerts.cer elasticsearch.crt elasticsearch.crt: OK OpenSSL\> Then I have used same cacerts.cer file in transport client program - .put("xpack.ssl.certificate\_authorities", "C:/Users/Downloads/keystore/cacerts.cer") but getting same error as "client did not trust this server's certificate, closing connection" ---
**Author:** ![ikakavas](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ikakavas/32/34430_2.png) [@ikakavas](https://discuss.elastic.co/u/ikakavas)\ **Post date:** [June 7, 2019, 8:13am UTC](https://discuss.elastic.co/t/client-did-not-trust-this-servers-certificate-closing-connection-netty4tcpchannel/184342/12 "2019-06-07T08:13:06Z")
I can only assume that hostname verification fails ( i.e. your certificate is issued for a different domain name/IP Address than the one you attempt to connect to ) 1. Check what you use to connect to Elasticsearch from the client ( find the `.addTransportAddress(XXX)` in your `PreBuiltXPackTransportClient` ) and take a note of that IP Address. 2. What's the output of If the above fails also, you can either: - Get a proper certificate that has the IP Addresses of your Elasticserach nodes as Subject Alternate Names - Disable hostname verification (at your own risk) by setting ```auto .put("xpack.ssl.verification_mode", "certificate") ``` ---
**Author:** ![sureshrupnar](https://avatars.discourse-cdn.com/v4/letter/s/edb3f5/32.png) [@sureshrupnar](https://discuss.elastic.co/u/sureshrupnar)\ **Post date:** [June 7, 2019, 9:25am UTC](https://discuss.elastic.co/t/client-did-not-trust-this-servers-certificate-closing-connection-netty4tcpchannel/184342/13 "2019-06-07T09:25:24Z")
Below is the output by executing command of #2 - C:\Users\rupnsur\>openssl s\_client -connect 10.2.242.185:9300 -CAfile C:/Users/Downloads/keystore/cacerts.cer Loading 'screen' into random state - done CONNECTED(00000168) 17908:error:140770FC:SSL routines:SSL23\_GET\_SERVER\_HELLO:unknown protocol:.\ssl\s23\_clnt.c:610: And at elasticsearch log, we have received below error message - [2019-06-07T14:46:48,433][WARN][o.e.t.TcpTransport] [node-1] exception caught on transport layer [Netty4TcpChannel{localAddress=0.0.0.0/0.0.0. 0:9300, remoteAddress=/10.2.242.185:61024}], closing connection io.netty.handler.codec.DecoderException: javax.net.ssl.SSLHandshakeException: SSLv2Hello is disabled Meanwhile i'll work on suggestions which you have mentioned in the bottom and share the result. ---
**Author:** ![ikakavas](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ikakavas/32/34430_2.png) [@ikakavas](https://discuss.elastic.co/u/ikakavas)\ **Post date:** [June 7, 2019, 9:46am UTC](https://discuss.elastic.co/t/client-did-not-trust-this-servers-certificate-closing-connection-netty4tcpchannel/184342/14 "2019-06-07T09:46:43Z")
> [@sureshrupnar](#): > > Below is the output by executing command of #2 - > C:\Users\rupnsur\>openssl s\_client -connect 10.2.242.185:9300 -CAfile C:/Users/Downloads/keystore/cacerts.cer > Loading 'screen' into random state - done > CONNECTED(00000168) > 17908:error:140770FC:SSL routines:SSL23\_GET\_SERVER\_HELLO:unknown protocol:.\ssl\s23\_clnt.c:610: > > And at elasticsearch log, we have received below error message - > [2019-06-07T14:46:48,433][WARN][o.e.t.TcpTransport] [node-1] exception caught on transport layer [Netty4TcpChannel{localAddress=0.0.0.0/0.0.0. > 0:9300, remoteAddress=/10.2.242.185:61024}], closing connection > io.netty.handler.codec.DecoderException: javax.net.ssl.SSLHandshakeException: SSLv2Hello is disabled This has probably nothing to do with what we're dealing so far, it's just that openssl on your machine uses `sslv2` by default ( which is strange but still, unrelated to previous errors ) You can specify the protocol version by setting one of `-tls1_1`, `-tls1_2` in your `openssl s_client` command. ---
**Author:** ![sureshrupnar](https://avatars.discourse-cdn.com/v4/letter/s/edb3f5/32.png) [@sureshrupnar](https://discuss.elastic.co/u/sureshrupnar)\ **Post date:** [June 7, 2019, 2:32pm UTC](https://discuss.elastic.co/t/client-did-not-trust-this-servers-certificate-closing-connection-netty4tcpchannel/184342/15 "2019-06-07T14:32:40Z")
Now I have received new certificate.p12 and CA.cer file for IP Addresses. Also I have followed CA certificate Openssl verify, I got 'OK' Afterwards I tried to connect to elasticsearch - C:\Users\rupnsur\>openssl s\_client -connect 10.2.242.185:9300 -CAfile C:/Users/Downloads/keystore/cacerts.cer but I have received different error now - [2019-06-07T19:58:45,128][WARN][o.e.t.TcpTransport] [node-1] exception caught on transport layer [Netty4TcpChannel{localAddress=0.0.0.0/0.0.0. 0:9300, remoteAddress=/10.2.242.185:63808}], closing connection io.netty.handler.codec.DecoderException: javax.net.ssl.SSLHandshakeException: null cert chain Afterwards I have tried to put below configuration in elasticsearch.yml - xpack.security.transport.ssl.client\_authentication: none And I am able to successfully connect to elasticsearch. No exceptions found. I don't know exactly, what will be impact if I use above configuration? pls explain. ---
**Author:** ![ikakavas](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ikakavas/32/34430_2.png) [@ikakavas](https://discuss.elastic.co/u/ikakavas)\ **Post date:** [June 7, 2019, 2:50pm UTC](https://discuss.elastic.co/t/client-did-not-trust-this-servers-certificate-closing-connection-netty4tcpchannel/184342/16 "2019-06-07T14:50:16Z")
> [@sureshrupnar](#): > > Afterwards I have tried to put below configuration in elasticsearch.yml - > xpack.security.transport.ssl.client\_authentication: none ~~I can't see how this plays any role. You didn't have this set in the config you have shared with us previously and the default value for this is `none`, so adding the setting explicitly shouldn't make any difference at all.~~ This setting controls whether the client is also required to present a certificate and key for client TLS authentication. ~~This should not be relevant here. If your client can connect with the current settings, then you're good to go.~~ This was badly misspoken, see @TimV post below. ---
**Author:** ![sureshrupnar](https://avatars.discourse-cdn.com/v4/letter/s/edb3f5/32.png) [@sureshrupnar](https://discuss.elastic.co/u/sureshrupnar)\ **Post date:** [June 10, 2019, 10:15am UTC](https://discuss.elastic.co/t/client-did-not-trust-this-servers-certificate-closing-connection-netty4tcpchannel/184342/17 "2019-06-10T10:15:13Z")
Thanks for all the help and detailed description. ---
**Author:** ![TimV](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/timv/32/13162_2.png) [@TimV](https://discuss.elastic.co/u/TimV)\ **Post date:** [June 11, 2019, 7:17am UTC](https://discuss.elastic.co/t/client-did-not-trust-this-servers-certificate-closing-connection-netty4tcpchannel/184342/18 "2019-06-11T07:17:12Z")
> [@sureshrupnar](#): > > xpack.security.transport.ssl.client\_authentication: none This is a bad idea. It means that any client can connect to your elasticsearch cluster (using transport protocol) without needing a client certificate. This opens up your cluster to having a rogue client connect and send malicious commands. > [@ikakavas](#): > > the default value for this is `none` That is true for the `http` SSL context. For `transport` it defaults to `required`. ---
**Author:** ![sureshrupnar](https://avatars.discourse-cdn.com/v4/letter/s/edb3f5/32.png) [@sureshrupnar](https://discuss.elastic.co/u/sureshrupnar)\ **Post date:** [June 11, 2019, 8:36am UTC](https://discuss.elastic.co/t/client-did-not-trust-this-servers-certificate-closing-connection-netty4tcpchannel/184342/19 "2019-06-11T08:36:53Z")
We are passing total 4 parameter - 1. xpack.security.user 2. xpack.ssl.verification\_mode 3. xpack.security.transport.ssl.enabled 4. xpack.ssl.certificate\_authorities Whenever I am using correct CA certificate, then I am getting below error - [2019-06-07T19:58:45,128][WARN][o.e.t.TcpTransport] [node-1] exception caught on transport layer [Netty4TcpChannel{localAddress=0.0.0.0/0.0.0. 0:9300, remoteAddress=/10.2.242.185:63808}], closing connection io.netty.handler.codec.DecoderException: javax.net.ssl.SSLHandshakeException: null cert chain So you mean "xpack.security.user" credentials are not playing any role in terms of authentication and certificate based communication plays an important role in protecting cluster data. Can you guide me on resolving this issue so that I can achieve basic level of security. ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 9, 2019, 8:36am UTC](https://discuss.elastic.co/t/client-did-not-trust-this-servers-certificate-closing-connection-netty4tcpchannel/184342/20 "2019-07-09T08:36:54Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.