SSL inter-node interoperability between ROR node and existing xpack.security cluster

Users Feedback
1

I have a big problem with connecting readonlyrest to the elasticsearch cluster.
At the moment I have a 4 node cluster and I would like to connect one additional node as readonlyrest.
I have tls enabled in my cluster (xpack.security.transport.ssl.enabled) and when I try to connect an additional readonlyrest node to it I always get the error:

[2021-07-07T14:27:52,254][WARN ][o.e.t.TcpTransport       ] [elk5-ror] exception caught on transport layer [Netty4TcpChannel{localAddress=0.0.0.0/0.0.0.0:51460, remoteAddress=null}], closing connection
io.netty.handler.codec.DecoderException: javax.net.ssl.SSLHandshakeException: Received fatal alert: bad_certificate

I generate the certificate as p12 from my main node:
bin / elasticsearch-certutil cert --ca elastic-stack-ca.p12
and then keytool imports it:
keytool -importkeystore -deststorepass pass -destkeypass pass -destkeystore shield.jks -srckeystore elk-ror.p12 -srcstoretype PKCS12 -srcalias instance
On ror node of course i have disable xpack and enable transport.type: ror_ssl_internode. My readonlyrest.yml:

 readonlyrest:
     ssl_internode:
       keystore_file: "shield.jks"
       keystore_pass: pass
       key_pass: pass
     access_control_rules:
     - name: "Require HTTP Basic Auth"
       type: allow
       auth_key: elastic:pass

But unfortunately it doesn’t work. Is there any procedure how to add new ror node to exist cluster?

2

How do you configure this certificate in the existing working node?

3

It is rather a standard configuration:

xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: none
xpack.security.transport.ssl.keystore.path: certs/elastic-certificates.p12
xpack.security.transport.ssl.truststore.path: certs/elastic-certificates.p12

4

I also tried the configuration with

xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: none
xpack.security.transport.ssl.key: /etc/elasticsearch/config/certs/elk1.key
xpack.security.transport.ssl.certificate: /etc/elasticsearch/config/certs/elk1.crt
xpack.security.transport.ssl.certificate_authorities: [ “/etc/elasticsearch/config/certs/ca.crt” ]

But in each case there was the same error => Received fatal alert: bad_certificate, on ror node.

5

Hi @mix091 yesterday we added your request for support to our internal task management system.
Because I’d like to bump up priority to this task, I would need to know if you are an active ReadonlyREST PRO/Enterprise user already, or are you evaluating to adopt one of these solutions.

6

We have just added internode SSL compatibility between ROR nodes and XPack nodes. If you want to test it, please give me a hint about the ES version you use - I’ll send you a pre-build.

The feature will be available starting from ROR 1.36.0.

1 Like
7

Hi all what is working configuration. We have same issue with ROR 1.38.
Thanks

R

8

@rjan have you read the paragraph we wrote about internode SSL configuration especially for configuring an Elasticsearch node with ReadonlyREST plugin so it can join an existing Elasticsearch cluster with Xpack security SSL enabled using Elastic’s SSL certificate?

It’s in the official docs, look where where it says “Internode communication with XPack nodes”. There’s also an example of configuration.

9

Hi Simone
ofcourse I did.
We setup xpack cluster with selfsigned cert for transport. Cluster with 2 data,master nodes 1 client.
All works.
We added ROR client node but we are getting still exceptions during discovery
From ROR to master master logs
javax.net.ssl.SSLHandshakeException: Empty client certificate chain
From Xpack > ROR node
javax.net.ssl.SSLHandshakeException: Received fatal alert: bad_certificate

We tried all possible formats in ROR internode SSL and we are not succesful

10

Problem was that by default in xpack has
xpack.security.transport.ssl.client_authentication : required
and
by default ROR internode
has
By default the client authentication is disabled.
client_authentication: true

It seems that internode comm is working now…

R

1 Like