Invalid Azure URL or Personal Access Token for ALM Integration

Trial Developer Edition SonarQube Version: 8.6.1.40680

Trying to configure Azure DevOps Server ALM configuration and get the following:
image

Following is the network traffic:
image

I have tried resetting my PAT in Azure DevOps Server 2019 and insured the server URL was correct.

Of note - Azure DevOps and SonarQube are running on the same server. DevOps is accessible via HTTPS only and SonarQube is accessible via HTTP only. Is this the possible cause?

Thank you…troy

1 Like

I’m having the same issues, with the dame Dev version of the software, but I’m using Azure DevOps 2020

Same issue here. Azure Devops 2020 On-Prem

Hello @TroyG , @DotNetDeveloper and @teriansilva
Let me post a preliminary answer here for our community.
The “Invalid Azure URL or Personal Access Token” message is shown in the UI for any problem related to your PAT or AzDO URL you have set or, and that is important, to SonarQube connectivity to your Azure Devops.

In order to know which, on SonarQube 8.7, you need to

  • turn on the DEBUG logs for the SonarQube WEB component (in Administration → System page)
  • check your Azure Configuration again
  • open the web.log file and search for the “check pat” line as follows

The line(s) are shaped as follows (on SonarQube 8.7):

2021.03.11 08:06:53 DEBUG web[AXgBwW+6J0z4dDrXABFO][o.s.a.c.a.AzureDevOpsHttpClient] check pat : [<Azure URL>]

About 20 other DEBUG lines about http/https connectivity follow and the block ends with

2021.03.11 08:06:54 DEBUG web[AXgBwW+6J0z4dDrXABFO][o.s.a.c.a.AzureDevOpsHttpClient] Unable to contact Azure DevOps server: <Azure URL> 401

If you are in this case the remediation is probably simple; you need to fix the URL or the PAT you have set according to SonarQube documentation.
You need to make sure PATs are allowed with your Azure Devops setup too: IIS Basic Authentication invalidates using PATs - Azure DevOps | Microsoft Docs

In case you only see the initial line, then it means SonarQube is unable to establish the http/https connectivity to the address you have configured. A few root cause to investigate:

  • the address is unresolved in the context of your SonarQube instance (docker?)
  • SonarQube is unaware of some needed proxy for this connection
  • SonarQube (JVM) does not trust the certificate shown by the AzDO service (e.g. established by a corporate CA)

In order to confirm in which situation you are, you may use simple curl command lines, and then use some simple Java https client to check the JVM TrustStore and Java proxy settings.
Parameters for proxy and JVM TrustStore can be set either with your sonar.properties or with the environment variables (Docker case).

Side note about OCSPs / CRLs:
If your PKI issues some CRLs or OCSPs, the addresses for these services should also be reachable.

Sylvain

1 Like

Hi @Sylvain_Combe,

thank you for the extensive answer.
Sadly, we have the exact same problem.

Edition: Developer Edition Version 8.9 (build 43852)

I have the case, that I only see the initial line, so I am pretty sure SonarQube is unable to establish the http/https connectivity to the address (Sonar is http, Azure DevOps is https).
The URL is our Azure DevOps Server 2020 containing our collection at the end.
The first 2 reason you gave do not apply to my situation: I am not using docker nor there is a proxy for our DevOps Connection.
Our (https) Azure DevOps Server Service has a certificate established by our corporate CA (the certificate is the correct one and is used by other services which connect without any problem). This root certificate is deposited in the cacerts of the used jdk (11) on the SonarQube Server.

I am setting java in the wrapper.conf (wrapper.java.command=C:\Program Files (x86)\Java\bin\java), “C:\Program Files (x86)\Java” is set as JAVA_HOME.
So we basically think, that we are doing everything correctly.

The only funny thing, that I am getting is a java exception in my main process log:

