Azure DevOps Server On-Premise URL or PAT fails

Good afternoon, I am working on setting up a SonarQube to Azure DevOps Server (on-premise) integration. My base setup information is below:

  • SonarQube Community version
  • Azure DevOps Server 2020
  • Java 11 version (Microsoft OpenJDK build)

Each time I enter my URL and PAT, I receive an error that say the URL or PAT is not correct. I have tried most of what was recommended in Invalid Azure URL or Personal Access Token for ALM Integration - SonarQube - Sonar Community ( with the exception of Wireshark. I have verified that I can access the json output that SonarQube is looking for using the URL from the check pat log entry and my PAT.

I have setup:

  • The CA root cert from our enterprise is in the Java keystore
  • SonarQube is setup to bind to localhost only and is reversed proxied from IIS
    • Firewall rules allow access from a custom port for IIS https reverse proxy
  • Azure DevOps is setup on another server with IIS using http to https redirection
    • Firewall rules allow access from the standard 80/443 ports for IIS

If I use SonarQube over localhost the problem still exists. I see only a small bit of information regarding the request for PAT even with TRACE level logging. Please see the below sample:

2022.04.19 13:57:55 DEBUG web[AYBC+LZQ+xt7G0zHAAAj][o.s.a.c.a.AzureDevOpsHttpClient] check pat : [https:/[server dns]/[collection]/_apis/projects?api-version=3.0]
2022.04.19 13:57:55 TRACE web[AYBC+LZQ+xt7G0zHAAAk][sql] time=0ms | sql=select a.kee as "key", a.uuid as "uuid", a.alm_id as "rawAlm", a.url as "url", a.app_id as "appId", a.private_key as "privateKey", a.pat as "personalAccessToken", a.client_id as "clientId", a.client_secret as "clientSecret", a.created_at as "createdAt", a.updated_at as "updatedAt" from alm_settings a

Older versions of SonarQube had additional logging information that would be relevant according to the post in which I worked through.

Any assistance that anyone has found using Azure DevOps and SonarQube would be most appreciated.


Adam Brousseau

So I worked on this from a different point of view. I pulled down the SonarQube source code and ran the test for the checkPat under the AzureDevOpsHttpClient. Come to find out, the cacerts keystore was not being updated, even though Java indicated that the alias wasn’t properly in there, see below:

"C:\Program Files\java\bin\keytool" -importcert -file C:\mycert.cer -alias enterprise-ca -keystore -cacerts -storepass "secret_password"
Trust this certificate? [no]:  yes
Certificate was added to keystore

"C:\Program Files\java\bin\keytool" -importcert -file C:\mycert.cer -alias enterprise-ca -keystore -cacerts -storepass "secret_password"
keytool error: java.lang.Exception: Certificate not imported, alias <enterprise-ca> already exists

This was run in an administrative command prompt to ensure UAC could not affect writing to the cacerts keystore, but I noticed after further checking that the modification date wasn’t changed. So I used another tool KeyStore Explorer ( which provides a GUI and I have used in the past. I was able to run it as an administrator and successfully was able to update the cacerts with my enterprise CA.

I am leaving this as a note for others that might be going through a similar situation and how I was able to resolve it.

Adam Brousseau



i am also getting same issue. but this solution didn’t work for me .

can you please provide clear steps so that will verify in local if anything missed .

Thank you.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.

Hey folks,

Similarly to what was discussed on this thread, SQ 9.5 now provides better logging to troubleshoot problems with ADO integration.

Would it be possible for you to upgrade to SQ 9.5, and then share those new logs?