Hi,
I have a problem with loading openssl, does not make a difference if statically or dynamically linked, I always get the following error message when starting up
[2019-04-13T21:40:36,563][INFO ][c.f.s.s.DefaultSearchGuardKeyStore] [HMTWkAe] OpenSSL not available (this is not an error, we simply fallback to built-in JDK SSL) because of java.lang.IllegalArgumentException: Failed to load any of the given libraries: [netty_tcnative_linux_x86_64, netty_tcnative_linux_x86_64_fedora, netty_tcnative_x86_64, netty_tcnative]
There are no other DEBUG or INFO messages regarding this issue before or after.
I use the netty files
netty-tcnative-openssl-1.1.0j-dynamic-2.0.20.Final-fedora-linux-x86_64.jar
or
netty-tcnative-openssl-1.1.0j-static-2.0.20.Final-fedora-linux-x86_64.jar
Elasticsearch is 6.7.1.
If no netty file at all is present I get (correctly)
[2019-04-13T21:17:58,427][INFO ][c.f.s.s.DefaultSearchGuardKeyStore] [HMTWkAe] OpenSSL not available (this is not an error, we simply fallback to built-in JDK SSL) because of java.lang.Cl assNotFoundException: io.netty.internal.tcnative.SSL
Running on CentOS latest, of course when trying the dynamically linked version apr is installed. But from what I can see for dynamically linked you would expect that the OpenSSL version on the system is updated to the latest version manually which is an absolute no-go on RHEL systems in production as a lot of packages expect the version which is provided by RHEL/CentOS and side effects can occur, this is official statement from RedHat. But it makes no difference, the error is always the same. In generel the static linked version would be preferred.
OpenSSL is optional - if there are problems (like in your case) we just fallback to use TLS implementation of the JVM. So you can just ignore that. If you are on Java 11 there are also no big performance gains anymore of using OpenSSL over JVM TLS. If you are on Java 8 and can not use OpenSSL you can adjust the cipher suites to use CBC mode instead of GCM to make things faster. See https://github.com/floragunncom/search-guard/issues/310#issuecomment-372145935
To get more insights why the netty-tcnative-openssl-1.1.0j-static-2.0.20.Final-fedora-linux-x86_64.jar can not be loaded pls turn on debugging for the netty library
Thanks for your reply, yes I know it is optional but want to use the “native” OS functionality where possible. I am on Java 8, CBC ciphers instead of GCM… this is all too workaround for me.
I will definitely give the debug run a try and see what it says, if I need any more help then I would be happy to get back to you here, thanks.
Thanks for this hint as this made it pretty easy. Same problem I have or had with many java applications, my main /tmp/ is mounted noexec, so I gave
-Dio.netty.native.workdir and
-Dio.netty.tmpdir
its own dir in /var/lib/elasticsearch
Now it is working without any issues with the static linked file
[2019-04-14T15:28:34,623][INFO ][c.f.s.s.DefaultSearchGuardKeyStore] [1R7JXmL] OpenSSL OpenSSL 1.1.0j 20 Nov 2018 (269484207) available
[2019-04-14T15:28:34,673][INFO ][c.f.s.s.DefaultSearchGuardKeyStore] [1R7JXmL] Config directory is /etc/elasticsearch/, from there the key- and truststore files are resolved relatively
[2019-04-14T15:28:34,983][INFO ][c.f.s.s.DefaultSearchGuardKeyStore] [1R7JXmL] TLS Transport Client Provider : OPENSSL
[2019-04-14T15:28:34,983][INFO ][c.f.s.s.DefaultSearchGuardKeyStore] [1R7JXmL] TLS Transport Server Provider : OPENSSL
[2019-04-14T15:28:34,983][INFO ][c.f.s.s.DefaultSearchGuardKeyStore] [1R7JXmL] TLS HTTP Provider : OPENSSL
[2019-04-14T15:28:34,983][INFO ][c.f.s.s.DefaultSearchGuardKeyStore] [1R7JXmL] Enabled TLS protocols for transport layer : [TLSv1.2, TLSv1.1]
[2019-04-14T15:28:34,983][INFO ][c.f.s.s.DefaultSearchGuardKeyStore] [1R7JXmL] Enabled TLS protocols for HTTP layer : [TLSv1.2, TLSv1.1]