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.
i know the original post wasn’t about this but to answer one of the questions raised in the discussion, you can get certificates issued by an internal ca working with the vsts (now azure pipelines) agent. it’s cumbersome but not too bad.
first create a pem file that contains the public certificate chain used to issue your cert (you don’t need the leaf node, just the root ca and any issuing nodes). create a system environment variable named NODE_EXTRA_CA_CERTS. the value should be the full path to the pem file. This will get the custom certs working for the SonarQube prepare task (which I think is written exclusively in nodejs).
to get the analyze task working (which i think is nodejs that calls batch or bash scripts which then call java for good measure), you need the individual public certs in the chain. you might be able to use a chain like in the last step but it has to be in pkcs#7 format to work right with java keytool. fair warning, i didn’t test importing the chain but importing the individual certs works just fine. set another system environment variable named JAVA_HOME that points to the java home directory. This ensures that the batch or bash shells use the system java and not the embedded jre. then run the following command for each cert in the chain you need to import (you need to do it for each one, you can’t just import the root)
"%JAVA_HOME%\bin\keytool.exe" -importcert -alias {whatever your alias is} -cacerts -file {path to file, can be cer, crt or I think pem}
after that, restart the agent service so it picks up the new environment variables and certs and everything should work