# SSL between elastic nodes is failing **URL:** \ **Category:** Elasticsearch\ **Created:** [July 5, 2017, 2:28pm UTC](https://discuss.elastic.co/t/ssl-between-elastic-nodes-is-failing/91925 "2017-07-05T14:28:39Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![ravichoudhary](https://avatars.discourse-cdn.com/v4/letter/r/a698b9/32.png) [@ravichoudhary](https://discuss.elastic.co/u/ravichoudhary)\ **Post date:** [July 5, 2017, 2:28pm UTC](https://discuss.elastic.co/t/ssl-between-elastic-nodes-is-failing/91925/1 "2017-07-05T14:28:39Z")
We have created a 6 node elastic 5.4 cluster with 3 master and 3 data nodes. We are using our org signed CA certificate to implement the TLS/SSL between nodes but it is giving error as "Caused by: sun.security.validator.ValidatorException: Extended key usage does not permit use for TLS client authentication" The TLS/SSL is working correctly with self signed certs generated using the certgen tool. and we have used same certgen tool to generate the csr for CA cert. Please find below the full stack track io.netty.handler.codec.DecoderException: javax.net.ssl.SSLHandshakeException: General SSLEngine problem at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:442) ~[netty-codec-4.1.9.Final.jar:4.1.9.Final] at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:248) ~[netty-codec-4.1.9.Final.jar:4.1.9.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362) [netty-transport-4.1.9.Final.jar:4.1.9.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348) [netty-transport-4.1.9.Final.jar:4.1.9.Final] at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340) [netty-transport-4.1.9.Final.jar:4.1.9.Final] at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1334) [netty-transport-4.1.9.Final.jar:4.1.9.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362) [netty-transport-4.1.9.Final.jar:4.1.9.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348) [netty-transport-4.1.9.Final.jar:4.1.9.Final] at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:926) [netty-transport-4.1.9.Final.jar:4.1.9.Final] at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:134) [netty-transport-4.1.9.Final.jar:4.1.9.Final] at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:624) [netty-transport-4.1.9.Final.jar:4.1.9.Final] at io.netty.channel.nio.NioEventLoop.processSelectedKeysPlain(NioEventLoop.java:524) [netty-transport-4.1.9.Final.jar:4.1.9.Final] at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:478) [netty-transport-4.1.9.Final.jar:4.1.9.Final] at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:438) [netty-transport-4.1.9.Final.jar:4.1.9.Final] at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:858) [netty-common-4.1.9.Final.jar:4.1.9.Final] at java.lang.Thread.run(Thread.java:748) [?:1.8.0\_131] Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine problem at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1478) ~[?:?] at sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:535) ~[?:?] at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:813) ~[?:?] at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:781) ~[?:?] at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624) ~[?:1.8.0\_131] at io.netty.handler.ssl.SslHandler$SslEngineType$2.unwrap(SslHandler.java:222) ~[?:?] at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1119) ~[?:?] at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1041) ~[?:?] at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:411) ~[?:?] ... 15 more Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine problem at sun.security.ssl.Alerts.getSSLException(Alerts.java:192) ~[?:?] at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1728) ~[?:?] at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:304) ~[?:?] at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:296) ~[?:?] at sun.security.ssl.ServerHandshaker.clientCertificate(ServerHandshaker.java:1906) ~[?:?] at sun.security.ssl.ServerHandshaker.processMessage(ServerHandshaker.java:233) ~[?:?] at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1026) ~[?:?] at sun.security.ssl.Handshaker$1.run(Handshaker.java:966) ~[?:?] at sun.security.ssl.Handshaker$1.run(Handshaker.java:963) ~[?:?] at java.security.AccessController.doPrivileged(Native Method) ~[?:1.8.0\_131] at sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1416) ~[?:?] at io.netty.handler.ssl.SslHandler.runDelegatedTasks(SslHandler.java:1268) ~[?:?] at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1176) ~[?:?] at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1041) ~[?:?] at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:411) ~[?:?] ... 15 more Caused by: sun.security.validator.ValidatorException: Extended key usage does not permit use for TLS client authentication at sun.security.validator.EndEntityChecker.checkTLSClient(EndEntityChecker.java:233) ~[?:?] at sun.security.validator.EndEntityChecker.check(EndEntityChecker.java:143) ~[?:?] at sun.security.validator.Validator.validate(Validator.java:264) ~[?:?] at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324) ~[?:?] at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:279) ~[?:?] at sun.security.ssl.X509TrustManagerImpl.checkClientTrusted(X509TrustManagerImpl.java:130) ~[?:?] at org.elasticsearch.xpack.ssl.SSLService$ReloadableTrustManager.checkClientTrusted(SSLService.java:532) ~[?:?] at sun.security.ssl.ServerHandshaker.clientCertificate(ServerHandshaker.java:1893) ~[?:?] at sun.security.ssl.ServerHandshaker.processMessage(ServerHandshaker.java:233) ~[?:?] at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1026) ~[?:?] at sun.security.ssl.Handshaker$1.run(Handshaker.java:966) ~[?:?] at sun.security.ssl.Handshaker$1.run(Handshaker.java:963) ~[?:?] at java.security.AccessController.doPrivileged(Native Method) ~[?:1.8.0\_131] at sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1416) ~[?:?] at io.netty.handler.ssl.SslHandler.runDelegatedTasks(SslHandler.java:1268) ~[?:?] at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1176) ~[?:?] at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1041) ~[?:?] at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:411) ~[?:?] ... 15 more ---
**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:** [July 6, 2017, 4:03am UTC](https://discuss.elastic.co/t/ssl-between-elastic-nodes-is-failing/91925/2 "2017-07-06T04:03:43Z")
You are running into this issue from the [Setting up SSL/TLS](https://www.elastic.co/guide/en/x-pack/5.4/ssl-tls.html#installing-node-certificates) documentation: > If you choose not to use the certgen, the certificates that you obtain must allow for both clientAuth and serverAuth if the extended key usage extension is present. SSL certificates _can_ be marked (but don't have to be) as allowing either "client authentication" or "server authentication" or both. Because there is no strict notion of "client" or "server" in a cluster (all nodes act as both a client and a server) your certificate must either be marked as having _both_ `clientAuth` and `serverAuth` _extended key usage_, or not have that extension included at all. You'll need to generate new certificates. ---
**Author:** ![ravichoudhary](https://avatars.discourse-cdn.com/v4/letter/r/a698b9/32.png) [@ravichoudhary](https://discuss.elastic.co/u/ravichoudhary)\ **Post date:** [July 6, 2017, 5:48am UTC](https://discuss.elastic.co/t/ssl-between-elastic-nodes-is-failing/91925/3 "2017-07-06T05:48:07Z")
Thanks for the information. We have used certgen tool to create csr then the certificates are signed by our organization. Does the certgen tool has some option to specify extended key usage while creating csr or we need to take care of extended key usage while signing csr and creating certificate? ---
**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:** [July 6, 2017, 7:12am UTC](https://discuss.elastic.co/t/ssl-between-elastic-nodes-is-failing/91925/4 "2017-07-06T07:12:56Z")
> [@](#): > > Does the certgen tool has some option to specify extended key usage while creating csr No, certgen does not populate the "X509v3 Extended Key Usage" extension in the CSR. It must be being added by your internal CA. > [@](#): > > we need to take care of extended key usage while signing csr and creating certificate? More specifically the CA just needs to _not do anything_. The simplest path is not to specify a key usage extension. certgen doesn't populate it, and (for Elasticsearch node certificates), your CA shouldn't either. Your CA has made the choice (perhaps unintentionally) to fill in the extended key usage extension with "serverAuth", they can either put both "serverAuth" and "clientAuth" in there, or take the simpler option and not fill in that extension at all. ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [August 3, 2017, 7:13am UTC](https://discuss.elastic.co/t/ssl-between-elastic-nodes-is-failing/91925/5 "2017-08-03T07:13:23Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.