Invalid Azure URL or Personal Access Token for ALM Integration

Hi @Sylvain_Combe

  1. According to the logs I am using TLS 1.2
  2. I added the javaAdditionalOpts to my (but since I am using TLS 1.2 in the first place, I think, it does not have an effect on it)

How did you come to the conclusion that I use JRE ? I use the OpenJDK 11.0.2.
When I run “java -version” I get:
openjdk version “11.0.2” 2019-01-15
OpenJDK Runtime Environment 18.9 (build 11.0.2+9)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode)

I “simply” use the downloaded and extracted zip folder from OpenJDK as JAVA_HOME. And until now that work fine, my SonarQube Server is running, etc.

When I run the sslpoke specifically with the java.exe in my sdk folder I also get this:

java.version: System: 11.0.2
java.vendor: System: Oracle Corporation
policy.allowSystemProperty: Security: true
security.provider.1: Security: SUN
jdk.tls.disabledAlgorithms: Security: SSLv3, RC4, DES, MD5withRSA, DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL
jdk.tls.legacyAlgorithms: Security: K_NULL, C_NULL, M_NULL, DH_anon, ECDH_anon, RC4_128, RC4_40, DES_CBC, DES40_CBC, 3DES_EDE_CBC
keystore.type: Security: pkcs12
keystore.type.compat: Security: true
jdk.certpath.disabledAlgorithms: Security: MD2, MD5, SHA1 jdkCA & usage TLSServer, RSA keySize < 1024, DSA keySize < 1024, EC keySize < 224

Successfully connected.
Protocol: TLSv1.2
Cipher suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

Is there anything wrong with how I used the sslpoke or my java sdk in general ?

What might be important to know: Our Azure DevOps runs via https and the SonarQube Server via http. We dont really think that might be an issue with this, but maybe it’s usefull to know :slight_smile:


Hi @chauser
your SSL Poke output seemed to indicate a different (Oracle) JRE but it’s probably due to your older AdoptOpenJDK version, here is what I get with version

java.version: System:
java.vendor: System: AdoptOpenJDK

I would still recommend that you upgrade your Java version because this is a Security good practice and because it may remove those annoying warning messages. But now I doubt it will fix your Azure connectivity.
And for next step, I believe you should look into your Azure Devops side to try to understand why the SonarQube requests are rejected while your PAT is valid. If you have no other service or scripts using PATs, maybe you should have a look at this page.

Best regards

Hi @Sylvain_Combe,

after analyzing what happens in my Azure DevOps side via Wireshark, there actually seems to be an error on the TCP level. Here’ s screenshot of what i get (reproducible):

Important to know:
Sonarqube →
DevOps →

As it seems to me, Sonar send its request via port 50432 to the 443 (SSL) Port of DevOps. But the DevOps Server then cannot answer correctly because the port 50432 seems to be closed to it.
(Thats what I get, when googling the [RST,ACK] error).
I dont know if this area is your expertise, but would you agree ?

Problem here is, that when I send another request, the SonarQube port changes dynamically (e.g 50465). So simply allowing this port via Windows firewall would’t change my problem.
Can I set a fixed port for the SonarQube application requests and allow the firewall this port to be open, and is that a good/common practice ?

Am I correct in my assumptions and what would you recommend ?


Hello @chauser
this could be rapidly become too complex for me :slight_smile:
So my first advice would be to hire some help from a network engineer, if you have one available.

Then to your question about client port, the answer is no; I don’t know of any way to set the client port for SonarQube and I don’t think this should be necessary for such an https connection. The standard is to have a free port chosen ‘randomly’ by the client when the socket is opened.
And in your wireshark screenshot, I see no evidence of a firewall at play, the TCP connectivity is up and TLS handshake almost done when the TCP connection is closed by the DevOps server, with the RST in frame 351. Do you have any log about this failed connection on the DevOps side?

What are the differences between this TLS handshake and the one done successfully with SSL Poke?

Hello @Sylvain_Combe,

thank you for your answer.
I am currently in talks with our network administrator, he also can’t really find a solution here.

What we did now, was to establish our SonarQube Server as HTTPS via reverse proxy as shown here :Operating the Server | SonarQube Docs
We we’re hoping that this might solve our problem, but sadly it didn’t change the error message in Wireshark.
But there is still a funny phenomenon:
When sending out the sslpoke, I get the this console message

Successfully connected.
Protocol: TLSv1.2
Cipher suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

