Internal or shard requests not allowed from a non-server node for transport type netty.

Search Guard
1

Hi,

Greetings!

We have been trying to install SearchGuard in our Dev cluster (2 Master + 4 Data nodes). I am blocked by the error: [ERROR][c.f.s.t.SearchGuardRequestHandler] Internal or shard requests not allowed from a non-server node for transport type netty

I have tried adding searchguard.cert.oid: 1.2.3.4.5.5 in elasticsearch.yml. Still getting same error.

We have Certificate chain and it shows mutiple Oid’s when I list it using Keytool. So I tried adding searchguard.nodes_dn with all listed “CN=XXXX”, still getting the same error.

Can someone guide me to resolve this issue.

Best Regards,

Rakesh

Error message for reference:

c.f.s.t.SearchGuardRequestHandler] Internal or shard
requests not allowed from a non-server node for transport type netty

o.e.a.a.i.c.TransportCreateIndexAction] [node372M]
no known master node, scheduling a retry

[o.e.d.z.UnicastZenPing ] [node372M] [9]
failed send ping to {#zen_unicast_XXXXXX}

java.lang.IllegalStateException: handshake failed
with {#zen_unicast_XXXX}

   at

org.elasticsearch.transport.TransportService.handshake(TransportService.java:364)
~[elasticsearch-5.2.2.jar:5.2.2]

   at

org.elasticsearch.discovery.zen.UnicastZenPing$PingingRound.getOrConnect(UnicastZenPing.java:393)
~[elasticsearch-5.2.2.jar:5.2.2]

   at

org.elasticsearch.discovery.zen.UnicastZenPing$3.doRun(UnicastZenPing.java:500)
[elasticsearch-5.2.2.jar:5.2.2]

   at

org.elasticsearch.common.util.concurrent.ThreadContext$ContextPreservingAbstractRunnable.doRun(ThreadContext.java:596)
[elasticsearch-5.2.2.jar:5.2.2]

   at

org.elasticsearch.common.util.concurrent.AbstractRunnable.run(AbstractRunnable.java:37)
[elasticsearch-5.2.2.jar:5.2.2]

   at

java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[?:1.8.0_131]

   at

java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[?:1.8.0_131]

   at java.lang.Thread.run(Thread.java:748) [?:1.8.0_131]
2

Hi,

Tried running sgadmin.sh with following errors:

[root@10 tools]# ./sgadmin.sh -h -ts /etc/elasticsearch/newcertsAllImported/cdelkdev.jks -tspass -ks /etc/elasticsearch/newcertsAllImported/cdelkdev.jks -kspass -ksalias -cd …/sgconfig -nhnv -cn cd_elk_cluster-dev

WARNING: JAVA_HOME not set, will use /usr/bin/java

Search Guard Admin v5

Will connect to :9300 … done

Contacting elasticsearch cluster ‘cd_elk_cluster-dev’ and wait for YELLOW clusterstate …

Cannot retrieve cluster state due to: None of the configured nodes are available: [{#transport#-1}{mSn5-o76QRywvF6bFWYC2A}{}{:9300}]. This is not an error, will keep on trying …

  • Try running sgadmin.sh with -icl and -nhnv (If thats works you need to check your clustername as well as hostnames in your SSL certificates)

  • If this is not working, try running sgadmin.sh with --diagnose and see diagnose trace log file)

We have openjdk version “1.8.0_131”

OpenJDK Runtime Environment (build 1.8.0_131-b11).

Is SearchGuard compatible with Openjdk?

Everything worked well with local demo bundle however it is not working with Company certificates.

Thanks,

Rakesh

3

My SearchGuard Config in elasticsearch.yml is:

searchguard.ssl.transport.enabled: true

searchguard.ssl.transport.keystore_filepath: /etc/elasticsearch/newcertsAllImported/cdelkdev.jks

searchguard.ssl.transport.keystore_password: pass

searchguard.ssl.transport.truststore_filepath: /etc/elasticsearch/newcertsAllImported/cdelkdev.jks

searchguard.ssl.transport.truststore_password: pass

searchguard.ssl.transport.enforce_hostname_verification: false

searchguard.ssl.transport.keystore_alias:alias

searchguard.ssl.http.enabled: true

searchguard.ssl.http.keystore_filepath: /etc/elasticsearch/newcertsAllImported/cdelkdev.jks

searchguard.ssl.http.keystore_password: pass

searchguard.ssl.http.truststore_filepath: /etc/elasticsearch/newcertsAllImported/cdelkdev.jks

searchguard.ssl.http.truststore_password: pass

searchguard.ssl.http.keystore_alias: alias

#searchguard.kerberos.krb5_filepath: /Users/temp/kerberos_ldap_environment/krb5.conf

#searchguard.kerberos.acceptor_keytab_filepath: http_srv.keytab

searchguard.audit.type: internal_elasticsearch

searchguard.authcz.admin_dn:

  • CN=xxxxx-dev.com, O=“Company name”, SERIALNUMBER=54557795, OID.1.3.6.1.4.1.311.60.2.1.3=US, OID.1.3.6.1.4.1.311.60.2.1.2=NY, OID.2.5.4.15="V1.4, Clause 7.3.2

searchguard.cert.oid: 1.2.3.4.5.5

There are multiple Oid’s in our cert chain.

···
4

Hi Rakesh,

when configuring TLS only the last certificate in your chain is really relevant for Search Guard. The intermediate certificates are required for checking the validity of the cert chain, but regarding OID or DN values, you need to look only at the last certificate.

Having said that, you have two possibilities here, either configure the OID (if your certs contain one), or set the DN correctyl. The value you have used for searchguard.authcz.admin_dn is not a DN!

OID approach:

First check the certificates in your keystore with the keytool list command, e.g.:

keytool -list -v -keystore keystore.jks

In the output, look for the SAN section of the last cert in the chain (which is listed first in the output):

#5: ObjectId: 2.5.29.17 Criticality=false

SubjectAlternativeName [

DNSName: node-0.example.com

DNSName: localhost

IPAddress: 127.0.0.1

OIDName: 1.2.3.4.5.5

]

Here you will find the OID value you need to configure in elastcsearch.yml, if you use a different value then the default “1.2.3.4.5.5”.

DN approach:

Again, check the contents of the keystore with the keytool command, and look for the Distinguished Name of the certificate:

Owner: CN=node-0.example.com, OU=SSL, O=Test, L=Test, C=DE

The setting you used:

  • CN=xxxxx-dev.com, O=“Company name”, SERIALNUMBER=54557795, OID.1.3.6.1.4.1.311.60.2.1.3=US, OID.1.3.6.1.4.1.311.60.2.1.2=NY, OID.2.5.4.15="V1.4, Clause 7.3.2

is not an X.509 Distinguished Name. Here’s a short article about DNs:

https://docs.oracle.com/cd/E24191_01/common/tutorials/authz_cert_attributes.html

Note that you can also use wildcards in the searchguard.authcz.admin_dn setting, and that you can also use multiple entries. This can simplify the configuration.

Finally, here’s a link to the Search Guard docs regarding node certificates:

https://github.com/floragunncom/search-guard-docs/blob/master/tls_node_certificates.md

Hope this helps!

···

On Monday, May 22, 2017 at 4:19:12 AM UTC+2, Rakesh wrote:

My SearchGuard Config in elasticsearch.yml is:

searchguard.ssl.transport.enabled: true

searchguard.ssl.transport.keystore_filepath: /etc/elasticsearch/newcertsAllImported/cdelkdev.jks

searchguard.ssl.transport.keystore_password: pass

searchguard.ssl.transport.truststore_filepath: /etc/elasticsearch/newcertsAllImported/cdelkdev.jks

searchguard.ssl.transport.truststore_password: pass

searchguard.ssl.transport.enforce_hostname_verification: false

searchguard.ssl.transport.keystore_alias:alias

searchguard.ssl.http.enabled: true

searchguard.ssl.http.keystore_filepath: /etc/elasticsearch/newcertsAllImported/cdelkdev.jks

searchguard.ssl.http.keystore_password: pass

searchguard.ssl.http.truststore_filepath: /etc/elasticsearch/newcertsAllImported/cdelkdev.jks

searchguard.ssl.http.truststore_password: pass

searchguard.ssl.http.keystore_alias: alias

#searchguard.kerberos.krb5_filepath: /Users/temp/kerberos_ldap_environment/krb5.conf

#searchguard.kerberos.acceptor_keytab_filepath: http_srv.keytab

searchguard.audit.type: internal_elasticsearch

searchguard.authcz.admin_dn:

  • CN=xxxxx-dev.com, O=“Company name”, SERIALNUMBER=54557795, OID.1.3.6.1.4.1.311.60.2.1.3=US, OID.1.3.6.1.4.1.311.60.2.1.2=NY, OID.2.5.4.15="V1.4, Clause 7.3.2

searchguard.cert.oid: 1.2.3.4.5.5

There are multiple Oid’s in our cert chain.

5

Hi JK,

Thanks for your reply.

We have four certificates in a cert chain with this order. 1. root 2. cdelkdev 3.intermediate1 and 4. intermediate2 which certificate DN should I consider, Intermediate2?

SAN part is only under cdelkdev section and it does not have OID. Do you think creating local certificates with your example scripts would work at enterprise? (https://github.com/floragunncom/search-guard-ssl/tree/master/example-pki-scripts)

Best Regards,

Rakesh

···

On Sunday, May 21, 2017 at 5:03:35 PM UTC-7, Rakesh wrote:

Hi,

Greetings!

We have been trying to install SearchGuard in our Dev cluster (2 Master + 4 Data nodes). I am blocked by the error: [ERROR][c.f.s.t.SearchGuardRequestHandler] Internal or shard requests not allowed from a non-server node for transport type netty

I have tried adding searchguard.cert.oid: 1.2.3.4.5.5 in elasticsearch.yml. Still getting same error.

We have Certificate chain and it shows mutiple Oid’s when I list it using Keytool. So I tried adding searchguard.nodes_dn with all listed “CN=XXXX”, still getting the same error.

Can someone guide me to resolve this issue.

Best Regards,

Rakesh

Error message for reference:

c.f.s.t.SearchGuardRequestHandler] Internal or shard
requests not allowed from a non-server node for transport type netty

o.e.a.a.i.c.TransportCreateIndexAction] [node372M]
no known master node, scheduling a retry

[o.e.d.z.UnicastZenPing ] [node372M] [9]
failed send ping to {#zen_unicast_XXXXXX}

java.lang.IllegalStateException: handshake failed
with {#zen_unicast_XXXX}

   at

org.elasticsearch.transport.TransportService.handshake(TransportService.java:364)
~[elasticsearch-5.2.2.jar:5.2.2]

   at

org.elasticsearch.discovery.zen.UnicastZenPing$PingingRound.getOrConnect(UnicastZenPing.java:393)
~[elasticsearch-5.2.2.jar:5.2.2]

   at

org.elasticsearch.discovery.zen.UnicastZenPing$3.doRun(UnicastZenPing.java:500)
[elasticsearch-5.2.2.jar:5.2.2]

   at

org.elasticsearch.common.util.concurrent.ThreadContext$ContextPreservingAbstractRunnable.doRun(ThreadContext.java:596)
[elasticsearch-5.2.2.jar:5.2.2]

   at

org.elasticsearch.common.util.concurrent.AbstractRunnable.run(AbstractRunnable.java:37)
[elasticsearch-5.2.2.jar:5.2.2]

   at

java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[?:1.8.0_131]

   at

java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[?:1.8.0_131]

   at java.lang.Thread.run(Thread.java:748) [?:1.8.0_131]
6

So, it seems that cdelkdev is the last one in the chain, and you should use the DN of this certificate then. I’m just wondering where you got the order from. Because usually, the chain of trust goes like:

Root CA signs intermediate cert 1

Intermediate cert 1 signs intermediate cert 2

Intermediate cert 2 signs the client certifcate

So I assume the cdelkdev is the correct one. The OID needs to be set in the certificate signing request. In some companies, adding this OID to the SAN entry is not possible/permitted, so it’s normal that you don’t see it.

So in your case I would recommended to set the DNs in the config. You can also use wildcards here, which probably makes configuration a bit easier.

You can find an example in the config template on our githib repository, lines 97 and following:

https://github.com/floragunncom/search-guard/blob/master/sgconfig/elasticsearch.yml.example

If ‘searchguard.ssl.transport.principal_extractor_class’ is set use the outcome of this as DN

searchguard.nodes_dn:

  • “CN=*.example.com, OU=SSL, O=Test, L=Test, C=DE”

  • “CN=node.other.com, OU=SSL, O=Test, L=Test, C=DE”

And please also correct the DN of the searchguard.authcz.admin_dn entry, the value you are using there is not a DN. Otherwise, you won’t be able to initialize Search Guard.

The scripts generated with the example PKI scripts are perfectly valid, but they should not be used in production unless you change the settings like company name, passwords etc. in the scripts.

Another way of generating working certificates for demo purposes is to use our certificate generator on our website:

Here you can generate up to 10 node certificates, and we also include the Root CA and two client certificates in the generated package.

Hope that helps!

Like written earlier, you can also use wildcards when setting the

···

On Monday, May 22, 2017 at 5:58:47 PM UTC+2, Rakesh wrote:

Hi JK,

Thanks for your reply.

We have four certificates in a cert chain with this order. 1. root 2. cdelkdev 3.intermediate1 and 4. intermediate2 which certificate DN should I consider, Intermediate2?

SAN part is only under cdelkdev section and it does not have OID. Do you think creating local certificates with your example scripts would work at enterprise? (https://github.com/floragunncom/search-guard-ssl/tree/master/example-pki-scripts)

Best Regards,

Rakesh

On Sunday, May 21, 2017 at 5:03:35 PM UTC-7, Rakesh wrote:

Hi,

Greetings!

We have been trying to install SearchGuard in our Dev cluster (2 Master + 4 Data nodes). I am blocked by the error: [ERROR][c.f.s.t.SearchGuardRequestHandler] Internal or shard requests not allowed from a non-server node for transport type netty

I have tried adding searchguard.cert.oid: 1.2.3.4.5.5 in elasticsearch.yml. Still getting same error.

We have Certificate chain and it shows mutiple Oid’s when I list it using Keytool. So I tried adding searchguard.nodes_dn with all listed “CN=XXXX”, still getting the same error.

Can someone guide me to resolve this issue.

Best Regards,

Rakesh

Error message for reference:

c.f.s.t.SearchGuardRequestHandler] Internal or shard
requests not allowed from a non-server node for transport type netty

o.e.a.a.i.c.TransportCreateIndexAction] [node372M]
no known master node, scheduling a retry

[o.e.d.z.UnicastZenPing ] [node372M] [9]
failed send ping to {#zen_unicast_XXXXXX}

java.lang.IllegalStateException: handshake failed
with {#zen_unicast_XXXX}

   at

org.elasticsearch.transport.TransportService.handshake(TransportService.java:364)
~[elasticsearch-5.2.2.jar:5.2.2]

   at

org.elasticsearch.discovery.zen.UnicastZenPing$PingingRound.getOrConnect(UnicastZenPing.java:393)
~[elasticsearch-5.2.2.jar:5.2.2]

   at

org.elasticsearch.discovery.zen.UnicastZenPing$3.doRun(UnicastZenPing.java:500)
[elasticsearch-5.2.2.jar:5.2.2]

   at

org.elasticsearch.common.util.concurrent.ThreadContext$ContextPreservingAbstractRunnable.doRun(ThreadContext.java:596)
[elasticsearch-5.2.2.jar:5.2.2]

   at

org.elasticsearch.common.util.concurrent.AbstractRunnable.run(AbstractRunnable.java:37)
[elasticsearch-5.2.2.jar:5.2.2]

   at

java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[?:1.8.0_131]

   at

java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[?:1.8.0_131]

   at java.lang.Thread.run(Thread.java:748) [?:1.8.0_131]
7

Hi,

searchguard.nodes_dn

We have only VIP and nodes names in certificate. I couldn’t find OU=SSL, O=Test, L=Test, C=DE part for node DN. Would it work with just - CN: nodename

searchguard.authcz.admin_dn

We have only one cert chain, no client certificate as such. As we have node names added to this cert chain, would it work as client node.

Best Regards,

Rakesh

···

On Sunday, May 21, 2017 at 5:03:35 PM UTC-7, Rakesh wrote:

Hi,

Greetings!

We have been trying to install SearchGuard in our Dev cluster (2 Master + 4 Data nodes). I am blocked by the error: [ERROR][c.f.s.t.SearchGuardRequestHandler] Internal or shard requests not allowed from a non-server node for transport type netty

I have tried adding searchguard.cert.oid: 1.2.3.4.5.5 in elasticsearch.yml. Still getting same error.

We have Certificate chain and it shows mutiple Oid’s when I list it using Keytool. So I tried adding searchguard.nodes_dn with all listed “CN=XXXX”, still getting the same error.

Can someone guide me to resolve this issue.

Best Regards,

Rakesh

Error message for reference:

c.f.s.t.SearchGuardRequestHandler] Internal or shard
requests not allowed from a non-server node for transport type netty

o.e.a.a.i.c.TransportCreateIndexAction] [node372M]
no known master node, scheduling a retry

[o.e.d.z.UnicastZenPing ] [node372M] [9]
failed send ping to {#zen_unicast_XXXXXX}

java.lang.IllegalStateException: handshake failed
with {#zen_unicast_XXXX}

   at

org.elasticsearch.transport.TransportService.handshake(TransportService.java:364)
~[elasticsearch-5.2.2.jar:5.2.2]

   at

org.elasticsearch.discovery.zen.UnicastZenPing$PingingRound.getOrConnect(UnicastZenPing.java:393)
~[elasticsearch-5.2.2.jar:5.2.2]

   at

org.elasticsearch.discovery.zen.UnicastZenPing$3.doRun(UnicastZenPing.java:500)
[elasticsearch-5.2.2.jar:5.2.2]

   at

org.elasticsearch.common.util.concurrent.ThreadContext$ContextPreservingAbstractRunnable.doRun(ThreadContext.java:596)
[elasticsearch-5.2.2.jar:5.2.2]

   at

org.elasticsearch.common.util.concurrent.AbstractRunnable.run(AbstractRunnable.java:37)
[elasticsearch-5.2.2.jar:5.2.2]

   at

java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[?:1.8.0_131]

   at

java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[?:1.8.0_131]

   at java.lang.Thread.run(Thread.java:748) [?:1.8.0_131]
8

Hi Rakesh,

searchguard.nodes_dn

“I couldn’t find OU=SSL, O=Test, L=Test, C=DE part for node DN”. The Distinguished Name of a certificate consists of multiple parts, and most of them are optional. So, the DN of your certificate might look very different from the sample DN I gave you, and indeed may only contain the CN=… part. If you can post the output of the keytool list command (or send it via email if you do not want to post it here), I can have a closer look and advise you better on this issue. But regarding your question “Would it work with just - CN: nodename”, yes, it will also work if you only specify the CN=nodename part (note that you need to use “=” instead of “:”). If your DN contains more parts than just CN, you can use wildcards like CN=nodename*

searchguard.authcz.admin_dn

You can use any certificate as admin certificate. Even the same certificate that you use as node certificate, although we do not recommend this for production use. The searchguard.authcz.admin_dn is just a way to tell Search Guard: “If an incoming request carries a certificate with this DN, treat it as an admin certificate and allow everything, including modifying the Search Guard index that stores users, roles and permissions”.

Let me know if this makes sense!

Thanks,

Jochen

···

On Monday, May 22, 2017 at 9:06:10 PM UTC+2, Rakesh wrote:

Hi,

searchguard.nodes_dn

We have only VIP and nodes names in certificate. I couldn’t find OU=SSL, O=Test, L=Test, C=DE part for node DN. Would it work with just - CN: nodename

searchguard.authcz.admin_dn

We have only one cert chain, no client certificate as such. As we have node names added to this cert chain, would it work as client node.

Best Regards,

Rakesh

On Sunday, May 21, 2017 at 5:03:35 PM UTC-7, Rakesh wrote:

Hi,

Greetings!

We have been trying to install SearchGuard in our Dev cluster (2 Master + 4 Data nodes). I am blocked by the error: [ERROR][c.f.s.t.SearchGuardRequestHandler] Internal or shard requests not allowed from a non-server node for transport type netty

I have tried adding searchguard.cert.oid: 1.2.3.4.5.5 in elasticsearch.yml. Still getting same error.

We have Certificate chain and it shows mutiple Oid’s when I list it using Keytool. So I tried adding searchguard.nodes_dn with all listed “CN=XXXX”, still getting the same error.

Can someone guide me to resolve this issue.

Best Regards,

Rakesh

Error message for reference:

c.f.s.t.SearchGuardRequestHandler] Internal or shard
requests not allowed from a non-server node for transport type netty

o.e.a.a.i.c.TransportCreateIndexAction] [node372M]
no known master node, scheduling a retry

[o.e.d.z.UnicastZenPing ] [node372M] [9]
failed send ping to {#zen_unicast_XXXXXX}

java.lang.IllegalStateException: handshake failed
with {#zen_unicast_XXXX}

   at

org.elasticsearch.transport.TransportService.handshake(TransportService.java:364)
~[elasticsearch-5.2.2.jar:5.2.2]

   at

org.elasticsearch.discovery.zen.UnicastZenPing$PingingRound.getOrConnect(UnicastZenPing.java:393)
~[elasticsearch-5.2.2.jar:5.2.2]

   at

org.elasticsearch.discovery.zen.UnicastZenPing$3.doRun(UnicastZenPing.java:500)
[elasticsearch-5.2.2.jar:5.2.2]

   at

org.elasticsearch.common.util.concurrent.ThreadContext$ContextPreservingAbstractRunnable.doRun(ThreadContext.java:596)
[elasticsearch-5.2.2.jar:5.2.2]

   at

org.elasticsearch.common.util.concurrent.AbstractRunnable.run(AbstractRunnable.java:37)
[elasticsearch-5.2.2.jar:5.2.2]

   at

java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[?:1.8.0_131]

   at

java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[?:1.8.0_131]

   at java.lang.Thread.run(Thread.java:748) [?:1.8.0_131]
9

Hi JK,

I have updated elasticsearch.yml with followign values:

searchguard.authcz.admin_dn:

searchguard.nodes_dn:

  • “CN=cdmonitoring-dev.*”

  • “CN=LPXXXXX00372.*”

  • “CN=LPXXXXX00335.*”

Tried running ./sgadmin.sh -cn cd_elk_cluster-dev -h lpxxxxx00335.xxxxx.com -ts /etc/elasticsearch/newcertsAllImported/cdelkdev.jks -tspass pass -ks /etc/elasticsearch/newcertsAllImported/cdelkdev.jks -kspass pass -ksalias cdelkdev -cd …/sgconfig -icl -nhnv

As least it is not showing error immediately. It is timing out after about 2 minutes and showing:Contacting elasticsearch cluster ‘cd_elk_cluster-dev’ and wait for YELLOW clusterstate …

ERR: Timed out while waiting for a green or yellow cluster state.

In the ES logs, I am seeing “unauthenticated request indices:data/write/bulk for user User [name=_sg_internal, roles=]”.

Currently I have started two master nodes, data nodes are not started yet. Usually we start master nodes, form a cluster and then add data nodes. Do we need all nodes up before running ./sgadmin.sh

···
10

Hi Rakesh,

This is not correct, the “ou”, “o”, “L” etc. parts were just an example/demo on how a DN is constructed! This will not match your actual DN of your certificate. I suggest that you use the keytool list command again to display the DN of your cdmonitoring-dev.xxxxx.com certificate, and copy and paste it 1:1.

Regarding sgadmin: You use an invalid combination of switches:

If you define the clustername with (-cn cd_elk_cluster-dev), you should not use the “ignore cluster name” (-icl) switch. Since this is a PoC, I suggest to simply use -icl, and remove the -cn part of sgadmin:

./sgadmin.sh -h lpxxxxx00335.xxxxx.com -ts /etc/elasticsearch/newcertsAllImported/cdelkdev.jks -tspass pass -ks /etc/elasticsearch/newcertsAllImported/cdelkdev.jks -kspass pass -ksalias cdelkdev -cd …/sgconfig -icl -nhnv

Thanks!

Jochen

···

On Tuesday, May 23, 2017 at 12:03:48 AM UTC+2, Rakesh wrote:

Hi JK,

I have updated elasticsearch.yml with followign values:

searchguard.authcz.admin_dn:

searchguard.nodes_dn:

  • “CN=cdmonitoring-dev.*”
  • “CN=LPXXXXX00372.*”
  • “CN=LPXXXXX00335.*”

Tried running ./sgadmin.sh -cn cd_elk_cluster-dev -h lpxxxxx00335.xxxxx.com -ts /etc/elasticsearch/newcertsAllImported/cdelkdev.jks -tspass pass -ks /etc/elasticsearch/newcertsAllImported/cdelkdev.jks -kspass pass -ksalias cdelkdev -cd …/sgconfig -icl -nhnv

As least it is not showing error immediately. It is timing out after about 2 minutes and showing:Contacting elasticsearch cluster ‘cd_elk_cluster-dev’ and wait for YELLOW clusterstate …

ERR: Timed out while waiting for a green or yellow cluster state.

In the ES logs, I am seeing “unauthenticated request indices:data/write/bulk for user User [name=_sg_internal, roles=]”.

Currently I have started two master nodes, data nodes are not started yet. Usually we start master nodes, form a cluster and then add data nodes. Do we need all nodes up before running ./sgadmin.sh

11

Hi JK,

Using complete DN and removing -cn option made it work. Cluster is yellow now.

Thank you for your timely response.

Best Regards,

Rakesh

12

Cool, glad I could help!

···

On Tuesday, May 23, 2017 at 7:38:05 PM UTC+2, Rakesh wrote:

Hi JK,

Using complete DN and removing -cn option made it work. Cluster is yellow now.

Thank you for your timely response.

Best Regards,

Rakesh