Sonarqube fails to start after Elastic Search encounters fatal error:
ERROR es[ ][o.e.b.Elasticsearch] fatal exception while booting Elasticsearch
org.elasticsearch.common.ssl.SslConfigException: failed to find a X509ExtendedTrustManager in the trust manager factory for [PKIX] and truststore [null]
at org.elasticsearch.common.ssl.KeyStoreUtil.createTrustManager(KeyStoreUtil.java:179) ~[?:?]
on Version 2025.3.0.108892 Deployed to Windows Servers through IIS.
My hope was to use _JAVA_OPTIONS to globally set it on the system however individually setting sonar.ce.javaAdditionalOpts and sonar.web.javaAdditionalOpts still achieved the intended goal. I need these certificates to communicate with my on-premise Azure DevOps Server 2022 for PR Decoration.
Any ideas on why Elastic Search fails and the other two succeed?
I was entirely unaware of the Elasticsearch process needing a trust store. It should only be communicating with SonarQube’s other 2 processes. It’s certainly not involved in PR decoration. Can you just leave this out?
I can and I did ignore it using sonar.properties. It does prevent a user from setting the global java options environment variable is the main issue.
A Windows user cannot set _JAVA_OPTIONS to have all JVMs use the same Djavax.net.ssl.trustStoreType. They will have to set the option for each individual process.
I’m not understanding. Are you saying that when you use the settings for the (2 of 3) individual processes, you were successfully able to set up the trust store usage for SonarQube, but that when you set it globally, startup failed because of Elasticsearch’s attempt to use it?
And that’s a problem for you because you have multiple processes running on the box and you want to simply configure the trust store globally?
Yes that is correct. Setting compute engine and web individually and keeping elastic search’s option empty allowed sonar qube service to start.
This is not a big deal to me, I was just curious if there was something I missed. With the global option set, I did attempt to specifically set elastic search option to null (NUL), but it looks like the global environment variable overrides what is in sonar properties. Sonar qube did not start failing with the same exception.
There’s not something you missed. I suppose we just don’t work from the assumption of being on a shared box. And/or Elasticsearch is picking up that global configuration automatically, without our intervention.