SSL between elastic nodes is failing

Elastic Stack Elasticsearch
1

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

2

You are running into this issue from the Setting up SSL/TLS 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.

1 Like
3

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?

4

No, certgen does not populate the "X509v3 Extended Key Usage" extension in the CSR.
It must be being added by your internal CA.

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.

1 Like
5

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