S_s_l_handshake_exception in kibana while using reindex api

I moved this to the Elasticsearch forum.

The issue you're running into seems to be that you generated your own custom SSL certificates for the node at "elastic-search-1" with a custom CA.
That's often the right thing to do, but unfortunately reindex with custom SSL certificates is messy. We're planning a fix but there's no ETA yet.

Your 2nd cluster doesn't automatically trust that custom CA (even if its using the same CA), so it cannot establish a trusted SSL (https) connection to cluster-1.

To overcome things, you need to do one of the following:

  1. Turn off SSL for the "http" interface on cluster 1. That's probably not a great option for a production cluster, but if you're just trying things out, it's an easy path to getting reindex working for now.
  2. Add your custom CA certificate (from "elastic-search-1") to the JVM's "cacerts" for cluster 2.
  3. Create a completely new truststore, combing your CA certificate (from "elastic-search-1") and the JVM's existing "cacerts", and configure that as the truststore for cluster 2.

Option 1 is easiest, but not a real long term option.
Option 2 is pretty easy, but it does mean making changes to the JVM install for the whole Centos server so every java process will trust your custom CA. Often that's a perfectly fine thing to do, but occasionally it's not what you want.
Option 3 is a fair bit more work. If you really want to go with that, then let us know and I'll write up some steps for it.

Assuming you want option 2:
If you have trouble finding your CA certificate, then we can help you, but we'll need to see your config file for "elastic-search-1".

The Microsoft Azure docs provides a useful guide for adding a CA to the JVM's truststore.
In their example they're adding the "Baltimore Cybertrust" CA, and you'll want to use your own CA.

1 Like