S_s_l_handshake_exception in kibana while using reindex api

Elastic Stack Elasticsearch
1

I have been using reindex api and trying to reindex data from remote cluster both of version 6.2.4 and I am running on centos and openjdk 1.8.0.161.
X Pack installed on both clusters with trial license.
When I am trying to use this command
POST _reindex

{
  "source": {
    "remote": {
      "host": "https://elastic-search-1:9200",
      "username": "elastic",
      "password": "dummypassword"
    },
    "index": "source",
    "query": {
      "match": {
        "test": "data"
      }
    }
  },
  "dest": {
    "index": "dest"
  }
}

I am getting
> {

      "error": {
        "root_cause": [
          {
            "type": "s_s_l_handshake_exception",
            "reason": "General SSLEngine problem"
          }
        ],
        "type": "s_s_l_handshake_exception",
        "reason": "General SSLEngine problem",
        "caused_by": {
          "type": "s_s_l_handshake_exception",
          "reason": "General SSLEngine problem",
          "caused_by": {
            "type": "validator_exception",
            "reason": "PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target",
            "caused_by": {
              "type": "sun_cert_path_builder_exception",
              "reason": "unable to find valid certification path to requested target"
            }
          }
        }
      },
      "status": 500
    }

On internet I have seen to add certificates. I don't understand which certificates to add.
Can you please tell which certificates to add and how to add? I have installed openjdk using sudo yum install java.

2

Hey @Praneeth,

It looks like you need to configure the certificate authorities in Elasticsearch so that your cluster can verify the identity of the remote cluster's certificate. Try setting or updating your truststore configuration for Elasticsearch: https://www.elastic.co/guide/en/elasticsearch/reference/current/security-settings.html#_java_keystore_files_2

3

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
4

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