I’m seing the exact same issue. But I’m not missing any intermediate certificates.
When SonarQube starts up it prunes the gitlab projects and fails to verify TLS cert.
I downloaded the ssltest (GitHub - ChristopherSchultz/ssltest: A Java-based tool to test SSL connections to servers.) and ran INSIDE the container using the SAME cacerts truststrore where I added my CA-Root-Cert. It succesfully validates my gitlab cert.
I turned on DEBUG logging and I see that sonarqube picks up the same CA-Root-Cert but fails to validate… How can that be?? I have added my CN into the SAN fields. Curl with the --cacert option pointing to the same file I imported into cacerts works as well. Just like all major browsers.
What is going on???
Having the same issue.
My on-prem Gitlab cert validates fine via browsers and also using curl inside the container (running sonarqube under Docker). curl --cacert against my gitlab instance validates fine. Added the same root-cert to the keystore under /usr/lib/jvm/java-11-openjdk/lib/security/. Restarted the container but still the same issue. No intermidiate certs exists.
Downloaded a TLS/SSL testing tool
Checking what java binaries are used inside the container…
# ps -ef
PID USER TIME COMMAND
1 sonarqub 0:07 java -jar lib/sonar-application-184.108.40.206531.jar -Dsonar.log.console=true
37 sonarqub 0:37 /usr/lib/jvm/java-11-openjdk/bin/java -XX:+UseG1GC -Djava.io.tmpdir=/opt/sonarqube/temp -XX:ErrorFile=../logs/es_hs_err_pid%p.log -Des.networkaddress.cache.ttl=60 -De
151 sonarqub 0:31 /usr/lib/jvm/java-11-openjdk/bin/java -Djava.awt.headless=true -Dfile.encoding=UTF-8 -Djava.io.tmpdir=/opt/sonarqube/temp -XX:-OmitStackTraceInFastThrow --add-opens=j
201 sonarqub 0:19 /usr/lib/jvm/java-11-openjdk/bin/java -Djava.awt.headless=true -Dfile.encoding=UTF-8 -Djava.io.tmpdir=/opt/sonarqube/temp -XX:-OmitStackTraceInFastThrow --add-opens=j
Trying against gitlab which is added to the truststore… works
bash-5.1# /usr/lib/jvm/java-11-openjdk/bin/java -jar ssltest.jar -showsslerrors -check-certificate gitlab.xxxx.net:443
Testing server gitlab.xxxx.net:443
Supported Protocol Cipher
Accepted TLSv1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
Accepted TLSv1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
Accepted TLSv1.3 TLS_AES_128_GCM_SHA256
When I try against a server with self-signed it fails as expected…
bash-5.1# /usr/lib/jvm/java-11-openjdk/bin/java -jar ssltest.jar -showsslerrors -check-certificate web01.xxxx.net:443
Testing server web01.xxxx.net:443
Supported Protocol Cipher
Untrusted TLSv1.2 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
Server certificate is not trusted. All other connections will fail similarly.
Server certificate is not trusted, cannot complete handshake. Try -no-check-certificate
So whats up with SonarQube???
I’ve moved your topic (and posts on other threads) into its own post.
If I had to make a guess, the reverse proxy sitting in front of your SonarQube server (responsible for serving it over HTTPS) only accepts the
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 cipher, which is relatively new and might not be trusted on older versions of Java 11 (I believe it became trusted in 11.0.13)
You might want to expand the list of cipher suites, or make sure you are using the latest version of Java 11 when connecting to your SonarQube server.