# Using the TransportClient with ECK **URL:** \ **Category:** Elastic Cloud on Kubernetes (ECK)\ **Created:** [September 3, 2019, 6:52am UTC](https://discuss.elastic.co/t/using-the-transportclient-with-eck/197767 "2019-09-03T06:52:44Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![akappler](https://avatars.discourse-cdn.com/v4/letter/a/7c8e57/32.png) [@akappler](https://discuss.elastic.co/u/akappler)\ **Post date:** [September 3, 2019, 6:52am UTC](https://discuss.elastic.co/t/using-the-transportclient-with-eck/197767/1 "2019-09-03T06:52:44Z")
We have a legacy application which uses the Java TransportClient to access the ES API on port 9300, which we would like to operate with the ES operator. It seems that the ES instance created by ECK only exposes the REST API on port 9200. Is it possible to use the API on port 9300? I tried to expose it via a Service, but it is secured by client certificate authentication and I cannot figure out how to create a valid certificate. ---
**Author:** ![Artem\_Nikitin](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/artem_nikitin/32/42859_2.png) [@Artem\_Nikitin](https://discuss.elastic.co/u/Artem_Nikitin)\ **Post date:** [September 4, 2019, 10:12am UTC](https://discuss.elastic.co/t/using-the-transportclient-with-eck/197767/2 "2019-09-04T10:12:10Z")
Hi, First of all, Transport Client is currently deprecated and we don't suggest to rely on it in the future. If disabling client authentication is an option for you, then you can do it as described in [https://www.elastic.co/guide/en/elasticsearch/reference/7.3/separating-node-client-traffic.html](https://www.elastic.co/guide/en/elasticsearch/reference/7.3/separating-node-client-traffic.html) ---
**Author:** ![akappler](https://avatars.discourse-cdn.com/v4/letter/a/7c8e57/32.png) [@akappler](https://discuss.elastic.co/u/akappler)\ **Post date:** [September 4, 2019, 1:05pm UTC](https://discuss.elastic.co/t/using-the-transportclient-with-eck/197767/3 "2019-09-04T13:05:47Z")
Thanks for your prompt answer. I followed the instructions and disabled client certificate authentication, the application can now successfully connect to ES. We are aware that the Transport Client is deprecated, but until the migration is implemented we need an intermediate solution. ---
**Author:** ![TimWardFS](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/timwardfs/32/65108_2.png) [@TimWardFS](https://discuss.elastic.co/u/TimWardFS)\ **Post date:** [April 7, 2020, 11:48am UTC](https://discuss.elastic.co/t/using-the-transportclient-with-eck/197767/4 "2020-04-07T11:48:25Z")
What exactly did you do to make this work please? Looking at the referenced documentation, and hoping it also works for the 6.8.8 that I'm constrained to use, it looks like one puts ```auto transport.profiles.client.xpack.security.ssl.client_authentication: none ``` somewhere, but where exactly in the Elasticsearch resource manifest does this go? And even having done that, the connection has to be TLS, yes? So the client needs to either be modified to skip the CA check, or needs the CA certificate? Which is in the `-es-transport-ca-internal` secret? - have I got this right so far? ---
**Author:** ![Thibault\_Richard](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/thibault_richard/32/50513_2.png) [@Thibault\_Richard](https://discuss.elastic.co/u/Thibault_Richard)\ **Post date:** [April 9, 2020, 12:07pm UTC](https://discuss.elastic.co/t/using-the-transportclient-with-eck/197767/5 "2020-04-09T12:07:07Z")
> [@TimWardFS](#): > > somewhere, but where exactly in the Elasticsearch resource manifest does this go? That would go to the config section of the nodeSet: ``` spec: nodeSets: - name: masters count: 3 config: transport.profiles.client.xpack.security.ssl.client_authentication: none ``` > **[Node configuration | Elastic Cloud on Kubernetes \[2.10\] | Elastic](https://www.elastic.co/guide/en/cloud-on-k8s/current/k8s-node-configuration.html)** > [@TimWardFS](#): > > the connection has to be TLS, yes? Yes. The transport networking layer is used for internal communication between nodes in a cluster. As ECK enables the security by default, you must use TLS to ensure that communication between the nodes is encrypted. And ECK does it for you. > [@TimWardFS](#): > > So the client needs to either be modified to skip the CA check, or needs the CA certificate? Which is in the `-es-transport-ca-internal` secret? - have I got this right so far? Absolutely. ---
**Author:** ![TimWardFS](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/timwardfs/32/65108_2.png) [@TimWardFS](https://discuss.elastic.co/u/TimWardFS)\ **Post date:** [April 9, 2020, 12:28pm UTC](https://discuss.elastic.co/t/using-the-transportclient-with-eck/197767/6 "2020-04-09T12:28:03Z")
Thanks, I'd subsequently found the documentation of where to put that config. The next problem is that the SAN of the server certificate does not of course match the name of the bodged service so the client drops the connection. So that's a change to the client code to bypass most of the checking - which, as I do have access to the client code, I can actually do (but haven't done yet). ---
**Author:** ![TimWardFS](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/timwardfs/32/65108_2.png) [@TimWardFS](https://discuss.elastic.co/u/TimWardFS)\ **Post date:** [April 14, 2020, 3:16pm UTC](https://discuss.elastic.co/t/using-the-transportclient-with-eck/197767/7 "2020-04-14T15:16:05Z")
But in fact I have not found any way to tell the Java transport client to ignore the server name mismatch. Has anyone solved this? ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [November 4, 2022, 7:23am UTC](https://discuss.elastic.co/t/using-the-transportclient-with-eck/197767/8 "2022-11-04T07:23:48Z")