LDAPS Fails in SonarQube 7.1 After Working in 6.7.3


(Gash Teshome) #1

After upgrading to SonarQube 7.1, LDAPS fails. The specific error is below.

  • which versions are you using (SonarQube, Scanner, Plugin, and any relevant extension)
    SonarQube 7.1 (Docker image on Kubernetes v1.9.10)
  • what are you trying to achieve
    Authenticate users with LDAPS using Active Directory on SonarQube 7.1
  • what have you tried so far to achieve this
    Use the official Docker 7.1 image with same configuration that worked with 6.7.3


Caused by: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative DNS name matching p******.com found.
	at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
	at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1964)
	at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:328)
	at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:322)
	at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1614)
	at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216)
	at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1052)
	at sun.security.ssl.Handshaker.process_record(Handshaker.java:987)
	at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1072)
	at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1385)
	at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1413)
	at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1397)
	at com.sun.jndi.ldap.Connection.createSocket(Connection.java:394)
	at com.sun.jndi.ldap.Connection.<init>(Connection.java:215)
	... 41 common frames omitted
Caused by: java.security.cert.CertificateException: No subject alternative DNS name matching p******.com found.
	at sun.security.util.HostnameChecker.matchDNS(HostnameChecker.java:214)
	at sun.security.util.HostnameChecker.match(HostnameChecker.java:96)
	at sun.security.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:459)
	at sun.security.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:436)
	at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:200)
	at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:124)
	at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1596)

The error is correct in that the SSL cert returned from AD does not have a Subject Alternative Name (SAN) matching the server address used in the SonarQube configuration. My question is two-fold:

  1. Any ideas what changed between the 6.x and 7.x versions to cause the failure (possibly in a underlying library or JDK?)
  2. Is there a way to turn off SAN checking?

I have reverted to 6.7.3 for the time being.

(Nicolas Bontoux) #2

Hey Gash,

Thanks for the detailed report. The error you’re showing is entirely living in the Java-SSL stack (which SonarQube fully relies upon for SSL interactions), so it does seem like a possible change at the Java layer (are you using the same distro/version with 7.1 than with 6.7.3 ?).

Since it’s potentially unrelated to SonarQube logic itself, it’s worth checking broader recommendations regarding that error, and Atlassian has issued an interesting piece: java.security.cert.CertificateException: No subject alternative DNS name matching <hostname> found .

  1. Fix the certificate to contain the correct name. This is the preferred (and most secure) fix.

As you noted.

  1. Disable “Follow Referrals” in the User Directory configuration, if cross-domain memberships are not used.

Note that LDAP integration also provides control over this (check for referrals in that doc).

f you are using JDK 1.8.0_51 or later (bundled in Confluence 5.8.8 and later), the JDK no longer performs reverse name lookup for IP addresses by default, as per this java doc.

Another good hint at possible changes at the Java layer itself.

(Gash Teshome) #3

Thanks for the quick response Nico. I went through your suggestions without success, unfortunately:

This didn’t change the error. SQ still failed parsing the LDAPS certificate.

I’m using the official image from Docker Hub so I don’t know what JDK was used to build SQ. Based on the Dockerfile, the image downloads one of the prebuilt binaries from the official SonarSource Bintray download site. (https://github.com/SonarSource/docker-sonarqube/blob/4d76dfe9fb4c5d41ba1852cd5072dbff15ca5a20/7.1/Dockerfile). Is there any information on the JDK used to build 7.1?

Anyway, I got around the LDAPS issue by using the actual DNS names of the AD servers responding to the LDAP queries (ldaps://example.com:636 -> ldaps://ad01.example.com:636). I now have 7.1 running in production.

Thank you for your help.

(Nicolas Bontoux) #4

Hi Gash,

Thanks for the heads-up. Regarding your JDK note: given that the error is in the Java layer, as far as I can tell what matters is the JDK locally present at runtime, and not the JDK with which SonarQube was built. And just in case: SonarQube does not ship any embedded Java distro, it fully relies on the one locally installed. In your Docker context that might mean having to understand which JDK is deployed in your container.

Thanks for the follow-through based on DNS-cert update.

(Gash Teshome) #5

Thanks for the clarification on the JDK. I took a look at the Dockerfiles used to build the image for the 6.7.3 version versus the one for 7.1 and can’t figure out why LDAPS behaves differently between the two. Both images use a JDK that is much newer than JDK 1.8.0_51. I’m going to stick with the DNS fix instead of trying to figure out the JDK issue. Thanks for your insight.