avax.net.ssl|WARNING|1C|http-nio-172.20.13.40-80-exec-5|2021-06-28 14:46:07.677 CEST|SSLSocketImpl.java:494|SSLSocket duplex close failed (
“throwable” : {
java.net.SocketException: Socket is closed
at java.base/java.net.Socket.shutdownInput(Socket.java:1521)…

strangely enough this exception is only thrown occasionly, but maybe could be connected the our problem.

Could you give me any further advice, what to look for ?

  • Is it important which user is setting up the connection ? (I can use my LDAP User with admin rights or the dedicated admin user)
  • Is maybe a certain port needed ?

We pretty much run out of ideas, because we think, we ware doing everything correctly accordung to the documentation :slight_smile:

If you need any more information (logs,etc.), please let me know
Thanks in advance

Claudius

Hello @chauser
did you try using a java SSL test applications in order to validate your SSL connectivity, from your SonarQube host?
There are many around; I have been using klasen / sslpoke lately.

Could you give me any further advice, what to look for ?
Is it important which user is setting up the connection ? (I can use my LDAP User with admin rights or the dedicated admin user)
Is maybe a certain port needed ?

No, the SonarQube user does not matter, only the PAT you use.
And no, you should not need to worry about ports for this connectivity, SonarQube is the client.

Last advice: SonarQube 8.9.1 fixes SONAR-14870 which has been causing some trouble with some repository connectivity. You may give it a try as well.

Sylvain

Hl @Sylvain_Combe ,
I have tried the sslpoke.
Luckily when I run the command “java -jar sslpoke.jar ourdevopsserver 443” within our SonarQube Server, I get the response that the connection is good:

java.version: System: 11.0.2
java.vendor: System: Oracle Corporation
policy.allowSystemProperty: Security: true
java.security.policy:
CertPathValidator.PKIX:
cert.provider.x509v1:
java.protocol.handler.pkgs:
security.provider.1: Security: SUN
ssl.ServerSocketFactory.provider:
ssl.SocketFactory.provider:
jdk.tls.client.protocols:
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
jdk.tls.ephemeralDHKeySize:
jsse.enableSNIExtension:
https.cipherSuites:
https.protocols:
sun.security.ssl.allowUnsafeRenegotiation:
sun.security.ssl.allowLegacyHelloMessages:
keystore.type: Security: pkcs12
keystore.type.compat: Security: true
javax.net.ssl.trustStore:
javax.net.ssl.trustStorePassword:
javax.net.ssl.trustStoreType:
javax.net.ssl.keyStore:
javax.net.ssl.keyStorePassword:
javax.net.ssl.keyStoreType:
CertPathValidator.PKIX:
jdk.certpath.disabledAlgorithms: Security: MD2, MD5, SHA1 jdkCA & usage TLSServer, RSA keySize < 1024, DSA keySize < 1024, EC keySize < 224
jdk.security.caDistrustPolicies:
com.sun.net.ssl.checkRevocation:
com.sun.security.enableCRLDP:
com.sun.security.crl.timeout:
sun.security.certpath.ldap.cache.lifetime:
com.sun.security.enableAIAcaIssuers:
ocsp.enable:
ocsp.responderURL:
ocsp.responderCertSubjectName:
ocsp.responderCertIssuerName:
ocsp.responderCertSerialNumber:
http.nonProxyHosts:
https.protocols:
https.proxyHost:
https.proxyPort:
java.security.debug:
javax.net.debug:

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

Fun Fact: When I run the same command from my local computer I cannot connect which a handshake exception:
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
Despite the fact that both our SonarQube Server and my computer use the same root CA certificate :thinking:

So I am going to install the new version you recommended and give you feedback whether my problem could be solved with that.

Thank you so far

Hello @chauser
any news?
I was thinking that you may look into the JRE version you use, 11.0.2 is rather old and may be more permissive than newer versions.

Hello @Sylvain_Combe

First I got the Version 8.9.1 to run, but I got the same error when checking the configuration in the Web UI.
But since I have another issue with this version, making it inconsistent to use, I briefly went back to the 8.9.0 version (since the 8.9.1 version doesnt seem to solve my problem in the first place)

javax.net.ssl|WARNING|29|http-nio-172.20.13.40-80-exec-6|2021-07-01 11:57:09.927 CEST|SSLSocketImpl.java:494|SSLSocket duplex close failed (
"throwable" : {
  java.net.SocketException: Socket is closed
  	at java.base/java.net.Socket.shutdownInput(Socket.java:1521)
  	at java.base/sun.security.ssl.BaseSSLSocketImpl.shutdownInput(BaseSSLSocketImpl.java:218)
  	at java.base/sun.security.ssl.SSLSocketImpl.shutdownInput(SSLSocketImpl.java:651)
  	at java.base/sun.security.ssl.SSLSocketImpl.bruteForceCloseInput(SSLSocketImpl.java:606)
  	at java.base/sun.security.ssl.SSLSocketImpl.duplexCloseOutput(SSLSocketImpl.java:566)
  	at java.base/sun.security.ssl.SSLSocketImpl.close(SSLSocketImpl.java:479)
  	at okhttp3.internal.Util.closeQuietly(Util.kt:498)
  	at okhttp3.internal.connection.RealConnection.connectTls(RealConnection.kt:430)
  	at okhttp3.internal.connection.RealConnection.establishProtocol(RealConnection.kt:337)
  	at okhttp3.internal.connection.RealConnection.connect(RealConnection.kt:209)
  	at okhttp3.internal.connection.ExchangeFinder.findConnection(ExchangeFinder.kt:226)
  	at okhttp3.internal.connection.ExchangeFinder.findHealthyConnection(ExchangeFinder.kt:106)
  	at okhttp3.internal.connection.ExchangeFinder.find(ExchangeFinder.kt:74)
  	at okhttp3.internal.connection.RealCall.initExchange$okhttp(RealCall.kt:255)
  	at okhttp3.internal.connection.ConnectInterceptor.intercept(ConnectInterceptor.kt:32)
  	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
  	at okhttp3.internal.cache.CacheInterceptor.intercept(CacheInterceptor.kt:95)
  	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
  	at okhttp3.internal.http.BridgeInterceptor.intercept(BridgeInterceptor.kt:83)
  	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
  	at okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(RetryAndFollowUpInterceptor.kt:76)
  	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
  	at okhttp3.internal.connection.RealCall.getResponseWithInterceptorChain$okhttp(RealCall.kt:201)
  	at okhttp3.internal.connection.RealCall.execute(RealCall.kt:154)
  	at org.sonar.alm.client.azure.AzureDevOpsHttpClient.doCall(AzureDevOpsHttpClient.java:100)
  	at org.sonar.alm.client.azure.AzureDevOpsHttpClient.doGet(AzureDevOpsHttpClient.java:96)
  	at org.sonar.alm.client.azure.AzureDevOpsHttpClient.checkPAT(AzureDevOpsHttpClient.java:68)
  	at org.sonar.server.almsettings.ws.ValidateAction.validateAzure(ValidateAction.java:114)
  	at org.sonar.server.almsettings.ws.ValidateAction.doHandle(ValidateAction.java:106)
  	at org.sonar.server.almsettings.ws.ValidateAction.handle(ValidateAction.java:83)
  	at org.sonar.server.ws.WebServiceEngine.execute(WebServiceEngine.java:110)
  	at org.sonar.server.platform.web.WebServiceFilter.doFilter(WebServiceFilter.java:84)
  	at org.sonar.server.platform.web.MasterServletFilter$GodFilterChain.doFilter(MasterServletFilter.java:139)
  	at org.sonar.server.platform.web.SonarLintConnectionFilter.doFilter(SonarLintConnectionFilter.java:66)
  	at org.sonar.server.platform.web.MasterServletFilter$GodFilterChain.doFilter(MasterServletFilter.java:139)
  	at org.sonar.server.platform.web.MasterServletFilter.doFilter(MasterServletFilter.java:108)
  	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
  	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
  	at org.sonar.server.platform.web.UserSessionFilter.doFilter(UserSessionFilter.java:81)
  	at org.sonar.server.platform.web.UserSessionFilter.doFilter(UserSessionFilter.java:68)
  	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
  	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
  	at org.sonar.server.platform.web.CacheControlFilter.doFilter(CacheControlFilter.java:76)
  	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
  	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
  	at org.sonar.server.platform.web.SecurityServletFilter.doHttpFilter(SecurityServletFilter.java:76)
  	at org.sonar.server.platform.web.SecurityServletFilter.doFilter(SecurityServletFilter.java:48)
  	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
  	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
  	at org.sonar.server.platform.web.RedirectFilter.doFilter(RedirectFilter.java:58)
  	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
  	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
  	at org.sonar.server.platform.web.RequestIdFilter.doFilter(RequestIdFilter.java:66)
  	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
  	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
  	at org.sonar.server.platform.web.RootFilter.doFilter(RootFilter.java:62)
  	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
  	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
  	at org.apache.catalina.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:109)
  	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
  	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
  	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:199)
  	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:97)
  	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:544)
  	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:143)
  	at ch.qos.logback.access.tomcat.LogbackValve.invoke(LogbackValve.java:256)
  	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:81)
  	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:78)
  	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:353)
  	at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:616)
  	at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
  	at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:831)
  	at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1629)
  	at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
  	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
  	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
  	at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
  	at java.base/java.lang.Thread.run(Thread.java:834)}

