SSLHandshakeException when enabling security

Elastic Stack Elasticsearch
1

Hi we have a working cluster but when we enable xpack security the transport communication fails.

Configuration:
bootstrap.memory_lock: true
cluster.initial_master_nodes:
- elk.mydomain.dk
- elk-02.mydomain.dk
- elk-03.mydomain.dk
cluster.name: elasticsearch-prod
discovery.seed_hosts:
- elk-02.mydomain.dk
- elk-03.mydomain.dk
http.port: 9200
network.host: elk.mydomain.dk
node.data: false
node.ingest: true
node.master: true
node.max_local_storage_nodes: 1
node.name: ELK
path.data: C:\tools\elasticsearch\data
path.logs: C:\tools\elasticsearch\logs
transport.tcp.port: 9300
xpack.license.self_generated.type: basic
xpack.security.enabled: true
xpack.security.http.ssl.enabled: true
xpack.security.http.ssl.keystore.path: certs\myssl.pfx
xpack.security.http.ssl.truststore.path: certs\myssl.pfx
xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: certificate
xpack.security.transport.ssl.keystore.path: certs/myssl.pfx
xpack.security.transport.ssl.truststore.path: certs/myssl.pfx

Communication to https...:9200 works fine - but https....:9300 fails with
javax.net.ssl.SSLHandshakeException: Received fatal alert: bad_certificate

What and why is communication different ? We have tried a lot of different solutions. Another funny thing is this "cluster_uuid" : "na" :-:thinking:

Version: Elastic 7.1.1

Best regards

Aage Nielsen
Openminds

2

You haven't given us much to go on but ...

Where did this myssl.pfx file come from?
Based on the fact that it's named "pfx" I suspect it was created by tooling in a microsoft/windows environment.
If so, then it is quite likely that it has the right data in it to act as a keystore, but not as a truststore.

The technical explanation is that a PKCS#12 file (your .pfx) is technically a key storage format. Java uses its "keystore" format to also store CAs, which it calls a "truststore", and it uses special PKCS#12 entries to do that.
It is rare for non-Java tooling to create those trust entries.

If that pfx was issued to you by a CA, then you probably want to get a copy of their CA cert in PEM format, and then replace the xpack.security.transport.ssl.truststore.path with

xpack.security.transport.ssl.certificate_authorities: [ "path/to/ca.pem" ]

And likewise for http.ssl

3

The PFX filen was delivered directly from the CA (DigiCert). The PKCS12/PFX file contains the entire chain including the CA cert. It just did not make (much) sense that communication with 9200 was ok and 9300 was not. We did the configuration exactly as stated in your documentation at

https://www.elastic.co/guide/en/elasticsearch/reference/current/configuring-tls.html

But anyhow - we exported the CA from the PFX file and applied

xpack.security.transport.ssl.certificate_authorities: certs/ca.cer

And still the same error :frowning:

4

That's not the issue. Using a PKCS#12 as a truststore requires additional entries. It will not automatically trust every issuer of every certificate that is stored as a key, it needs explicit entires for "trust this CA (chain)".

Oh. You're trying to connect to port 9300 using https. That won't work.

9200 is the http port.
9300 is the transport port. It is used for internal communications in a bespoke binary format , it cannot be used over https.

5

Hmmm the cluster nodes are still getting the same error when trying to communicate - bad certificate. As stated - we have followed the documentation. Now we have created a new standard jks keystore and change the elastic configuration - and a new error occurs -

Caused by: io.netty.handler.ssl.NotSslRecordException: not an SSL/TLS record

Any clue what that is ?

/aage

6

Wait wait - now the cluster is up and running :slight_smile:

So I guess it had something to do with - elastic not being able to figure out the pfx format for the 9300 communication but could with plain https at 9200.

Thanks for your help

Best regards
Aage

7

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