# Elasticsearch throws a SSLHandshakeException: Client requested protocol TLSv1.2 is not enabled or supported in server context

**URL:** <https://discuss.elastic.co/t/elasticsearch-throws-a-sslhandshakeexception-client-requested-protocol-tlsv1-2-is-not-enabled-or-supported-in-server-context/328294>\
**Category:** Elasticsearch\
**Tags:** elastic-stack-security\
**Created:** [March 22, 2023, 10:15pm UTC](https://discuss.elastic.co/t/elasticsearch-throws-a-sslhandshakeexception-client-requested-protocol-tlsv1-2-is-not-enabled-or-supported-in-server-context/328294 "2023-03-22T22:15:16Z")\
**Posts on this page:** 11\
**Page:** 1

<div class="post-metadata">

**Author:** ![wlktiago70](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/wlktiago70/32/118791_2.png) [@wlktiago70](https://discuss.elastic.co/u/wlktiago70)\
**Post date:** [March 22, 2023, 10:15pm UTC](https://discuss.elastic.co/t/elasticsearch-throws-a-sslhandshakeexception-client-requested-protocol-tlsv1-2-is-not-enabled-or-supported-in-server-context/328294/1 "2023-03-22T22:15:16Z")

</div>

Hello there,

I am trying to configure **Elasticsearch 8.5** to support both TLSv1.3 AND TLSv1.2 communication, but following all documentation available, but it still supports TLSv1.3 only.  
I did the basic setup following this `[Security Basic Setup](https://www.elastic.co/guide/en/elasticsearch/reference/8.5/security-basic-setup-https.html)`  
In the elasticsearch I added:

```auto
xpack.security.http.ssl:
  enabled: true
  keystore.path: certs/elasticsearch/http.p12
  truststore.path: certs/elasticsearch/http.p12
  supported_protocols: ["TLSv1.3", "TLSv1.2"]
  cipher_suites: ["TLS_AES_256_GCM_SHA384",
                  "TLS_AES_128_GCM_SHA256",
                  "TLS_CHACHA20_POLY1305_SHA256",
                  "ECDHE-ECDSA-AES128-GCM-SHA256",
                  "ECDHE-RSA-AES128-GCM-SHA256",
                  "ECDHE-ECDSA-AES256-GCM-SHA384",
                  "ECDHE-RSA-AES256-GCM-SHA384",
                  "ECDHE-ECDSA-CHACHA20-POLY1305",
                  "ECDHE-RSA-CHACHA20-POLY1305",
                  "DHE-RSA-AES128-GCM-SHA256",
                  "DHE-RSA-AES256-GCM-SHA384"]

xpack.security.transport.ssl:
  enabled: true
  verification_mode: certificate
  client_authentication: required
  keystore.path: certs/elastic-certificates.p12
  truststore.path: certs/elastic-certificates.p12
  supported_protocols: ["TLSv1.3", "TLSv1.2"]
  cipher_suites: ["TLS_AES_256_GCM_SHA384",
                  "TLS_AES_128_GCM_SHA256",
                  "TLS_CHACHA20_POLY1305_SHA256",
                  "ECDHE-ECDSA-AES128-GCM-SHA256",
                  "ECDHE-RSA-AES128-GCM-SHA256",
                  "ECDHE-ECDSA-AES256-GCM-SHA384",
                  "ECDHE-RSA-AES256-GCM-SHA384",
                  "ECDHE-ECDSA-CHACHA20-POLY1305",
                  "ECDHE-RSA-CHACHA20-POLY1305",
                  "DHE-RSA-AES128-GCM-SHA256",
                  "DHE-RSA-AES256-GCM-SHA384"]

```

As I read in `[this JDK TLS versions documentation](https://www.elastic.co/guide/en/elasticsearch/reference/8.5/jdk-tls-versions.html#jdk-enable-tls-protocol)`, I also added to Java options:  
-Djdk.tls.client.protocols=TLSv1.3,TLSv1.2  
-Dhttps.protocols=TLSv1.3,TLSv1.2  
-Dcrypto.policy=unlimited (it seems to be default, but there is another error message on the beginning that states: _unsupported ciphers [[...]] were requested but cannot be used in this JVM, however there are supported ciphers that will be used [[...]]. If you are trying to use ciphers with a key length greater than 128 bits on an Oracle JVM, you will need to install the unlimited strength JCE policy files_, which leads me to try reinforce this setting, although I believe that is a misleading message since JCE policy files are all configured to unlimited strength in this version, but this issue is not a blocker for now... let's go back to the subject 😅)  
These options were added to $ELASTICSEARCH\_INSTALLATION\_PATH/jdk/conf/security/es.java.security and then $ELASTICSEARCH\_INSTALLATION\_PATH/config/jvm.options.d/java.security.options file was created with an entry:

```auto
-Djava.security.properties=......../jdk/conf/security/es.java.security

```

I can see that Elasticsearch started with this option properly set by doing `ps -uf | grep "\-Djdk.tls.client.protocols"`  
but when I try to test a request with TLSv1.2

```auto
curl --user elastic \
     --cacert $ELASTICSEARCH_INSTALLATION_PATH/config/certs/client-ca.cer \
     --cert $ELASTICSEARCH_INSTALLATION_PATH/config/certs/client.cer \
     --key $ELASTICSEARCH_INSTALLATION_PATH/config/certs/client.key \
     --request GET "$ELASTICSEARCH_HOST:$ELASTICSEARCH_PORT" \
     --verbose \
     --ciphers DHE-RSA-AES128-GCM-SHA256,DHE-RSA-AES256-GCM-SHA384,ECDHE-ECDSA-AES128-GCM-SHA256,ECDHE-ECDSA-AES256-GCM-SHA384,ECDHE-ECDSA-CHACHA20-POLY1305,ECDHE-RSA-AES128-GCM-SHA256,ECDHE-RSA-AES256-GCM-SHA384,ECDHE-RSA-CHACHA20-POLY1305,TLS_AES_128_GCM_SHA256,TLS_AES_256_GCM_SHA384,TLS_CHACHA20_POLY1305_SHA256,TLS_AES_128_CCM_8_SHA256,TLS_AES_128_CCM_SHA256 \
     --tlsv1.2 --tls-max 1.2

```

It just throw an exception:

```auto
[2023-03-22T21:10:29,633][WARN][o.e.h.AbstractHttpServerTransport] [eb-elk-node-1] caught exception while handling client http traffic, closing connection Netty4HttpChannel{localAddress=/10.117.159.100:9200, remoteAddress=/10.117.159.100:59596}io.netty.handler.codec.DecoderException: javax.net.ssl.SSLHandshakeException: Client requested protocol TLSv1.2 is not enabled or supported in server context
        at io.netty.codec@4.1.77.Final/io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:480)
        at io.netty.codec@4.1.77.Final/io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:279)
        at io.netty.transport@4.1.77.Final/io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
        at io.netty.transport@4.1.77.Final/io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
        at io.netty.transport@4.1.77.Final/io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)

See logs for more details.

```

There is no additional relevant information in the logs. So I tried again, but this time added the parameters directly:

```auto
echo "-Djdk.tls.client.protocols=TLSv1.3,TLSv1.2
-Dhttps.protocols=TLSv1.3,TLSv1.2
-Dcrypto.policy=unlimited
" > $ELASTICSEARCH_INSTALLATION_PATH/config/jvm.options.d/java.security.options

```

I also can see that Elasticsearch started with all these options, but when I try to execute the same curl test, I got the same exception "_javax.net.ssl.SSLHandshakeException: Client requested protocol TLSv1.2 is not enabled or supported in server context...._"  
Does anyone knows how to configure the Elasticsearch and/or its bundled JDK properly to support TLSv1.2 ?

---

<div class="post-metadata">

**Author:** ![Yang\_Wang](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/yang_wang/32/48857_2.png) [@Yang\_Wang](https://discuss.elastic.co/u/Yang_Wang)\
**Post date:** [March 24, 2023, 3:52am UTC](https://discuss.elastic.co/t/elasticsearch-throws-a-sslhandshakeexception-client-requested-protocol-tlsv1-2-is-not-enabled-or-supported-in-server-context/328294/2 "2023-03-24T03:52:17Z")

</div>

Are you using the bundled JDK? TLSv1.2 should be supported by default.

BTW, java security policy configuraiton is not through system properties, .e.g. `-Dcrypto.policy=unlimited` does not work. But that should be irrelevant for your problem because TLSv1.2 should be supported out of the box if you are using bundled JDK.

---

<div class="post-metadata">

**Author:** ![wlktiago70](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/wlktiago70/32/118791_2.png) [@wlktiago70](https://discuss.elastic.co/u/wlktiago70)\
**Post date:** [March 24, 2023, 12:18pm UTC](https://discuss.elastic.co/t/elasticsearch-throws-a-sslhandshakeexception-client-requested-protocol-tlsv1-2-is-not-enabled-or-supported-in-server-context/328294/3 "2023-03-24T12:18:31Z")

</div>

The documentation also states that. The point is when I force TLSv1.2 using this curl command:

```auto
curl --user elastic \
     --cacert $ELASTICSEARCH_INSTALLATION_PATH/config/certs/client-ca.cer \
     --cert $ELASTICSEARCH_INSTALLATION_PATH/config/certs/client.cer \
     --key $ELASTICSEARCH_INSTALLATION_PATH/config/certs/client.key \
     --request GET "$ELASTICSEARCH_HOST:$ELASTICSEARCH_PORT" \
     --verbose \
     --ciphers DHE-RSA-AES128-GCM-SHA256,DHE-RSA-AES256-GCM-SHA384,ECDHE-ECDSA-AES128-GCM-SHA256,ECDHE-ECDSA-AES256-GCM-SHA384,ECDHE-ECDSA-CHACHA20-POLY1305,ECDHE-RSA-AES128-GCM-SHA256,ECDHE-RSA-AES256-GCM-SHA384,ECDHE-RSA-CHACHA20-POLY1305,TLS_AES_128_GCM_SHA256,TLS_AES_256_GCM_SHA384,TLS_CHACHA20_POLY1305_SHA256,TLS_AES_128_CCM_8_SHA256,TLS_AES_128_CCM_SHA256 \
     --tlsv1.2 --tls-max 1.2

```

Elasticsearch simply throws an error saying that TLSv1.2 is not supported:

```auto
[2023-03-22T21:10:29,633][WARN][o.e.h.AbstractHttpServerTransport] [eb-elk-node-1] caught exception while handling client http traffic, closing connection Netty4HttpChannel{localAddress=/10.117.159.100:9200, remoteAddress=/10.117.159.100:59596}io.netty.handler.codec.DecoderException: javax.net.ssl.SSLHandshakeException: Client requested protocol TLSv1.2 is not enabled or supported in server context
        at io.netty.codec@4.1.77.Final/io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:480)
        at io.netty.codec@4.1.77.Final/io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:279)
        at io.netty.transport@4.1.77.Final/io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
        at io.netty.transport@4.1.77.Final/io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
        at io.netty.transport@4.1.77.Final/io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)

See logs for more details.

```

Is there any missing configuration in my elasticsearch.yml? The changes I made are basically those I put above.

---

<div class="post-metadata">

**Author:** ![wlktiago70](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/wlktiago70/32/118791_2.png) [@wlktiago70](https://discuss.elastic.co/u/wlktiago70)\
**Post date:** [March 24, 2023, 12:27pm UTC](https://discuss.elastic.co/t/elasticsearch-throws-a-sslhandshakeexception-client-requested-protocol-tlsv1-2-is-not-enabled-or-supported-in-server-context/328294/4 "2023-03-24T12:27:11Z")

</div>

> [@wlktiago70](#):
>
> `supported_protocols: ["TLSv1.3", "TLSv1.2"]`

Even though both TLS versions are set as supported protocols, Elasticsearch still starts with TLSv1.3 as we can understand from this misleading error message:

```auto
[2023-03-24T13:08:21,639][ERROR][o.e.x.c.s.SSLService] [eb-elk-node-1] unsupported ciphers [[ECDHE-ECDSA-AES128-GCM-SHA256, ECDHE-RSA-AES128-GCM-SHA256, ECDHE-ECDSA-AES256-GCM-SHA384, ECDHE-RSA-AES256-GCM-SHA384, ECDHE-ECDSA-CHACHA20-POLY1305, ECDHE-RSA-CHACHA20-POLY1305, DHE-RSA-AES128-GCM-SHA256, DHE-RSA-AES256-GCM-SHA384]] were requested but cannot be used in this JVM, however there are supported ciphers that will be used [[TLS_AES_256_GCM_SHA384, TLS_AES_128_GCM_SHA256, TLS_CHACHA20_POLY1305_SHA256]]. If you are trying to use ciphers with a key length greater than 128 bits on an Oracle JVM, you will need to install the unlimited strength JCE policy files.

```

---

<div class="post-metadata">

**Author:** ![wlktiago70](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/wlktiago70/32/118791_2.png) [@wlktiago70](https://discuss.elastic.co/u/wlktiago70)\
**Post date:** [March 24, 2023, 1:17pm UTC](https://discuss.elastic.co/t/elasticsearch-throws-a-sslhandshakeexception-client-requested-protocol-tlsv1-2-is-not-enabled-or-supported-in-server-context/328294/5 "2023-03-24T13:17:43Z")

</div>

And yes, I am using the bundled JDK, there is no environment variable changing it.  
 ![image](https://us1.discourse-cdn.com/elastic/original/3X/b/8/b8290465e245f152764c7afb6a888850583fd510.png)

---

<div class="post-metadata">

**Author:** ![Yang\_Wang](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/yang_wang/32/48857_2.png) [@Yang\_Wang](https://discuss.elastic.co/u/Yang_Wang)\
**Post date:** [March 28, 2023, 1:48am UTC](https://discuss.elastic.co/t/elasticsearch-throws-a-sslhandshakeexception-client-requested-protocol-tlsv1-2-is-not-enabled-or-supported-in-server-context/328294/6 "2023-03-28T01:48:07Z")

</div>

> [@wlktiago70](#):
>
> And yes, I am using the bundled JDK, there is no environment variable changing it.

You need look into elasticsearch log to be sure. At node launch time, ES will log information about the JDK it is using. Please make sure it says something like `... using bundled JDK [true]`.

---

<div class="post-metadata">

**Author:** ![wlktiago70](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/wlktiago70/32/118791_2.png) [@wlktiago70](https://discuss.elastic.co/u/wlktiago70)\
**Post date:** [March 28, 2023, 5:44pm UTC](https://discuss.elastic.co/t/elasticsearch-throws-a-sslhandshakeexception-client-requested-protocol-tlsv1-2-is-not-enabled-or-supported-in-server-context/328294/7 "2023-03-28T17:44:21Z")

</div>

![image](https://us1.discourse-cdn.com/elastic/original/3X/b/0/b099e82b949cf5e20e93591b0669325a4dd25758.png)

Ok, I am definitely using bundled JDK 👆

---

<div class="post-metadata">

**Author:** ![wlktiago70](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/wlktiago70/32/118791_2.png) [@wlktiago70](https://discuss.elastic.co/u/wlktiago70)\
**Post date:** [March 28, 2023, 5:51pm UTC](https://discuss.elastic.co/t/elasticsearch-throws-a-sslhandshakeexception-client-requested-protocol-tlsv1-2-is-not-enabled-or-supported-in-server-context/328294/8 "2023-03-28T17:51:53Z")

</div>

Since no where else were changed, do you have any idea of why this error is thrown when we try to use TLSv1.2?

---

<div class="post-metadata">

**Author:** ![Yang\_Wang](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/yang_wang/32/48857_2.png) [@Yang\_Wang](https://discuss.elastic.co/u/Yang_Wang)\
**Post date:** [March 29, 2023, 12:50am UTC](https://discuss.elastic.co/t/elasticsearch-throws-a-sslhandshakeexception-client-requested-protocol-tlsv1-2-is-not-enabled-or-supported-in-server-context/328294/9 "2023-03-29T00:50:06Z")

</div>

OK thanks for checking. It turns out that the cipher suites you configured is _not_ compatible with TLSv1.2. In fact, most of them are _not_ recognisable by JVM. You should see a logging line like the follows in your server log

> unsupported ciphers [[ECDHE-ECDSA-AES128-GCM-SHA256, ECDHE-RSA-AES128-GCM-SHA256, ECDHE-ECDSA-AES256-GCM-SHA384, ECDHE-RSA-AES256-GCM-SHA384, ECDHE-ECDSA-CHACHA20-POLY1305, ECDHE-RSA-CHACHA20-POLY1305, DHE-RSA-AES128-GCM-SHA256, DHE-RSA-AES256-GCM-SHA384]] were requested but cannot be used in this JVM, however there are supported ciphers that will be used [[TLS\_AES\_256\_GCM\_SHA384, TLS\_AES\_128\_GCM\_SHA256, TLS\_CHACHA20\_POLY1305\_SHA256]]. If you are trying to use ciphers with a key length greater than 128 bits on an Oracle JVM, you will need to install the unlimited strength JCE policy files.

You should check the [jdk doc](https://docs.oracle.com/en/java/javase/11/docs/specs/security/standard-names.html#jsse-cipher-suite-names) for the correct cipher suite names. The ones that are usable (from the above logging line) are all for TLSv1.3. That's why the connection using TLSv1.2 is failing. For it to work, you need add a supported cipher suite. For example, if you have `TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384` in the cipher suites, you will be able to make connection with TLSv1.2 using the following curl command

```auto
curl -v -k --tlsv1.2 --tls-max 1.2 --ciphers ECDHE-RSA-AES256-GCM-SHA384 https://ES_HOST:9200

```

NOTE curl requires cipher suites to be [separated with colon](https://curl.se/docs/ssl-ciphers.html) (`:`) instead of comma (`,`).

---

<div class="post-metadata">

**Author:** ![wlktiago70](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/wlktiago70/32/118791_2.png) [@wlktiago70](https://discuss.elastic.co/u/wlktiago70)\
**Post date:** [March 29, 2023, 1:09pm UTC](https://discuss.elastic.co/t/elasticsearch-throws-a-sslhandshakeexception-client-requested-protocol-tlsv1-2-is-not-enabled-or-supported-in-server-context/328294/10 "2023-03-29T13:09:51Z")

</div>

Thank you for the help @Yang_Wang ! Now it is working.  
The problem was that cipher suite list I configured in `elasticsearch.yml` was using OpenSSL naming, after changing to IANA naming based on [this correspondence table](https://wiki.mozilla.org/Security/Cipher_Suites), it worked. Thank you very much!  
**NOTE** my curl command is actually correct, it does accept both colon (`:`) and comma (`,`).

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [April 26, 2023, 1:10pm UTC](https://discuss.elastic.co/t/elasticsearch-throws-a-sslhandshakeexception-client-requested-protocol-tlsv1-2-is-not-enabled-or-supported-in-server-context/328294/11 "2023-04-26T13:10:01Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.
