SonarQube Developer Ed problems connecting to Azure DevOps Server 2020 Update 1.1

SonarQube Developer Edition v9.6.1.59531

Azure DevOps:
Azure DevOps Server 2020 Update 1.1

I am attempting to set up the DevOps Platform Integration with Azure DevOps Server. The first issue I encountered was SonarQube not trusting the local enterprise CA. I got past that by adding the CA cert to the Java Trust.
The next issue I’m running into though appears to be with Azure DevOps itself.

2022.10.03 11:35:19 ERROR web[AYOdoJQ5tQZlaKk2AAAw][o.s.a.c.a.AzureDevOpsHttpClient]
Azure API call to [http://[internal azure devops url]/_apis/projects?api-version=3.0] failed with 302 http code. 
Azure response content : [<html><head><title>Object moved</title></head><body>\r\n<h2>Object moved to <a href="https://.../_apis/projects?api-version=3.0">here</a>.</h2>\r\n</body></html>\r\n]

I’ve verified that my PAT is correct, and that the root URL for Azure DevOps is correct.

This seems like SonarQube is trying to hit an old version of the Azure API?

The above looks like it is because it was pointed to http vs https.
I switched back to https and now I am getting the certificate issue again.

I’ve added both the root and the Azure DevOps certificates to the Java cert store.
"%JAVA_HOME%\bin\keytool" -importcert -alias [my Azure DevOps server name] -keystore "%JAVA_HOME%\lib\security\cacerts" -file "g:\[azure devops].cer"

After restarting SonarQube, I am still getting:

2022.10.03 12:31:31 ERROR web[AYOdoJQ5tQZlaKk2AABa][o.s.a.c.a.AzureDevOpsHttpClient]
Unable to contact Azure DevOps server for request [https://.../_apis/projects?api-version=3.0]: 
[PKIX path building failed: unable to find valid certification path to requested target

Is there a different JRE that SonarQube is using besides JAVA_HOME?

Update: I’ve verified that the imported certificates are valid via SSLPoke.

However, SonarQube is still throwing PKIX errors connecting to the Azure DevOps url.

Deleted and re-imported the certificates followed by a server reboot. The issue is resolved.
Odd that sslpoke was able to validate the previous certificates though…

1 Like