Unable to create an enrollment token for Kibana. "Elasticsearch node HTTP layer SSL configuration Keystore doesn't contain any PrivateKey entries where the associated certificate is a CA certificate"

Elastic Stack Elasticsearch
1

Hello,

I tried today to setup my ELK stack securely so I followed the documentation and created all certs that I need using the certutil and encrypted the CA and the node cert with passwords.
I placed the http.p12 file to /etc/Elasticsearch/certs/ Elasticsearch.
Then I updated the keystone as told in the README:

 elasticsearch-keystore add "xpack.security.http.ssl.keystore.secure_password"

and typed my node's p12 password here.

Now I wanted to add Kibana from another server so I tried to create the enrollment token but it failed:

elasticsearch-create-enrollment-token -s kibana
ERROR: Unable to create an enrollment token for Kibana. Elasticsearch node HTTP layer SSL configuration Keystore doesn't contain any PrivateKey entries where the associated certificate is a CA certificate

I am a bit confused. Why isn't the PrivateKey there? And what exactly does it mean that there is no associated CA certificate? Do I need to place the ca.p12 somewhere too? If yes then where? And with which command do I type the PrivateKey for that?
Or did I make another mistake somewhere else?

I would really appreciate any help.

Edit: I am on Elasticsearch 8.0 on a newly installed Ubuntu VM

2

The Kibana enrollment process relies on the configuration that is produced by the auto-generated security (TLS) setup that is included in Elasticsearch 8.0

It is possible to manually configure TLS in a way that meets the requirements for Kibana enrollment, but I don't think we have explicit documentation on how to do that - the design and intent is that it all flows through the automated setup process.

I think this can probably be classed as a bug (or at least a rough edge on the feature).
Kibana enrollment shouldn't require the CA private key. Node enrollment does, and I suspect we're applying the same validation regardless of the type on token being generated.

1 Like
3

Hey thanks for the fast response.
The actual reason why I made all this certificates on my own is because I got the following response trying to access the API via https:

curl --cacert /Users/martin/Downloads/http_ca.crt -u elastic https://10.24.1.5:9200

Enter host password for user 'elastic':

curl: (60) SSL: no alternative certificate subject name matches target host name '10.24.1.5'

More details here: https://curl.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

It seems like the default cert generated does not add the IP/Domain to the Subject-Name field. It only worked if I tried via https://localhost:9200

What are the steps for me to use TLS now? Can I re-do the auto generated security setup with the right Subject-Names? Or am I forced to just access the API vial localhost?

4

We do our best to detect all IP addresses of the interfaces that are up when elasticsearch is installed and then use them as IP Subject Alternative Names in the HTTP TLS certificate. How is the networking configured for your VM ? Is 10.24.1.5 an IP address that the VM itself is aware of or are you using NAT ?

If you still have these around, you can take a look at what IP addresses we found out by inspecting the certificate. (I'm assuming you have installed this with the DEB package, so the following commands apply to that )

# /usr/share/elasticsearch/bin/elasticsearch-keystore show xpack.security.http.ssl.keystore.secure_password

will show you the password for the http.p12 keystore. Then you can run

keytool -keystore /etc/elasticsearch/config/certs/http.p12 -storepass <password_you_got_above> -list -v

and look at the section that starts with Alias name: http.

As to what you can do now, you can either:

  • Reinstall elasticsearch and use an IP address/hostname to access it that exists in the SANs of the certificate. Use the enrollment process as described in to configure Kibana

or

We will track this and see if it makes sense to allow creating kibana enrollment tokens with manual/custom TLS setups and/or enhance the error message to make it clearer why it fails. Thanks for reporting this @maof97 !

2 Likes
5

Yeah because of restrictions I have to install ES using a different interface than the one used in production. Maybe add a feature to specify the production IP address on installation for cases like mine.

6

Creating this due apt-get install is bad idea. I need do build on dev enviroment, I can't install ELK on prod... after moving I just edit network stuff and should work, but it don't as ELK hardcode IPs etc :frowning:

1 Like
7

Apologies but it’s not clear from you comment what your problem is. Please don’t hijack other topics, open a new one and explain in detail what your issue is. We will do our best to help you out

8

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