Unable to run set-password in 6.1

(intrepid1) #1

Hi there,

I am setting up TLS on 6.1 and am having problems running set-password.

I configure ES as follows:

rm -rf elasticsearch-6.1.2
unzip elasticsearch-6.1.2.zip
cp elasticsearch.yml /config

./bin/elasticsearch-plugin install file:///./x-pack-6.1.2.zip

cd ./elasticsearch-6.1.2/config

/elasticsearch-6.1.2/bin/x-pack/certutil ca -pass '' -out elastic-stack-ca.p12
/elasticsearch-6.1.2/bin/x-pack/certutil cert ca -pass '' elastic-stack-ca.p12 -out elastic-certificates.p12

The docs say

"By default certutil generates certificates that have no hostname information in them (that is, they do not have any Subject Alternative Name fields). This means that you can use the certificate for every node in your cluster, but you must turn off hostname verification as shown in the configuration below."

This is what I want as it is all going to run on AWS using Terraform/Packer and when I launch an instance, I want the node to have a certificate that can be run on any node.

However when I run set-up password, I receive the following error.

My x-pack settings are

xpack.monitoring.enabled : true
xpack.security.enabled : true
xpack.graph.enabled : false
xpack.ml.enabled : false

bootstrap.system_call_filter : false

xpack.ssl.keystore.path: ./elastic/elasticsearch-6.1.2/config/elastic-certificates.p12
xpack.ssl.truststore.path: ./elastic/elasticsearch-6.1.2/config/elastic-certificates.p12

xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: certificate

xpack.security.http.ssl.enabled: true

SSL connection to https://x.x.x.x:9200/_xpack/security/_authenticate?pretty failed: java.security.cert .CertificateException: No subject alternative names present
Please check the elasticsearch SSL settings under xpack.security.http.ssl.

However I specifically don't want to use a SAN for the reason stated above.

Am I doing anything wrong? What can I do to reolve the issues.


(Tim Vernum) #2

The solution to this problem is covered in the troubleshooting guide.

See point 3 here:

(intrepid1) #3

Thank you for your reply.

It is now working. I had already read the link you said but

"If hostname verification fails, you can disable this verification by setting xpack.security.http.ssl.verification_mode to certificate."

which is what is needed if you don't have a SAN.

However in end I set xpack.security.http.ssl.enabled: false previously it was true. This was set to true i.e following point one of the trouble shooting, because there were times when the set-password tried to use http.

I have set the passwords, but still not 100% sure why it is now working.

(intrepid1) #4

Actually this didn't work. I am certain that xpack.security.http.ssl.enabled: must be set to true and hence I am back to step one. More reading, undertanding and googling necessary.

(Tim Vernum) #5

What do you mean by this?
Certainly Elasticsearch / X-Pack does not require that you set it to true, but if you have a reason to require TLS on the HTTP interface, then, yes you need to enable that setting.

If you enable http.ssl, with a certificate that doesn't contain your node's hostname (or IP) then that will cause certificate verification problems for any client that connects to your cluster (including setup-passwords), unless you configure that client to disable hostname verification. For the setup-passwords tool, the way to disable hostname verification is described in the link I posted earlier.

(intrepid1) #6

I have it working now using SAN but it is quite a manual and static process. By this I mean that I needed to know all the IP addresses. How can I cater for new nodes joining. There IP addresses wouldn't be know until boot time and I am trying to work out how I can configure new nodes in an automated way.

(system) #7

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