Starting Egeria fails with SSL enabled #7688
Comments
|
The So in our case, this is the egeria server chassis application, in it's context as a network server, ie accepting inbound ssl connections. These will be the typical REST API calls we make against the egeria platform and egeria server. A A |
|
In the chassis it is accessed via a spring property (which in itself can be sourced from many places including java properties or environment), and it is also used in our client applications, where it must be set as a java property (as there is no spring server) If set to false, we override the default certificate checker (TrustManager) (which checks certificates are valid) with a no-op one which just validates anything as ok.... At least that's all how it should work! |
|
In your example - and skipping strict.ssl for now -- you are setting up the egeria chassis to use ./xxxy.p12 as the location where it finds a certificate to send when a client connects. There's more. The default application.properties for the server chassis sets This also applies to other parameters set in the application.properties -- for example we DO configure the truststore -- so even if you don't set one, it won't be using the java default, it will be using OUR default. Specifically on your invocation that fails -- that stacktrace does like like a problem setting properties -- odd, and it's occuring in the spring launcher -- so this is likely nothing to do with how we use that parameter. Is this a regular build of egeria, or modified? I'm wondering if there are any version inconsistencies. I had expected you might get an exception on finding a cert to use, given the default alias -- or you might see some SSL errors, if for example using mutual TLS, but not a property issue. Will try... |
|
I was able to specify those parameters ok, and noted in the log output as expected. ie |
|
My conclusion is a build issue as in your log is odd. I also tried various invalid (for a boolean) values, but in each case the stack trace contained a specific mention around type conversion etc If you have customized the build, can you repeat completely clean? Or maybe I've missed something else... |
|
@planetf1 Thanks Nigel, the only thing I customized in the build is to chance some of the SSL parameters in application.properties |
|
Do you get the same results with a completely untouched build, ONLY specifying parameters on invocation? |
|
We went back to CLI and were able to launch the app. However in some local experimentation (cloud native) I tried commenting out the trust store definition, hoping this would then default to using system certs. So in application properties: When I did this I hit the same exception, including: |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 20 days if no further activity occurs. Thank you for your contributions. |
github-actions
bot
added
the
no-issue-activity
Been trying to configure Egeria as described in the documentation to with a key store certificate (but no trust store certificate). ( I believe that the certificate contains some of the trust information in it as well). I have tried a few ways to pass in this information - both on the java command line:
java -Dstrict.ssl=true -Dloader.path=./server/lib -Dserver.port=9443 -Dserver.ssl.key-store=./xxxy.p12 -Dserver.ssl.key-store-password=xxx -jar ./server/server-chassis-spring-4.1-SNAPSHOT.jarAnd in application.properties.
If I set strict.ssl=false, Egeria comes up normally and all is well (except the certificate isn't used). If I set strict.ssl=true then Egeria fails (I think starting web server). The error message is:
Has anyone seen this behavior and worked through a similar issue? I'm sure I must be missing something silly?
The text was updated successfully, but these errors were encountered: