SearchGuard initialization: None of the configured nodes are available

Hi,

like already mentioned in some other threads, I also got an error when trying to initialize searchGuard:

qqzecd0@lizebrav1:/global/zebra/elkstack/oem/elasticsearch-5.3.1/plugins/search-guard-5/tools> ./sgadmin.sh --diagnose --configdir /global/zebra/elkstack/oem/elasticsearch-5.3.1/plugins/search-guard-5/sgconfig -icl --fail-fast --keystore /global/zebra/elkstack/environments/MY_ENV/lizebrav1.bmwgroup.net.jks --keystore-password **** --disable-host-name-verification --truststore /global/zebra/elkstack/environments/MY_ENV/truststore.jks --truststore-password ****
Search Guard Admin v5
Will connect to localhost:9300 … done
Failfast is activated
Diagnostic trace written to: /global/zebra/elkstack/oem/elasticsearch-5.3.1/plugins/search-guard-5/tools/sgadmin_diag_trace_2018-Apr-25_15-53-49.txt
Contacting elasticsearch cluster ‘elasticsearch’ and wait for YELLOW clusterstate …
ERR: Cannot retrieve cluster state due to: None of the configured nodes are available: [{#transport#-1}{sKYgGSReS7GWOcw3Mq89LQ}{localhost}{127.0.0.1:9300}].

  • 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)

All I can see in the diagnose file is something like:
r:/global/zebra/elkstack/oem/elasticsearch-5.3.1/plugins/search-guard-5/tools/…/…/…/lib/jts-1.13.jar:/global/zebra/elkstack/oem/elasticsearch-5.3.1/plugins/search-guard-5/tools/…/…/…/lib/log4j-api-2.7.jar:
at com.floragunn.searchguard.tools.SearchGuardAdmin.generateDiagnoseTrace(SearchGuardAdmin.java:679)
at com.floragunn.searchguard.tools.SearchGuardAdmin.main0(SearchGuardAdmin.java:372)
at com.floragunn.searchguard.tools.SearchGuardAdmin.main(SearchGuardAdmin.java:108)

NodesInfoResponse:
NoNodeAvailableException[None of the configured nodes are available: [{#transport#-1}{sKYgGSReS7GWOcw3Mq89LQ}{localhost}{127.0.0.1:9300}]]
at org.elasticsearch.client.transport.TransportClientNodesService.ensureNodesAreAvailable(TransportClientNodesService.java:344)
at org.elasticsearch.client.transport.TransportClientNodesService.execute(TransportClientNodesService.java:242)
at org.elasticsearch.client.transport.TransportProxyClient.execute(TransportProxyClient.java:59)
at org.elasticsearch.client.transport.TransportClient.doExecute(TransportClient.java:366)
at org.elasticsearch.client.support.AbstractClient.execute(AbstractClient.java:404)
at org.elasticsearch.client.support.AbstractClient.execute(AbstractClient.java:393)
at org.elasticsearch.client.support.AbstractClient$ClusterAdmin.execute(AbstractClient.java:705)
at org.elasticsearch.client.support.AbstractClient$ClusterAdmin.nodesInfo(AbstractClient.java:787)
at com.floragunn.searchguard.tools.SearchGuardAdmin.generateDiagnoseTrace(SearchGuardAdmin.java:687)
at com.floragunn.searchguard.tools.SearchGuardAdmin.main0(SearchGuardAdmin.java:372)
at com.floragunn.searchguard.tools.SearchGuardAdmin.main(SearchGuardAdmin.java:108)

Also, adding some Debug output in the log4j2.properties didnt help:

logger.searchguard.name = com.floragunn
logger.searchguard.level = debug

I tried to narrow it down using https://docs.search-guard.com/latest/troubleshooting-sgadmin, but

  • clustername, hostname are already ignored (see command above)
    `- --accept-red-cluster switch seems to be not available in 5.3.1-12

After unpacking the Offline Tool, I only got:
qqzecd0@lizebrav1:/global/zebra/jenkins_ZEBRA-CORE-Deploy/tools> ./sgtlsdiag.sh -es /global/zebra/elkstack/oem/elasticsearch-5.3.1/config/elasticsearch.yml
Reading node config file /global/zebra/elkstack/oem/elasticsearch-5.3.1/config/elasticsearch.yml

`=> No more analysis output, even not after making the elasticsearch.yml corrupt by changing the Keystore password (or other entries)

Any hints of what I can do else to resolve this ? I guess it´s maybe something related to the Certificate chain being used ?

Thanx, Torsten

elasticsearch.yml (2.76 KB)

lizebrav1.bmwgroup.net.jks.txt (8.7 KB)

truststore.jks.txt (11.1 KB)

can you please post (or mail if data is sensitive) the elasticsearch.yml conf files (for all nodes) and the output of

keytool -v -list -keystore /global/zebra/elkstack/environments/MY_ENV/lizebrav1.bmwgroup.net.jks

and

keytool -v -list -keystore /global/zebra/elkstack/environments/MY_ENV/truststore.jks

···

On Wednesday, 25 April 2018 16:23:46 UTC+2, Torsten Reinhard wrote:

Hi,

like already mentioned in some other threads, I also got an error when trying to initialize searchGuard:

qqzecd0@lizebrav1:/global/zebra/elkstack/oem/elasticsearch-5.3.1/plugins/search-guard-5/tools> ./sgadmin.sh --diagnose --configdir /global/zebra/elkstack/oem/elasticsearch-5.3.1/plugins/search-guard-5/sgconfig -icl --fail-fast --keystore /global/zebra/elkstack/environments/MY_ENV/lizebrav1.bmwgroup.net.jks --keystore-password **** --disable-host-name-verification --truststore /global/zebra/elkstack/environments/MY_ENV/truststore.jks --truststore-password ****
Search Guard Admin v5
Will connect to localhost:9300 … done
Failfast is activated
Diagnostic trace written to: /global/zebra/elkstack/oem/elasticsearch-5.3.1/plugins/search-guard-5/tools/sgadmin_diag_trace_2018-Apr-25_15-53-49.txt
Contacting elasticsearch cluster ‘elasticsearch’ and wait for YELLOW clusterstate …
ERR: Cannot retrieve cluster state due to: None of the configured nodes are available: [{#transport#-1}{sKYgGSReS7GWOcw3Mq89LQ}{localhost}{127.0.0.1:9300}].

  • 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)

All I can see in the diagnose file is something like:
r:/global/zebra/elkstack/oem/elasticsearch-5.3.1/plugins/search-guard-5/tools/…/…/…/lib/jts-1.13.jar:/global/zebra/elkstack/oem/elasticsearch-5.3.1/plugins/search-guard-5/tools/…/…/…/lib/log4j-api-2.7.jar:
at com.floragunn.searchguard.tools.SearchGuardAdmin.generateDiagnoseTrace(SearchGuardAdmin.java:679)
at com.floragunn.searchguard.tools.SearchGuardAdmin.main0(SearchGuardAdmin.java:372)
at com.floragunn.searchguard.tools.SearchGuardAdmin.main(SearchGuardAdmin.java:108)

NodesInfoResponse:
NoNodeAvailableException[None of the configured nodes are available: [{#transport#-1}{sKYgGSReS7GWOcw3Mq89LQ}{localhost}{127.0.0.1:9300}]]
at org.elasticsearch.client.transport.TransportClientNodesService.ensureNodesAreAvailable(TransportClientNodesService.java:344)
at org.elasticsearch.client.transport.TransportClientNodesService.execute(TransportClientNodesService.java:242)
at org.elasticsearch.client.transport.TransportProxyClient.execute(TransportProxyClient.java:59)
at org.elasticsearch.client.transport.TransportClient.doExecute(TransportClient.java:366)
at org.elasticsearch.client.support.AbstractClient.execute(AbstractClient.java:404)
at org.elasticsearch.client.support.AbstractClient.execute(AbstractClient.java:393)
at org.elasticsearch.client.support.AbstractClient$ClusterAdmin.execute(AbstractClient.java:705)
at org.elasticsearch.client.support.AbstractClient$ClusterAdmin.nodesInfo(AbstractClient.java:787)
at com.floragunn.searchguard.tools.SearchGuardAdmin.generateDiagnoseTrace(SearchGuardAdmin.java:687)
at com.floragunn.searchguard.tools.SearchGuardAdmin.main0(SearchGuardAdmin.java:372)
at com.floragunn.searchguard.tools.SearchGuardAdmin.main(SearchGuardAdmin.java:108)

Also, adding some Debug output in the log4j2.properties didnt help:

logger.searchguard.name = com.floragunn
logger.searchguard.level = debug

I tried to narrow it down using https://docs.search-guard.com/latest/troubleshooting-sgadmin, but

  • clustername, hostname are already ignored (see command above)
    `- --accept-red-cluster switch seems to be not available in 5.3.1-12

After unpacking the Offline Tool, I only got:
qqzecd0@lizebrav1:/global/zebra/jenkins_ZEBRA-CORE-Deploy/tools> ./sgtlsdiag.sh -es /global/zebra/elkstack/oem/elasticsearch-5.3.1/config/elasticsearch.yml
Reading node config file /global/zebra/elkstack/oem/elasticsearch-5.3.1/config/elasticsearch.yml

`=> No more analysis output, even not after making the elasticsearch.yml corrupt by changing the Keystore password (or other entries)

Any hints of what I can do else to resolve this ? I guess it´s maybe something related to the Certificate chain being used ?

Thanx, Torsten

I´ve attached 3 files. The truststore.jks should be ok, it´s also used for other setups that are working.
The problem is somewhere either in the lizebrav1 keystore - or in the elasticsearch.yml.

Maybe you could also tell me, why the ./sgtlsdiag.sh does not output anything?

···

Am Mittwoch, 25. April 2018 17:06:55 UTC+2 schrieb Search Guard:

can you please post (or mail if data is sensitive) the elasticsearch.yml conf files (for all nodes) and the output of

keytool -v -list -keystore /global/zebra/elkstack/environments/MY_ENV/lizebrav1.bmwgroup.net.jks

and

keytool -v -list -keystore /global/zebra/elkstack/environments/MY_ENV/truststore.jks

On Wednesday, 25 April 2018 16:23:46 UTC+2, Torsten Reinhard wrote:

Hi,

like already mentioned in some other threads, I also got an error when trying to initialize searchGuard:

qqzecd0@lizebrav1:/global/zebra/elkstack/oem/elasticsearch-5.3.1/plugins/search-guard-5/tools> ./sgadmin.sh --diagnose --configdir /global/zebra/elkstack/oem/elasticsearch-5.3.1/plugins/search-guard-5/sgconfig -icl --fail-fast --keystore /global/zebra/elkstack/environments/MY_ENV/lizebrav1.bmwgroup.net.jks --keystore-password **** --disable-host-name-verification --truststore /global/zebra/elkstack/environments/MY_ENV/truststore.jks --truststore-password ****
Search Guard Admin v5
Will connect to localhost:9300 … done
Failfast is activated
Diagnostic trace written to: /global/zebra/elkstack/oem/elasticsearch-5.3.1/plugins/search-guard-5/tools/sgadmin_diag_trace_2018-Apr-25_15-53-49.txt
Contacting elasticsearch cluster ‘elasticsearch’ and wait for YELLOW clusterstate …
ERR: Cannot retrieve cluster state due to: None of the configured nodes are available: [{#transport#-1}{sKYgGSReS7GWOcw3Mq89LQ}{localhost}{127.0.0.1:9300}].

  • 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)

All I can see in the diagnose file is something like:
r:/global/zebra/elkstack/oem/elasticsearch-5.3.1/plugins/search-guard-5/tools/…/…/…/lib/jts-1.13.jar:/global/zebra/elkstack/oem/elasticsearch-5.3.1/plugins/search-guard-5/tools/…/…/…/lib/log4j-api-2.7.jar:
at com.floragunn.searchguard.tools.SearchGuardAdmin.generateDiagnoseTrace(SearchGuardAdmin.java:679)
at com.floragunn.searchguard.tools.SearchGuardAdmin.main0(SearchGuardAdmin.java:372)
at com.floragunn.searchguard.tools.SearchGuardAdmin.main(SearchGuardAdmin.java:108)

NodesInfoResponse:
NoNodeAvailableException[None of the configured nodes are available: [{#transport#-1}{sKYgGSReS7GWOcw3Mq89LQ}{localhost}{127.0.0.1:9300}]]
at org.elasticsearch.client.transport.TransportClientNodesService.ensureNodesAreAvailable(TransportClientNodesService.java:344)
at org.elasticsearch.client.transport.TransportClientNodesService.execute(TransportClientNodesService.java:242)
at org.elasticsearch.client.transport.TransportProxyClient.execute(TransportProxyClient.java:59)
at org.elasticsearch.client.transport.TransportClient.doExecute(TransportClient.java:366)
at org.elasticsearch.client.support.AbstractClient.execute(AbstractClient.java:404)
at org.elasticsearch.client.support.AbstractClient.execute(AbstractClient.java:393)
at org.elasticsearch.client.support.AbstractClient$ClusterAdmin.execute(AbstractClient.java:705)
at org.elasticsearch.client.support.AbstractClient$ClusterAdmin.nodesInfo(AbstractClient.java:787)
at com.floragunn.searchguard.tools.SearchGuardAdmin.generateDiagnoseTrace(SearchGuardAdmin.java:687)
at com.floragunn.searchguard.tools.SearchGuardAdmin.main0(SearchGuardAdmin.java:372)
at com.floragunn.searchguard.tools.SearchGuardAdmin.main(SearchGuardAdmin.java:108)

Also, adding some Debug output in the log4j2.properties didnt help:

logger.searchguard.name = com.floragunn
logger.searchguard.level = debug

I tried to narrow it down using https://docs.search-guard.com/latest/troubleshooting-sgadmin, but

  • clustername, hostname are already ignored (see command above)
    `- --accept-red-cluster switch seems to be not available in 5.3.1-12

After unpacking the Offline Tool, I only got:
qqzecd0@lizebrav1:/global/zebra/jenkins_ZEBRA-CORE-Deploy/tools> ./sgtlsdiag.sh -es /global/zebra/elkstack/oem/elasticsearch-5.3.1/config/elasticsearch.yml
Reading node config file /global/zebra/elkstack/oem/elasticsearch-5.3.1/config/elasticsearch.yml

`=> No more analysis output, even not after making the elasticsearch.yml corrupt by changing the Keystore password (or other entries)

Any hints of what I can do else to resolve this ? I guess it´s maybe something related to the Certificate chain being used ?

Thanx, Torsten

  • searchguard.authcz.admin_dn and searchguard.nodes_dn must no be same!
    You need at least a node certificate and a different admin certificate and different DN

  • We strongly recommend against putting the emailaddress into the DN of a certificate. This is deprecated and may cause troubles.

For example in the cert its EMAILADDRESS=zebra@…de, in the elasticsearch.yml its E=zebra@…de

Even if you cannot use the generated certs it should give you a clue how it works. Pls look also here Configuring TLS | Security for Elasticsearch | Search Guard

  • The diagnose only works if a connection to the cluster could be established. There are some improvements for this in SG 6 but they were not backported to SG 5.
···

On Thursday, 26 April 2018 10:21:00 UTC+2, Torsten Reinhard wrote:

I´ve attached 3 files. The truststore.jks should be ok, it´s also used for other setups that are working.
The problem is somewhere either in the lizebrav1 keystore - or in the elasticsearch.yml.

Maybe you could also tell me, why the ./sgtlsdiag.sh does not output anything?

Am Mittwoch, 25. April 2018 17:06:55 UTC+2 schrieb Search Guard:

can you please post (or mail if data is sensitive) the elasticsearch.yml conf files (for all nodes) and the output of

keytool -v -list -keystore /global/zebra/elkstack/environments/MY_ENV/lizebrav1.bmwgroup.net.jks

and

keytool -v -list -keystore /global/zebra/elkstack/environments/MY_ENV/truststore.jks

On Wednesday, 25 April 2018 16:23:46 UTC+2, Torsten Reinhard wrote:

Hi,

like already mentioned in some other threads, I also got an error when trying to initialize searchGuard:

qqzecd0@lizebrav1:/global/zebra/elkstack/oem/elasticsearch-5.3.1/plugins/search-guard-5/tools> ./sgadmin.sh --diagnose --configdir /global/zebra/elkstack/oem/elasticsearch-5.3.1/plugins/search-guard-5/sgconfig -icl --fail-fast --keystore /global/zebra/elkstack/environments/MY_ENV/lizebrav1.bmwgroup.net.jks --keystore-password **** --disable-host-name-verification --truststore /global/zebra/elkstack/environments/MY_ENV/truststore.jks --truststore-password ****
Search Guard Admin v5
Will connect to localhost:9300 … done
Failfast is activated
Diagnostic trace written to: /global/zebra/elkstack/oem/elasticsearch-5.3.1/plugins/search-guard-5/tools/sgadmin_diag_trace_2018-Apr-25_15-53-49.txt
Contacting elasticsearch cluster ‘elasticsearch’ and wait for YELLOW clusterstate …
ERR: Cannot retrieve cluster state due to: None of the configured nodes are available: [{#transport#-1}{sKYgGSReS7GWOcw3Mq89LQ}{localhost}{127.0.0.1:9300}].

  • 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)

All I can see in the diagnose file is something like:
r:/global/zebra/elkstack/oem/elasticsearch-5.3.1/plugins/search-guard-5/tools/…/…/…/lib/jts-1.13.jar:/global/zebra/elkstack/oem/elasticsearch-5.3.1/plugins/search-guard-5/tools/…/…/…/lib/log4j-api-2.7.jar:
at com.floragunn.searchguard.tools.SearchGuardAdmin.generateDiagnoseTrace(SearchGuardAdmin.java:679)
at com.floragunn.searchguard.tools.SearchGuardAdmin.main0(SearchGuardAdmin.java:372)
at com.floragunn.searchguard.tools.SearchGuardAdmin.main(SearchGuardAdmin.java:108)

NodesInfoResponse:
NoNodeAvailableException[None of the configured nodes are available: [{#transport#-1}{sKYgGSReS7GWOcw3Mq89LQ}{localhost}{127.0.0.1:9300}]]
at org.elasticsearch.client.transport.TransportClientNodesService.ensureNodesAreAvailable(TransportClientNodesService.java:344)
at org.elasticsearch.client.transport.TransportClientNodesService.execute(TransportClientNodesService.java:242)
at org.elasticsearch.client.transport.TransportProxyClient.execute(TransportProxyClient.java:59)
at org.elasticsearch.client.transport.TransportClient.doExecute(TransportClient.java:366)
at org.elasticsearch.client.support.AbstractClient.execute(AbstractClient.java:404)
at org.elasticsearch.client.support.AbstractClient.execute(AbstractClient.java:393)
at org.elasticsearch.client.support.AbstractClient$ClusterAdmin.execute(AbstractClient.java:705)
at org.elasticsearch.client.support.AbstractClient$ClusterAdmin.nodesInfo(AbstractClient.java:787)
at com.floragunn.searchguard.tools.SearchGuardAdmin.generateDiagnoseTrace(SearchGuardAdmin.java:687)
at com.floragunn.searchguard.tools.SearchGuardAdmin.main0(SearchGuardAdmin.java:372)
at com.floragunn.searchguard.tools.SearchGuardAdmin.main(SearchGuardAdmin.java:108)

Also, adding some Debug output in the log4j2.properties didnt help:

logger.searchguard.name = com.floragunn
logger.searchguard.level = debug

I tried to narrow it down using https://docs.search-guard.com/latest/troubleshooting-sgadmin, but

  • clustername, hostname are already ignored (see command above)
    `- --accept-red-cluster switch seems to be not available in 5.3.1-12

After unpacking the Offline Tool, I only got:
qqzecd0@lizebrav1:/global/zebra/jenkins_ZEBRA-CORE-Deploy/tools> ./sgtlsdiag.sh -es /global/zebra/elkstack/oem/elasticsearch-5.3.1/config/elasticsearch.yml
Reading node config file /global/zebra/elkstack/oem/elasticsearch-5.3.1/config/elasticsearch.yml

`=> No more analysis output, even not after making the elasticsearch.yml corrupt by changing the Keystore password (or other entries)

Any hints of what I can do else to resolve this ? I guess it´s maybe something related to the Certificate chain being used ?

Thanx, Torsten

Hi,

I read the documentation, but that didn´t help me, that´s why I was asking here, see the attached *.txt files (output of keytool -v -list)
Could I remove the EMAILADDRESS=… entry from elasticsearch.yml without changing the keystore? As far as I understand, it should match exactly the string that is reported by the keytool -v -list command, right?

Is there no way to validate elasticsearch.yml - and the key/truststore.jks to get an idea what may cause the connection problems ? Any DEBUG output maybe?

Thx, Torsten

The main problem at the moment is not the emailaddress in the DN but that searchguard.authcz.admin_dn and searchguard.nodes_dn must no be same. So its seem the general tls setup is not correct. Lets start with that first.

You are dealing with 2 certificate stores at the moment:

  • /global/zebra/elkstack/environments/MY_ENV/lizebrav1.bmwgroup.net.jks (used with sgadmin, for this i have already a keytool list output)

  • server.jks (used in elasticsearch.yml, no keytool list output yet)

So please attach the keytool list output of server.jks.

Thx

···

On Thursday, 26 April 2018 12:29:57 UTC+2, Torsten Reinhard wrote:

Hi,

I read the documentation, but that didn´t help me, that´s why I was asking here, see the attached *.txt files (output of keytool -v -list)
Could I remove the EMAILADDRESS=… entry from elasticsearch.yml without changing the keystore? As far as I understand, it should match exactly the string that is reported by the keytool -v -list command, right?

Is there no way to validate elasticsearch.yml - and the key/truststore.jks to get an idea what may cause the connection problems ? Any DEBUG output maybe?

Thx, Torsten

Hi, sorry,

the stores in elasticsearch.yml are the same as under MY_ENV folder, they are created by copying:

cp -f  "${target.global.dir}/environments/MY_ENV/$HOSTNAME.jks" "${elastic.elasticsearch.path.base}/config/server.jks"
cp -f  "${target.global.dir}/environments/MY_ENV/truststore.jks" "${elastic.elasticsearch.path.base}/config/truststore.jks"

This is due to the fact that there are multiple environments, where MY_ENV is a symbolic link to a dedicated environment.

For a correct setup the searchguard.authcz.admin_dn and searchguard.nodes_dn shouldnt be the same, yes -and also hostname verification should be turned on.
But as mentioned, we got it running like this at another environment, where only the keystore.jks is different - and the settings of searchguard.authcz.admin_dn and searchguard.nodes_dn…

Where do I get the searchguard.authcz.admin_dn and searchguard.nodes_dn from? Is that line a copy of what keytool -v -list is showing ? With or without EMail Adress? With or without blanks ?

Thanx, Torsten

Hi, sorry,

the stores in elasticsearch.yml are the same as under MY_ENV folder, they are created by copying:

cp -f  "${target.global.dir}/environments/MY_ENV/$HOSTNAME.jks" "${elastic.elasticsearch.path.base}/config/server.jks"
cp -f  "${target.global.dir}/environments/MY_ENV/truststore.jks" "${elastic.elasticsearch.path.base}/config/truststore.jks"

This is due to the fact that there are multiple environments, where MY_ENV is a symbolic link to a dedicated environment.

For a correct setup the searchguard.authcz.admin_dn and searchguard.nodes_dn shouldnt be the same, yes -and also hostname verification should be turned on.
But as mentioned, we got it running like this at another environment, where only the keystore.jks is different - and the settings of searchguard.authcz.admin_dn and searchguard.nodes_dn…

Where do I get the searchguard.authcz.admin_dn and searchguard.nodes_dn from? Is that line a copy of what keytool -v -list is showing ? With or without EMail Adress? With or without blanks ?

As mentioned before: You need two kind certificates. The node certificates which their CN should match the hostname.

They are configured via searchguard.ssl.transport.keystore_filepath and their DN must match also those listed under searchguard.nodes_dn (here you can also use wildcards and even regex expressions)

Then you need one admin certificate. The DN of this certificate must be listed under searchguard.authcz.admin_dn but not match any of searchguard.nodes_dn. For searchguard.authcz.admin_dn no wildcard or regex is allowed, so yes, it must match that what keytool list is showing.

So i guess the next step for you is to create another certificate which can be used as admin cert. Make sure that the DN of that certificate must not match searchguard.nodes_dn.

(all this must be done so that we clearly know if another node talks to another node or if sgadmin talks to a node)

···

On Thursday, 26 April 2018 13:51:46 UTC+2, Torsten Reinhard wrote:

Thanx, Torsten