No handler for action [cluster:admin/searchguard/whoami] when running sgadmin script

#1

Hello,
I am trying to install searchguard to SSL-ised ElasticSearch without Basic authentication, and i am facing issue when running sgadmin script.

Here is what i did :

Installed ElasticSearch 6.5.3

installed corresponding searchguard plugin: es/bin/elasticsearch-plugin install -b com.floragunn:search-guard-6:6.5.3-24.3

Generated all the certificates using SearchGuard procedure.

Tried using PEM or JKS certificates as described in the README File to run sgadmin.sh, and it fails with both attempts with the following error :

./sgadmin.sh -cacert root-ca.pem -cert CN=sgadmin.crtfull.pem -key CN=sgadmin.key.pem -keypass a070237aadaf5241d413 -nhnv -icl -cd …/sgconfig/
WARNING: JAVA_HOME not set, will use /usr/bin/java
Search Guard Admin v6
Will connect to localhost:9300 … done
Elasticsearch Version: 6.5.3
Search Guard Version: 6.5.3-24.3
ERR: An unexpected ActionNotFoundTransportException occured: No handler for action [cluster:admin/searchguard/whoami]
Trace:
ActionNotFoundTransportException[No handler for action [cluster:admin/searchguard/whoami]]
at org.elasticsearch.transport.TcpTransport.handleRequest(TcpTransport.java:1295)
at org.elasticsearch.transport.TcpTransport.messageReceived(TcpTransport.java:1172)
at org.elasticsearch.transport.netty4.Netty4MessageChannelHandler.channelRead(Netty4MessageChannelHandler.java:65)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:323)
at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:310)
at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:426)
at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:278)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
at io.netty.handler.logging.LoggingHandler.channelRead(LoggingHandler.java:241)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1429)
at io.netty.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1199)
at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1243)
at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:502)
at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:441)
at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:278)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1434)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:965)
at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:163)
at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:644)
at io.netty.channel.nio.NioEventLoop.processSelectedKeysPlain(NioEventLoop.java:544)
at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:498)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:458)
at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:897)
at java.lang.Thread.run(Thread.java:748)

Here is my elasticsearch config file with PEM certificates (same error stack when using jks certificates instead:

cluster.name: lal
node.name: ${HOSTNAME}
network.host: [site, local]

discovery.type: single-node
discovery.zen.minimum_master_nodes: 1

http.port: 9200
transport.tcp.port: 9300
script.painless.regex.enabled: true
http.cors.enabled : true
http.cors.allow-origin : “*”
http.cors.allow-methods : OPTIONS, HEAD, GET, POST, PUT, DELETE
http.cors.allow-headers : X-Requested-With,X-Auth-Token,Content-Type, Content-Length

######## Start Search Guard Demo Configuration ########

WARNING: revise all the lines below before you go into production

searchguard.ssl_only: true
searchguard.ssl.transport.resolve_hostname: false

searchguard.ssl.transport.pemcert_filepath: certs/CN=xxxx.crtfull.pem
searchguard.ssl.transport.pemkey_filepath: certs/CN=xxxx.key.pem
searchguard.ssl.transport.pemkey_password: 60380325479d2615399c
searchguard.ssl.transport.pemtrustedcas_filepath: certs/root-ca.pem
searchguard.ssl.transport.enforce_hostname_verification: false
searchguard.ssl.http.enabled: true
searchguard.ssl.http.pemcert_filepath: certs/CN=xxxx.crtfull.pem
searchguard.ssl.http.pemkey_filepath: certs/CN=xxxx.key.pem
searchguard.ssl.http.pemkey_password: 60380325479d2615399c
searchguard.ssl.http.pemtrustedcas_filepath: certs/root-ca.pem

cluster.routing.allocation.disk.threshold_enabled: false
node.max_local_storage_nodes: 3
xpack.security.enabled: false
######## End Search Guard Demo Configuration ########

0 Likes

#2

If you enable the SSL only mode:

then you do not need to run sgadmin, because you do not use any of the auth/auth functionality. When ssl_only is true, then no auth/auth related SG components are registered. That’s why you see the exception.

0 Likes

#3

Thanks a lot for your fast answer, this makes sense.

When I query Elastic via curl I get an exception, so I though something else would have to be added with sgadmin script.

The error I get ( again, I tried with both jks and pem certificates) is :

$ curl -XGET ‘https://xxxx:9200/_cat/indices?v
[2019-04-12T16:27:19,281][ERROR][c.f.s.s.h.n.SearchGuardSSLNettyHttpServerTransport] [slavtrim1] SSL Problem Received fatal alert: unknown_ca
javax.net.ssl.SSLException: Received fatal alert: unknown_ca

I used the certificates packages i received from SearchGuard.

$ keytool -list -v -keystore truststore.jks
Enter keystore password:

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 1 entry

Alias name: root-ca-chain
Creation date: Apr 12, 2019
Entry type: trustedCertEntry

Owner: CN=RSD Root CA, OU=RSD Root CA, O=RSD
Issuer: CN=RSD Root CA, OU=RSD Root CA, O=RSD
Serial number: 1
Valid from: Fri Apr 12 09:54:04 CEST 2019 until: Wed Apr 11 09:54:04 CEST 2029
Certificate fingerprints:
MD5: 8D:2A:DB:A9:03:A3:80:F0:3A:22:44:31:EA:F2:D5:A9
SHA1: AF:A0:24:A2:4D:E8:2E:90:41:43:E5:81:05:71:73:A8:63:50:93:9C
SHA256: F8:26:38:12:48:34:81:7F:BD:A5:30:AB:60:CD:97:83:F5:BB:67:29:49:C9:F4:24:E1:BE:43:CD:EA:3D:00:0D
Signature algorithm name: SHA256withRSA
Version: 3

Extensions:

#1: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: C3 BA E3 A0 D0 2E 8A AE 9A C6 52 8F 4B 87 4A 9F …R.K.J.
0010: CC B0 28 D9 …(.
]
]

#2: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:true
PathLen:2147483647
]

#3: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
Key_CertSign
Crl_Sign
]

#4: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: C3 BA E3 A0 D0 2E 8A AE 9A C6 52 8F 4B 87 4A 9F …R.K.J.
0010: CC B0 28 D9 …(.
]
]



What is wrong please ?

0 Likes

#4

This is because the root CA is self-signed. Self-signed certificates are not implicitly trusted and that’s why curl chokes.

You can either disable the verification of the root CA in curl by using the --insecure/-k switch like:

curl --insecure -XGET ‘https://xxxx:9200/_cat/indices?v’

Or you can provide the root CA to curl by using the --cacert switch:

curl --cacert /path/to/root-ca.pem -XGET ‘https://xxxx:9200/_cat/indices?v’

0 Likes

assigned jkressin #5
0 Likes

#6

Excellent!

All clear now, thanks a lot for your help,

0 Likes

closed #7
0 Likes