Invalid Azure URL or Personal Access Token for ALM Integration

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

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

Thanks
Claudius

Hi @chauser

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

Best

Hello @Mathieu_Suen,

We have links like this:

https://tfs/Dev/Example/_git/Sonarqube
https://tfs.example.corpo.local/Sonarqube

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

Invalid Azure URL or Personal Access Token

it is included also:
sonar.web.javaAdditionalOpts= -Dcom.sun.net.ssl.checkRevocation=false
in sonarqube config file.

Any workaround on this?

Thanks

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