Cloudbreak UI LDAPS Exception

[#1]

I have successfully configured my cloudbreak UI to authenticate logins with our AD servers using LDAP and that works fine. However when I try to use the LDAPS protocol, I get a certificate path error. I have imported my trust chain into the cacerts truststore AND used the update-ca-trust utility. But when I try to login the uaa.log shows an cert path exception (see below).

My questions are, what truststore is being used? What client cert is the LDAPS process presenting?

Thanks in advance.

[2019-03-28 16:53:17.378] cloudfoundry-identity-server - ???? [http-nio-8080-exec-4] .... ERROR --- UsernamePasswordAuthenticationFilter: org.springframework.security.authentication.InternalAuthenticationServiceException: simple bind failed: its-ad-ldap.it.example.com:636; nested exception is javax.naming.CommunicationException: simple bind failed: its-ad-ldap.it.example.com:636, [Root exception is 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]

[#2]

Hi,

Please add the following property to your uaa-changes.yml file:

ldap:
  ssl:
    skipverification: "true"

[#3]

What does that do? Feels vulnerable.

[#4]

LDAPS connection will not validate the server certificate. If you feel uncomfortable to use this attribute, you can also import the certificate to JVM's trust store in the identity container:

keytool -import -alias "$cert" -noprompt -file "$TRUSTED_CERT_DIR/$cert" -keystore /etc/ssl/certs/java/cacerts -storepass changeit;

[#5]

You might also add the certificate alias to you uaa-changes.yml file: https://github.com/cloudfoundry/uaa/blob/releases/3.6.14/uaa/src/main/resources/uaa.yml#L91

[#6]

Found it...not ideal...

ssl: {

• skipverification: {
  • *value: "<uaa.ldap.ssl.skipverification>",
  • *sources: {
    • uaa.ldap.ssl.skipverification: "Set to true, and LDAPS connection will not validate the server certificate."
  • }
• },

[#7]

Your other options would be to either use a trusted certificate (assuming currently you have a self-signed cert) or adding the certificate to JVM's trust store in the identity container as I stated in my other reply.