Startup fails due to problems with OpenSSL and netty-tcnative on Debian 11
After executing command make run
, caosDB server cannot start: failed to set certificate and key
Error message:
INFORMATION: Starting org.caosdb.server.CaosDBServer application
[org.caosdb.server.CaosDBServer.main()] ERROR org.caosdb.server.CaosDBServer - Could not start the server.
javax.net.ssl.SSLException: failed to set certificate and key
at io.netty.handler.ssl.ReferenceCountedOpenSslServerContext.newSessionContext(ReferenceCountedOpenSslServerContext.java:138) ~[netty-handler-4.1.63.Final.jar:4.1.63.Final]
at io.netty.handler.ssl.OpenSslServerContext.<init>(OpenSslServerContext.java:356) ~[netty-handler-4.1.63.Final.jar:4.1.63.Final]
at io.netty.handler.ssl.OpenSslServerContext.<init>(OpenSslServerContext.java:336) ~[netty-handler-4.1.63.Final.jar:4.1.63.Final]
at io.netty.handler.ssl.SslContext.newServerContextInternal(SslContext.java:473) ~[netty-handler-4.1.63.Final.jar:4.1.63.Final]
at io.netty.handler.ssl.SslContextBuilder.build(SslContextBuilder.java:609) ~[netty-handler-4.1.63.Final.jar:4.1.63.Final]
at org.caosdb.server.grpc.GRPCServer.buildSslContext(GRPCServer.java:112) ~[classes/:?]
at org.caosdb.server.grpc.GRPCServer.buildServer(GRPCServer.java:161) ~[classes/:?]
at org.caosdb.server.grpc.GRPCServer.startServer(GRPCServer.java:192) ~[classes/:?]
at org.caosdb.server.CaosDBServer.initWebServer(CaosDBServer.java:385) ~[classes/:?]
at org.caosdb.server.CaosDBServer.main(CaosDBServer.java:157) ~[classes/:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:282) ~[?:?]
at java.lang.Thread.run(Thread.java:829) ~[?:?]
Caused by: java.lang.IllegalArgumentException: KeyManagerFactory not supported
at io.netty.handler.ssl.ReferenceCountedOpenSslServerContext.newSessionContext(ReferenceCountedOpenSslServerContext.java:112) ~[netty-handler-4.1.63.Final.jar:4.1.63.Final]
... 15 more
make: *** [Makefile:42: run] Fehler 1
Self-signed certificates were made following instructions in documentation. In addition, unit test with make test
fails:
[ERROR] Failures:
[ERROR] TestServerSideScriptingCaller.testTimeout
Expected: an instance of org.caosdb.server.scripting.TimeoutException
but: <org.junit.internal.runners.model.MultipleFailureException: There were 2 errors:
org.caosdb.server.scripting.TimeoutException(The process was terminated due to a timeout.)
java.io.IOException(Unable to delete directory .TEST_DIR/serverSideScriptingCallerTestFolder/testPWD.)> is a org.junit.internal.runners.model.MultipleFailureException
Stacktrace was: org.junit.internal.runners.model.MultipleFailureException: There were 2 errors:
org.caosdb.server.scripting.TimeoutException(The process was terminated due to a timeout.)
java.io.IOException(Unable to delete directory .TEST_DIR/serverSideScriptingCallerTestFolder/testPWD.)
at org.junit.runners.model.MultipleFailureException.assertEmpty(MultipleFailureException.java:67)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:39)
at org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:239)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:364)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:237)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:158)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:428)
at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:162)
at org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:562)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:548)
This issue seems to occur so far in branches main, dev and v.0.7.1.
Any idea what the problem might be?
Known Workaround
Remove netty-tcnative
dependency:
diff --git a/pom.xml b/pom.xml
index 733a5b4..c9585b0 100644
--- a/pom.xml
+++ b/pom.xml
@@ -190,13 +190,6 @@
<artifactId>grpc-netty</artifactId>
<version>${grpc.version}</version>
</dependency>
- <dependency>
- <groupId>io.netty</groupId>
- <artifactId>netty-tcnative</artifactId>
- <version>${netty-tcnative.version}</version>
- <classifier>${os.detected.classifier}</classifier>
- <scope>runtime</scope>
- </dependency>
<dependency>
<groupId>io.grpc</groupId>
<artifactId>grpc-protobuf</artifactId>
Disabling the netty-tcnative dependency is probably ok, security-wise.
A bit of background: The only difference is, that we are not using the systems OpenSSL as the library but the JRE (Java) built-in SSL libraries instead. It is favorable to use the up-to-date OpenSSL implementation, because it is a widely used library with an active community whereas I'm not so sure about the built-in library. Be sure to review the disabled/enabled algorithms and cipher-suites in conf/core/server.conf
. Otherwise the server might offer also outdated/less secure SSL/TLS connections. If you are using this behind a reverse proxy or just for fun, you are good to go as well.