SonarLint fail to authenticate with proxy in a HTTPS SonarQube Server request

Hi there,

Before create this post, I made a research to see if some Tips&Tricks would work out, but, unfortunately, none of the things that I tried worked for me.

When configuring SonarLint via Wizard, I checked the Enable Proxy checkbox and went to proxy settings. There, I made all the configurations required and checked connection to At this point the connection is tested successfully. Then, selecting the SonarQube server, I enter the base path of SonarQube ( https://< hostname >/sonar ). In the next step, I used the Login/Password authentication type, entered my credentials and it ended with a message “Failed to connect to the server. Please check the configuration.”

Things I have already tried:

  • Checked with my browser if my https://< hostname >/sonar/api/system/status page is reacheable (and yes, it is working);
  • Installed the UnlimitedJCEPolicyJDK8 downloaded from Oracle site;
  • Imported my certificate as a Trusted Certificate (using keytool);
  • Included in the JVM start configuration;
  • Used Token instead of Login/Password connection (and ended in the same error);
  • Used my https://< hostname >/sonar/ and https://< hostname >/sonar/api/system/status as Check Connection URLs (in the proxy configuration) and both returned OK (proving that my IDE is reaching desired page);
  • Another piece of information: when using Wireshark to look at the package exchange and comparing with the check connection step, seems to me that the step when the wizard tries to connect to the status page is not answering the authentication demand made by the server (as presented in the image attached);

Essential information:

Windows 7 Entreprise
IntelliJ IDEA Version: Ultimate 2018.1 Build#IU-181.5087.20 (May 16, 2018)
SonarQube Server Version: 6.7.4 (build 38452)
SonarLint Plugin Version:

SonarLint Console output:

Connection test failed
java.lang.IllegalStateException: Fail to request https://< hostname >/sonar/api/system/status
at org.sonarsource.sonarlint.core.container.connected.SonarLintWsClient.rawGet(
at org.sonarsource.sonarlint.core.container.connected.validate.ServerVersionAndStatusChecker.fetchServerInfos(
at org.sonarsource.sonarlint.core.container.connected.validate.ServerVersionAndStatusChecker.checkVersionAndStatus(
at org.sonarsource.sonarlint.core.container.connected.validate.ServerVersionAndStatusChecker.checkVersionAndStatus(
at org.sonarsource.sonarlint.core.WsHelperImpl.validateConnection(
at org.sonarsource.sonarlint.core.WsHelperImpl.validateConnection(
at com.intellij.openapi.progress.impl.CoreProgressManager$
at com.intellij.openapi.progress.impl.CoreProgressManager$
at com.intellij.openapi.progress.impl.CoreProgressManager.lambda$runProcess$1(
at com.intellij.openapi.progress.impl.CoreProgressManager.registerIndicatorAndRun(
at com.intellij.openapi.progress.impl.CoreProgressManager.executeProcessUnderProgress(
at com.intellij.openapi.progress.impl.ProgressManagerImpl.executeProcessUnderProgress(
at com.intellij.openapi.progress.impl.CoreProgressManager.runProcess(
at com.intellij.openapi.application.impl.ApplicationImpl.lambda$null$10(
at com.intellij.openapi.application.impl.ApplicationImpl$
at java.util.concurrent.Executors$
at java.util.concurrent.ThreadPoolExecutor.runWorker(
at java.util.concurrent.ThreadPoolExecutor$
Caused by: Failed to authenticate with proxy
at org.sonarsource.sonarlint.shaded.okhttp3.internal.connection.RealConnection.createTunnel(
at org.sonarsource.sonarlint.shaded.okhttp3.internal.connection.RealConnection.connectTunnel(
at org.sonarsource.sonarlint.shaded.okhttp3.internal.connection.RealConnection.connect(
at org.sonarsource.sonarlint.shaded.okhttp3.internal.connection.StreamAllocation.findConnection(
at org.sonarsource.sonarlint.shaded.okhttp3.internal.connection.StreamAllocation.findHealthyConnection(
at org.sonarsource.sonarlint.shaded.okhttp3.internal.connection.StreamAllocation.newStream(
at org.sonarsource.sonarlint.shaded.okhttp3.internal.connection.ConnectInterceptor.intercept(
at org.sonarsource.sonarlint.shaded.okhttp3.internal.http.RealInterceptorChain.proceed(
at org.sonarsource.sonarlint.shaded.okhttp3.internal.http.RealInterceptorChain.proceed(
at org.sonarsource.sonarlint.shaded.okhttp3.internal.cache.CacheInterceptor.intercept(
at org.sonarsource.sonarlint.shaded.okhttp3.internal.http.RealInterceptorChain.proceed(
at org.sonarsource.sonarlint.shaded.okhttp3.internal.http.RealInterceptorChain.proceed(
at org.sonarsource.sonarlint.shaded.okhttp3.internal.http.BridgeInterceptor.intercept(
at org.sonarsource.sonarlint.shaded.okhttp3.internal.http.RealInterceptorChain.proceed(
at org.sonarsource.sonarlint.shaded.okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(
at org.sonarsource.sonarlint.shaded.okhttp3.internal.http.RealInterceptorChain.proceed(
at org.sonarsource.sonarlint.shaded.okhttp3.internal.http.RealInterceptorChain.proceed(
at org.sonarsource.sonarlint.shaded.okhttp3.RealCall.getResponseWithInterceptorChain(
at org.sonarsource.sonarlint.shaded.okhttp3.RealCall.execute(
… 23 more

Thank you and best regards,
David Pereira Barbosa

Hi David,

It is difficult for us to investigate, since there are so many different proxy configurations. Standard HTTP proxy with basic authentication should be supported.

For each connection, SonarLint for Eclipse will look into Eclipse proxy configuration to find the appropriate proxy:

Then this configuration will be passed to the underlying okhttp library we are using to perform all our HTTP request.

Looking at Wireshark, I see NTLMSSP_CHALLENGE in the 407 response, so I gess you are using an NTLM proxy. I’m afraid it is not supported by okhttp, so I don’t think we will be able to help you. I would suggest to configure an exclusion for your SonarQube server so that you can access it without proxy.

Out of curiosity, how are you submitting your analysis? SonarQube Scanners are also using okhttp, so I think they should have the same limitation.

Hi Julien,

I will start easing your curiosity: we are deploying into SonarQube by Jenkins. My goal is to bypass this because for each analysis we need to deploy a build (if we can do it by our IDE would be easier to do better codes).

Just to be sure, I’m using IntelliJ and not Eclipse (I did not opened the source and I don’t know if in your project there is any difference, but, anyways…)

Well, going back to the question, it’s sound a little bit weird to me that IntelliJ accomplish it and the plugin does not. Isn’t there any way to share the connection that IntelliJ uses to it’s addons? Because with that you guys would not be stuck with this kind of situation. I will see what I can do from my side but I’m afraid that my request to configure an exclusion rule will be denied. If you guys can get in touch with JetBrains to see if there is any chance to share the connection, I would appreciate it (and in the end of the day, 99% of the posts about SonarLint fail to authenticate will be answered).

And, btw, looking at the response of the okhttp, they are not interested in doing that (even if someone post the code for them to integrate to their core, which actually did happened in the post). As personal experience, that is not a good partner practice (and may lead to some limitations to your product as well). Anyways…

Thank you and best regards,
David Pereira Barbosa

Sorry for the confusion between IntelliJ and Eclipse. I don’t know how I missed that. But it doesn’t change most of my answer. We are basically doing the same in IntelliJ (trying to get proxy configuration).

Long time ago we were trying to reuse the HTTP client possibly provided by the IDEs to perform SonarLint calls. But it was also causing some issues, since we were unable to control some details like SSL and timeout. And those REST clients are sometimes old and not supporting latest protocol updates.
It was in a period where we were requiring a very specific SSL configuration. Maybe we could reconsider…
But quickly looking at IntelliJ development mailing list, they are suggesting to a plugin developer to ship its own HTTP client:

That doesn’t look like they are encouraging people to reuse their client…

Well, that’s a shame…

Looks like they are not in the mood to do reusable resources. Then we need to redo all the work that they do…well, c’est la vie…

But, (and this is a nice but) I come with good news: I talked to our dev team and we decided to use a reverse proxy. So, when I configure the proxy for SonarLint in the IntelliJ configuration window, I changed the proxy host to this reversed proxy (we are using CNTLM to manage this) and it worked like a charm.

Thank you Julien, and I hope this post can help others too to bypass this special condition.

1 Like

Thanks for sharing this option. I was not aware of CNTLM, it could be of great help in such situation.