Changing the URL of our Azure DevOps to scan with SonarQube

We current have the Developer edition of SonarQube running in our commercial Azure DevOps service pipeline which works fine. We are now moving to a government Azure DevOps VM server. When we go to the Administration → Configuration → DevOps Platform Integrations and update the URL and token the configuration cannot verify. We have tried deleting the current configuration and adding a new one but get the same results.


Welcome to the community!

Is there anything interesting in your server logs (specifically `web.log)?


Sorry for the late reply
I cannot find anything in the web logs
I have checked it with Log Level set to INFO and DEBUG


Thanks for checking.

We’ve had a ticket in the backlog for a while now about improving the logging when there’s a problem with ADO. I’m hoping it will be resolved in 9.5. But without clear logging about the problem, it’s difficult for me to know what to tell you from here.


Sorry to hear that as we are very close to going live which involves switch to government DevOps
Thanks for reply

Hi @ledetj ,
I’m sorry to hear that you struggle with this.
I just tried on my side and it worked. So, i will through my basic checklist:

  • Have you checked that you wrote the server URL with the right collection name? (like
  • Have you checked that the SonarQube server has the right permissions to query the Azure DevOps Server? (certificates, permissions, etc)

Can you copy paste the error message you got?

FYI our logging ticket referred above might be solved for the 9.5 version of SonarQube (but I cannot promise, :crossed_fingers: ). This will give us more details if we cannot solve your problem before :wink:


Hello Christophe,

Thanks for any help you could provide.
Here is my token on the government DevOps
I have also changed the “Organization” of the token to “All accessible organizations” but still got the error below

Here is the screen shot using the commercial DevOps

Below is the error message when I edit (URL and token) or create new entry for government DevOps
I have tried the following URLs

I have checked the web log file, so has others, and nothing was found on the error.
I really don’t know what else to do with this


Hey Jerry.

I’m surprised that there’s nothing in your web.log file that’s relevant. There should be something like the following:

2022.05.03 10:32:05 INFO web[AYCI8Q6y61K4zP0NAAMD][o.s.a.c.a.AzureDevOpsHttpClient] Azure API call to [Azure DevOps Services | Sign In] failed with 404 http code.

Something I noticed just by browsing to these links:

Is that something we would consider as a “self-signed certificate” (not sure if that’s what you would call it when it’s issued by government / defense contractors (as is the case here, where Lockheed Martin appears to be the certificate authority).

If this certificate isn’t trusted by the JVM installation on your server (SSLPoke is a great tool for testing this), you’ll need to update the truststore being used by the Java installation that runs your SonarQube server to trust this certificate.

1 Like

Thanks. I will have to research how to update the trust store

I just reported exactly the same issue here

I have a question that you might be able to clear up. Do we need to have certificate on both the SonarQube and DevOps servers?

Hey Jerry.

The certificate will need to be trusted by any machine trying to get in touch with Azure DevOps. In the case of SonarQube → Azure DevOps interactions, that means you just need to worry about the SonarQube server trusting the certificate for your Azure DevOps instance.

Hey Colin,

We have the certificate installed in the Java cert store and windows cert store but still get the error

Quick Update: we have fixed the issue.
Solution: it seems that if basis authentication is turn on in IIS it breaks the use of PATs

We are now able to connect to our DevOps server in SonarQube after turning off basic authentication in IIS on the DevOps server


Thanks for sharing your solution, I have added a ticket to the backlog to improve the docs on this topic.