I am running sonar-scanner as a pod/container in a kubernetes cluster. This is part of a gitlab-runner pipeline. I am running this same image in 3 different environments. One of these environments is air-gapped from commercial internet and that is the one that is failing.
Unfortunately this is a secure environment where I cannot pull log data and bring it into this forum, but let me use my working environments to try and help explain.
20:14:55.933 INFO SonarScanner CLI 6.2.1.4610
20:14:55.935 INFO Java 17.0.14 Red Hat, Inc. (64-bit)
20:14:55.935 INFO Linux 4.18.0-553.83.1.el8_10.x86_64 amd64
20:14:55.961 INFO User cache: /opt/sonar-scanner/.sonar/cache
20:14:56.689 INFO JRE provisioning: os[linux], arch[x86_64]
20:14:56.971 INFO Communicating with SonarQube Server 10.7.0.96327
20:14:57.248 INFO Starting SonarScanner Engine…
20:14:57.249 INFO Java 17.0.11 Eclipse Adoptium (64-bit)
20:14:57.893 INFO Load global settings
20:14:58.152 INFO Load global settings
This is as far as the secure scanner will get before it errors out with a “Failure to open URL: https://sonarqube.secure.com/settings/values.protobuf” (paraphrased) and then some errors further on about TrustManagers not trusting the cert and PKIX path issues.
Sounds like a cut and dry keystore issue with missing certs, but it is not.
I added “-Djavax.net.debug=”ssl,handshake” -X to my command line and it revealed that there are 3 successful secure connection attempts to that exact domain (all with “200” return codes) before it gets to the 4th connection attempt that fails with a “401” return code. Here are all the URL’s attempted with the return code that was received:
https://sonarqube.secure.com/api/v2/analysis/version (200)
https://sonarqube.secure.com/api/v2/analysis/jres?os=linux&arch=x86_64 (200)
https://sonarqube.secure.com/api/v2/analysis/engine (200)
https://sonarqube.secure.com/api/settings/values.protobuf (401)
So how is this possible? Why is it happening?
One difference in this environment is that the secure domain uses a certificate that is signed by 3 CA’s. One root, and 2 intermediate CA’s. Thats really the only difference I can think of. Maybe the part of sonar-scanner that loads settings is not capable of supporting a chain more than 2 certs in length?
I have tried many things to isolate the issue, even making a new keystore with just the 3 certs and forcing sonar-scanner to load it with “SONAR_SCANNER_OPTS”. It does not fix the issue.
I also tried to tell sonar-scanner to ignore the cert verification with “-Dsonar.scanner.skip.ssl.verification=true” and “-Dsonar.skip.ssl.verification=true” but neither appear to be valid or work in this instance.