# HTTPS access via x-pack problems **URL:** \ **Category:** Elasticsearch\ **Created:** [August 30, 2018, 11:36am UTC](https://discuss.elastic.co/t/https-access-via-x-pack-problems/146690 "2018-08-30T11:36:27Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![Arthur\_Bulakaiev](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/arthur_bulakaiev/32/20893_2.png) [@Arthur\_Bulakaiev](https://discuss.elastic.co/u/Arthur_Bulakaiev)\ **Post date:** [August 30, 2018, 11:36am UTC](https://discuss.elastic.co/t/https-access-via-x-pack-problems/146690/1 "2018-08-30T11:36:27Z")
Hi all! I'm trying to configure an https access to my elasticsearch server and I got stuck with it. My elasticsearch version is 6.2.4, I have installed x-pack for it, and followed this article: [https://www.elastic.co/guide/en/elasticsearch/reference/6.x/configuring-tls.html](https://www.elastic.co/guide/en/elasticsearch/reference/6.x/configuring-tls.html) I have generated certificates like in first chapter, my elasticsearch yml looks like: bootstrap.memory\_lock: false cluster.name: elasticsearch http.port: 9200 transport.tcp.port: 59205 network.bind\_host: 0.0.0.0 node.data: true node.ingest: true node.master: true node.max\_local\_storage\_nodes: 1 node.name: ololo path.data: D:\Program Files\Elastic\6.2.4\data path.logs: D:\Program Files\Elastic\6.2.4\logs xpack.security.enabled: true xpack.license.self\_generated.type: basic xpack.security.transport.ssl.enabled: true xpack.ssl.verification\_mode: none xpack.security.http.ssl.client\_authentication: none xpack.security.transport.ssl.client\_authentication: none xpack.security.transport.ssl.keystore.path: D:\Program Files\Elastic\6.2.4\bin\elastic-certificates.p12 xpack.security.transport.ssl.truststore.path: D:\Program Files\Elastic\6.2.4\bin\elastic-certificates.p12 When I start the server, access through http is ok, but through https I got error: ERR\_INVALID\_HTTP\_RESPONSE (in browser) and in curl This is not a HTTP portcurl: (56) Failure when receiving data from the peer or (35) schannel: SNI or certificate check failed: SEC\_E\_WRONG\_PRINCIPAL (0x80090322) - The target principal name is incorrect. depending on commands I tried to use. Could someone help me, please, to reveal the wrong or missed parts in the 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:** [August 30, 2018, 12:07pm UTC](https://discuss.elastic.co/t/https-access-via-x-pack-problems/146690/2 "2018-08-30T12:07:41Z")
Hi there, few things: 1. You haven't enabled [TLS for the http layer](https://www.elastic.co/guide/en/elasticsearch/reference/current/configuring-tls.html#tls-http) of Elasticsearch, you need to add : ```auto xpack.security.http.ssl.enabled: true ``` and also add the relevant keystore and truststore paths as you have done for the transport layer. See the documentation for details. 1. Your keys/certificates/keystores/truststores must be placed within the Elasticsearch configuration directory, so you cannot place them in `D:\Program Files\Elastic\6.2.4\bin\` . Note that you can also use relative paths to the Elasticsearch configuration directory (Which judging by the information you shared should be `D:\Program Files\Elastic\6.2.4\config` ) ---
**Author:** ![Arthur\_Bulakaiev](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/arthur_bulakaiev/32/20893_2.png) [@Arthur\_Bulakaiev](https://discuss.elastic.co/u/Arthur_Bulakaiev)\ **Post date:** [August 30, 2018, 12:40pm UTC](https://discuss.elastic.co/t/https-access-via-x-pack-problems/146690/3 "2018-08-30T12:40:04Z")
Thank you for your reply! I have made the changes you suggest, but now I have http connection broken too, but it's ok 🙂 I placed certificate into config folder, registered it from there, and my config strings now looks like: xpack.security.http.ssl.keystore.path: elastic-certificates.p12 During the start elasticsearch show me the warnings: [2018-08-30T15:33:59,730][WARN][o.e.x.s.t.n.SecurityNetty4ServerTransport] [ololo] client did not trust this server's certificate, closing connection NettyTcpChannel{localAddress=0.0.0.0/0.0.0.0:59205, remoteAddress=/0:0:0:0:0:0:0:1:5032} io.netty.handler.codec.DecoderException: javax.net.ssl.SSLHandshakeException: General SSLEngine problem [2018-08-30T15:34:00,628][WARN][o.e.x.s.t.n.SecurityNetty4ServerTransport] [ololo] client did not trust this server's certificate, closing connection NettyTcpChannel{localAddress=0.0.0.0/0.0.0.0:59205, remoteAddress=/0:0:0:0:0:0:0:1:5033} [2018-08-30T15:34:01,622][WARN][o.e.x.s.t.n.SecurityNetty4ServerTransport] [ololo] client did not trust this server's certificate, closing connection NettyTcpChannel{localAddress=0.0.0.0/0.0.0.0:59205, remoteAddress=/0:0:0:0:0:0:0:1:5034} It looks like it tires to enumerate several ports on remote address and stops after 3 errors. I really have not this ports opened on my server, should I configure another ports (and how to do this if so)? ---
**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:** [August 30, 2018, 12:48pm UTC](https://discuss.elastic.co/t/https-access-via-x-pack-problems/146690/4 "2018-08-30T12:48:37Z")
> [@Arthur\_Bulakaiev](#): > > I have made the changes you suggest, but now I have http connection broken too, but it's ok 🙂 You cannot connect to elasticsearch both via https and http. If you enable TLS for the http layer, you can't connect via http any more. This is expected and desired. > [@Arthur\_Bulakaiev](#): > > [2018-08-30T15:33:59,730][WARN][o.e.x.s.t.n.SecurityNetty4ServerTransport] [ololo] client did not trust this server's certificate, closing connection NettyTcpChannel{localAddress=0.0.0.0/0.0.0.0:59205, remoteAddress=/0:0:0:0:0:0:0:1:5032} > io.netty.handler.codec.DecoderException: javax.net.ssl.SSLHandshakeException: General SSLEngine problem > > [2018-08-30T15:34:00,628][WARN][o.e.x.s.t.n.SecurityNetty4ServerTransport] [ololo] client did not trust this server's certificate, closing connection NettyTcpChannel{localAddress=0.0.0.0/0.0.0.0:59205, remoteAddress=/0:0:0:0:0:0:0:1:5033} > > [2018-08-30T15:34:01,622][WARN][o.e.x.s.t.n.SecurityNetty4ServerTransport] [ololo] client did not trust this server's certificate, closing connection NettyTcpChannel{localAddress=0.0.0.0/0.0.0.0:59205, remoteAddress=/0:0:0:0:0:0:0:1:5034} These are irrelevant to the http layer. > [@Arthur\_Bulakaiev](#): > > It looks like it tires to enumerate several ports on remote address and stops after 3 errors. I really have not this ports opened on my server, should I configure another ports (and how to do this if so)? No, not really, this doesn't have to do with the ports being open or not. This is about the certificate that is used in the transport layer not being trusted. - Can you please share your updated configuration ? - Is this the only ES node in your cluster? - Which port are you using when trying to access Elasticsearch over https? - Can you share a larger part of the logs ? ( Please use the `` button to wrap your logs. ) ---
**Author:** ![Arthur\_Bulakaiev](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/arthur_bulakaiev/32/20893_2.png) [@Arthur\_Bulakaiev](https://discuss.elastic.co/u/Arthur_Bulakaiev)\ **Post date:** [August 30, 2018, 1:04pm UTC](https://discuss.elastic.co/t/https-access-via-x-pack-problems/146690/5 "2018-08-30T13:04:01Z")
> [@ikakavas](#): > > These are irrelevant to the http layer. Ok, and when I turned on the xpack.ssl.verification\_mode: certificate mode this warnings are gone. > [@ikakavas](#): > > Can you please share your updated configuration ? ``` bootstrap.memory_lock: false cluster.name: elasticsearch http.port: 9200 transport.tcp.port: 59205 network.bind_host: 0.0.0.0 node.data: true node.ingest: true node.master: true node.max_local_storage_nodes: 1 node.name: ololo path.data: D:\Program Files\Elastic\6.2.4\data path.logs: D:\Program Files\Elastic\6.2.4\logs xpack.security.enabled: true xpack.license.self_generated.type: basic xpack.security.http.ssl.enabled: true xpack.security.http.ssl.client_authentication: none xpack.security.http.ssl.keystore.path: elastic-certificates.p12 xpack.security.http.ssl.truststore.path: elastic-certificates.p12 xpack.security.transport.ssl.enabled: true xpack.security.transport.ssl.client_authentication: none xpack.security.transport.ssl.keystore.path: elastic-certificates.p12 xpack.security.transport.ssl.truststore.path: elastic-certificates.p12 xpack.ssl.verification_mode: certificate ``` > [@ikakavas](#): > > Is this the only ES node in your cluster? Yes > [@ikakavas](#): > > Which port are you using when trying to access Elasticsearch over https? I have tried to use port 59205, but it seems to be wrong, as "The transport module is used for internal communication between nodes within the cluster". When I tried to use http port 9200 for accessing elasticsearch via https it finally give me a desired json data. And now I'm able to send data using the address like https://my\_ip:9200/index/doc Thank you very much, ikakavas, you helped me a lot! ---
**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:** [August 30, 2018, 1:24pm UTC](https://discuss.elastic.co/t/https-access-via-x-pack-problems/146690/6 "2018-08-30T13:24:42Z")
> [@Arthur\_Bulakaiev](#): > > I have tried to use port 59205, but it seems to be wrong, Yes this is wrong. This is the port for the transport layer, this is where other elasticsearch nodes in your cluster can communicate to. As you figured out, `9200` is the default port for the http layer (whether or not http is over TLS ) ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [September 27, 2018, 1:24pm UTC](https://discuss.elastic.co/t/https-access-via-x-pack-problems/146690/7 "2018-09-27T13:24:45Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.