error observed:
Failed to request and parse ‘https://*********/api/server/version’: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.
06:12:39.215 A server certificate could not be validated. Possible cause: you are using a self-signed SSL certificate but the certificate has not been installed on the client machine. Please make sure that you can access https://******* without encountering certificate errors.
Welcome to SonarSource community forum. This issue is related to your environment as the error message suggests. Scanner uses your build machine system certificates trust chain to establish HTTPS connections.
Possible causes are:
You have expired HTTPS certificate for your ******* host on your SQ server. Please check validity of that certificate.
You’ve changed the certificate on your ***** host. And this one is not trusted by your build machine. Please check the certificate from your build environment.
You have self issues certificates on your ******* host and trust chain was broken somewhere on build machine. i.e. the self-signing CA certificate expired.
That’s actually not entirely true. For example in azure devops pipelines the prepare sonarqube scan task runs in Java afaik, and Java does not load the build machine certificate store on windows, it has it’s own trust store. So if you have sonarqube in your internal domain with a domain-signed certificate and the build machine is domain joined thus can trust the sonarqube server certificate, the azure devops pipeline will fail because the Java process does not actually load that domain certificate from the windows certificate store. For this reason in my company we host all sonarqube instances with a public certificate instead of a domain certificate.
In that case, can you please precisely describe what’s your current build machine and SQ instance certificate setup?
Can you still verify the certificate from build machine to rule out obvious causes?
Are you aware of any changes in your setup that might affect this except change of date causing some certificate to expire? Like scanner or SQ version update.
We build for example dotnet framework apps on windows build servers using azure devops. Sonarsource provides some build tasks for azure devops to help with executing a sonarqube scan in a build pipeline. These tasks require Java and nodejs to be present on the build server because they use them in some aspect in the sonarqube scan process. Both Java and Nodejs use their own certificate trust store and not the windows certificate store, thus your domain trusted private CA will not by default be trusted by the Java and Nodejs processes used in the sonarqube scan.
See also this topic:
I am simply pointing out that the causes you listed are not exhaustive, and that managing sonarqube with a private CA signed certificate was, for my organisation, too much of a hassle which is why we now use public certificates on all sonarqubes.
I’m sorry, but I’m little confused here. Do you @Rouke.Broersma.IS represent the original case reported by @santosh3702 or are you just contributing to this post as general discussion?
I’m not sure if we need to wait for more input from @santosh3702 or not.