I am using open the OpenJDK 11, based on the requirements heire

https://docs.sonarqube.org/latest/requirements/requirements/

but I could surely try to use a newer version. But what version would you recommend. What is the highest version I could try ?

Here, your colleague Ann says, it can’t go higher than 11. Is that correct ?
Thanks

Hi @chauser
your successful sslpoke test was run using an Oracle JRE 11.0.2 while your SonarQube is using an OpenJDK (version?). You should align before concluding on this particular test.

And I’ve found an interesting thread about such error, maybe you could:

  1. look into the SSL debug logs to check whether TLS 1.3 is not used
  2. try the suggestes work around (through the sonar.web.javaAdditionalOpts parameter in your sonar.properties file)
  3. upgrade your SonarQube host with the latest OpenJDK 11

Let me know.

Hi @Sylvain_Combe

  1. According to the logs I am using TLS 1.2
  2. I added the javaAdditionalOpts to my sonar.properties (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
java.security.policy:
CertPathValidator.PKIX:
cert.provider.x509v1:
java.protocol.handler.pkgs:
security.provider.1: Security: SUN
ssl.ServerSocketFactory.provider:
ssl.SocketFactory.provider:
jdk.tls.client.protocols:
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
jdk.tls.ephemeralDHKeySize:
jsse.enableSNIExtension:
https.cipherSuites:
https.protocols:
sun.security.ssl.allowUnsafeRenegotiation:
sun.security.ssl.allowLegacyHelloMessages:
keystore.type: Security: pkcs12
keystore.type.compat: Security: true
javax.net.ssl.trustStore:
javax.net.ssl.trustStorePassword:
javax.net.ssl.trustStoreType:
javax.net.ssl.keyStore:
javax.net.ssl.keyStorePassword:
javax.net.ssl.keyStoreType:
CertPathValidator.PKIX:
jdk.certpath.disabledAlgorithms: Security: MD2, MD5, SHA1 jdkCA & usage TLSServer, RSA keySize < 1024, DSA keySize < 1024, EC keySize < 224
jdk.security.caDistrustPolicies:
com.sun.net.ssl.checkRevocation:
com.sun.security.enableCRLDP:
com.sun.security.crl.timeout:
sun.security.certpath.ldap.cache.lifetime:
com.sun.security.enableAIAcaIssuers:
ocsp.enable:
ocsp.responderURL:
ocsp.responderCertSubjectName:
ocsp.responderCertIssuerName:
ocsp.responderCertSerialNumber:
http.nonProxyHosts:
https.protocols:
https.proxyHost:
https.proxyPort:
java.security.debug:
javax.net.debug:

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:

Claudius

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 11.0.9.1:

java.version: System: 11.0.9.1
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
Sylvain

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 → 172.20.13.40
DevOps → 172.20.14.3

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 ?

Cheers
Claudius

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 -Djavax.net.debug 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 (sonar.properties or docker-compose) so that I can check it as well (anonymise any address before sharing).

Sylvain

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:
image
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:

sonar.jdbc.username=**********
sonar.jdbc.password=**********
sonar.jdbc.url=jdbc:sqlserver://ourServer;databaseName=***************
sonar.web.host=IPAdresse_of_sonar_server
sonar.web.port=80
sonar.security.realm=LDAP
ldap.url=ldap://ourldapserver:389
ldap.bindDn=CN=ourCN,OU=ourOU,OU=ourOU,OU=ourOU,DC=ourDC,DC=ourDC
ldap.bindPassword=***********************
ldap.authentication=simple
ldap.user.baseDn=DC=ourDC,DC=ourDC
ldap.user.request=(&(objectClass=user)(sAMAccountName={login}))
ldap.user.realNameAttribute=cn
ldap.user.emailAttribute=mail
ldap.group.baseDn=OU=ourDC,OU=ourOU,OU=ourOU,OU=ourOU,DC=ourDC,DC=ourDC
ldap.group.request=(&(objectClass=group)(member={login}))
ldap.group.idAttribute=sAMAccountName
sonar.updatecenter.activate=false
sonar.path.data=es_data
sonar.path.temp=es_temp

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…

Cheers

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

Best regards
Sylvain

Hello @Sylvain_Combe ,

thanks for the hint.
I set my sonar.web.javaAdditionalOpts= -Dcom.sun.net.ssl.checkRevocation=false, 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 sonar.search.javaAdditionalOpts, 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.

Regards
Claudius

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 sonar.properties privately so that I can have a closer look at what is happening?

Thanks
Sylvain