But in wireshark I see the same error as above, when using the SonarQube UI, with one big difference. the Application Data Protocol is http-over-tls

When using the SonarQube UI the Application Data Protocol is “http2” ? Could this be the problem ?

Also, (to double check) we are using a Confluence Server doing these kind of requests to the DevOps Server as well, getting successfull acknownledgements [FIN,ACK], also using http-over-tls

We’re kind of stuck here :confused:

Hello @chauser
I don’t think you get the same wireshark capture with your successful SSL Poke. In this case, it’s the SSL Poke client which sends the first RST, which is fine: the connection is successfully established, it closes the ‘line’.
I still have a few ideas for things to try or check:

  • increasing the logs for SSL with added to the sonar.web.javaAdditionalOpts on SonarQube side
  • you can test SSL Poke from within your SonarQube system or docker container to reproduce the problem (or not), while making sure to use the same JRE and SSL settings
  • Checking the logs on Azure Devops side to see if it tells why it is closing the connection
  • sharing your SonarQube configuration file ( or docker-compose) so that I can check it as well (anonymise any address before sharing).


Hello @Sylvain_Combe ,

after a couple of days I want to give you an update now.
What we have done now was simply resetting our entire server and reinstall
everything from scratch so we can see what happens after a minimal installation and nothing else.
What we now have is our SonarQube Server Version 8.9.0 (http) without any IIS or ReverseProxy running and the Azure DevOps Server (https).
When trying to use the ALM Integration, the same error occurs:
On wireshark we get the same thing as we did with the “old” server

Still the Application Data Protocol is http2

When doing the SSLPoke with the same JDK the protocol is “http-over-ssl”.
I still dont know, if thats the reason, but it’s the most recognizable difference.

What we see, that neither IIS nor the java environment can be the cause, but the application itself.
One last idea: Does the user of the SonarQube service matter ? By now, we run it with local account.

Our properties file looks like this:


with all other properties commented out. But I don’t know, if there is anything there for you to see. The LDAP connection and everything else is working fine…


Hello @chauser
thanks for this extensive report and all this effort to make this work.
Would you be able to add to the sonar.web.javaAdditionalOpts and sonar.web.javaAdditionalOpts in your file, restart (full command line restart) and let me know of the outcome?

Best regards

Hello @Sylvain_Combe ,

thanks for the hint.
I set my sonar.web.javaAdditionalOpts=, but it didn’t change the outcome, I still get the RST ACK and the dynamic port seems to be closed.
I also tried to set this to sonar.ce.javaAdditionalOpts and, just to cover all my bases and tried all of this via service as well as the console, but sadly, it didn’t help.

Also on the Azure DevOps part, there is no warning etc. in the IIS Log or the Windows Event Log that can be connected to the error.


Hi @chauser
I don’t want to leave thread unresolved.
Would you be able to run this test once again with maximum verbosity (TRACE level) and send me your SonarQube logs (compressed) and your privately so that I can have a closer look at what is happening?


Hi @Sylvain_Combe,

thank you for the offer. I’d happily send you all the information. How can I send you something privately without pasting it in the forum ?
From my understanding, I dont have the needed trust level


Hi @chauser

Can you try HTTP instead if HTTPS temporally and send the wireshark stream to see what is happening ?


Hello @Mathieu_Suen,

We have links like this:


We tried with http as well but it does not work:

Invalid Azure URL or Personal Access Token

it is included also:
in sonarqube config file.

Any workaround on this?


We also have checked the Java version 11.x, just in case, and seems to be ok.
Any advice about this?
Thanks in advance.

We were getting the same error in SonarQube and finally found fix to our problem.
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

1 Like

Hi Jerry, could you please elaborate how this was fixed? how did u turn off basic authentication in azure devops?

Hi @chauser , was this issue fixed? could you please help me with steps you have followed? currently we are facing this and this had blocked our progress.

We have a VM where SonarQube is running so we had to turn of basic authentication in IIS on the VM
Hope this helps

Hi Jerrry ledet,

I had turned off the basic authentication on Azure devops server and SonarQube server but still it is throwing same error. could you please help me on this.

Hi @DeadPool ,
You will probably get a better response if we know what you have tried already and what error shows in your logs:

  • Copy of entire stack trace of error in SonarQube server logs at DEBUG level (you can download it from Administration > System > Download Web Server logs)
  • Results of running curl to the ADO server
  • Checking your proxy settings (if you have a proxy) in $SQ_HOME/conf/ file

I suggest you create a new thread with all this information so others can help you in a better manner.