Let's encrypt

Elastic Stack Elasticsearch
1

i have it working with kibana but cant seem to get it to work with my elastic cluster. I succesfuly mounted the share to my wildcard cert and I symlinked the privetkey.pem and fullchain .pem. i used

xpack.security.http.ssl:
  enabled: true
  key: name\of\pem
  certificate: name\of\pem

when I start the node with the new config the node would not join the cluster so i reverted back to using the keystore.path. I was doing this via a rolling restart. currently I am using the same cert for both trasport.ssl and http.ssl.

I have a few questions.

  1. Is the rolling restart the issue?
  2. do i need to remove the xpack.security.http.ssl.keystore.secure_password with the bin/elasticsearch-keystore comand?
  3. Would that cause problems for the transport.ssl keystore?

i noticed that I was getting the following erros for mulitple ports.

caught exception while handling client http traffic, closing connection Netty4HttpChannel{l

Received fatal alert: bad_certificate
	at io.netty.codec

I am not sure why elastic is trying to communicate those ports. is there a way to figure out why it is?

2

You should not do that.
The trust chain for transport.ssl is what controls which nodes are permitted to join your cluster. If you configure it to use a public CA then you make it possible for outside nodes to join your cluster. You should use a dedicated CA for your cluster.

This is almost certainly due to trying to switch the transport SSL configuration on a running cluster. That's possible to do, but you need to follow precise steps.

If you just try to configure http.ssl nodes should be fine to join the cluster.

It sounds like you have clients that are trying to connect to your cluster, but are not configured to trust the let's encrypt CA. You will need to work out what those clients are - the log should include IP addresses that can help you
track them down.

1 Like
3

you are right. the http.ssl is different than the transport.ssl.
but they where both in the keystore. I made no changes to the transport.ssl sorry for the confusion. they all still have the same transport.ssl they only differences was that one had the let encrypt cert for the http

It sounds like you have clients that are trying to connect to your cluster, but are not configured to trust the let's encrypt CA. You will need to work out what those clients are - the log should include IP addresses that can help you
track them down.

it all going to the fleetserver