Created 03-29-2019 04:11 AM
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]
Created 04-01-2019 01:52 PM
Please add the following property to your uaa-changes.yml file:
ldap: ssl: skipverification: "true"
Created 04-01-2019 02:14 PM
What does that do? Feels vulnerable.
Created 04-01-2019 02:19 PM
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;
Created 04-02-2019 12:09 PM
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
Created 04-01-2019 03:14 PM
Found it...not ideal...
Created 04-01-2019 04:33 PM
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.