SELF_SIGNED_CERT_IN_CHAIN Error in Azure DevOps Pipeline during prepare analysis stage

Currently receiving the following error on our Azure DevOps Pipeline when making use of the prepare analysis step:

[SQ] API GET ‘/api/server/version’ failed, error is request to https://COMPANY_INTERNAL_SONAR_URL/api/server/version failed, reason: self signed certificate in certificate chain

The plugin on Azure DevOps is the latest version available. We currently have the pipeline running on a static Linux VM that I can SSH to and make any changes necessary such as setting environment variables or importing certs. The instance of Sonarqube that is running is managed within the company by another team and they have provided a copy of the sonar server .crt file and also the root and intermediate certs for it.

The project that I’m trying to scan is a .NET project and I’m using the “scannerMode: ‘MSBuild’” option. I’ve looked over numerous threads in this forum for suggestions on how to fix this issue such as importing the provided certs to the java Keystone, using npm to set specific settings, updating specific environment variables and no luck.

When I’m on the agent I can curl the server version URL and return the version in question which points to the fact that it’s not a firewall rule or anything like that blocking it. Seems to be specifically failing because of something that is missing for the scanner to work.

When the prepare analysis stage runs using scannerMode: ‘MSBuild’, what keystone/variable does it use to try to reach the Sonar Url that’s set in the pipeline step?

Hi,

Welcome to the community!

The docs should help.

 
Ann

Hi Ann,

Thanks for that. Unfortunately I have already tried to import the cert using keytool on our EC2 VM that we use as an agent for the pipeline. I used “keytool -importcert -trustcacerts -alias SonarQube -keystore $JAVA_HOME/lib/security/cacerts -file /home/ec2-user/sonarqube-chain.crt”

In that file, I’ve combined the root, intermediate and internal company sonar server cert to make that chain file. I’ve also tried importing just the individual certs separately to test with the Azure DevOps Pipeline but unfortunately nothing changes.

The java version I’m using is openjdk java 17 (found that java 17 is the recommended version in Sonar docs) and the agent is RHEL 8.8. Java is installed using yum package manager, just want to provide as much detail as possible.

When the scanner that Azure DevOps uses tries to connect to the Sonar instance should it be using the keystore located in that location from the keytool command or is there anything built in to the scanner that needs to be configured? Every run of the pipeline has produced the same SSL error I mentioned in the original post unfortunately.

Hi,

This may also be relevant. Further details here.

 
HTH,
Ann

Hi,

I am also hitting similar problem, i have tried all options but getting same error. If you guys fixed it can you please through some suggestions.

Thanks

Aditya

My organization was facing the same issue with the Prepare Analysis task in Azure DevOps, prior to the Maven task where analysis would actually occur.

It turns out there are two issues, both relating to the self signed cert, but one for Node and the other for Java.

Since we use dynamic environments where the PATH entry for JAVA_HOME and the Node install location could change on a per pipeline basis we found manually configuring in each pipeline to be inefficient.

The following post was very helpful.
https://petertheautomator.com/2020/09/22/connect-sonarqube-to-azure-devops-with-self-signed-certificates/

The TLDR, is to create a .pem file containing your orgs self signed cert, and any other relevant certs, as well as a keystore (we use .jks file), and then add two environment variables on your azure agent (we’re hosted so these are ours to control)

  1. NODE_EXTRA_CA_CERTS = location of a .pem file containing the full certification chain of your self-signed cert - if your org uses multiple certs, make sure this file contains all of them.
  2. SONAR_SCANNER_OPTS = -Djavax.net.ssl.trustStore=“pathToKeyStore” -Djavax.net.ssl.keyStore=“pathToKeyStore” -Djavax.net.ssl.keyStorePassword=“yourPassword” -Djavax.net.ssl.trustStorePassword=“yourPassword”

now, no matter which version of node or java is used in our pipelines, they use the common store, and trust our self-signed cert.

2 Likes