Java 8u181 (Java 8 Update 181) enhances security around LDAPS connections:

Change: Improve LDAP support Endpoint identification has been enabled on LDAPS connections. To improve the robustness of LDAPS (secure LDAP over TLS ) connections, endpoint identification algorithms have been enabled by default. Note that there may be situations where some applications that were previously able to successfully connect to an LDAPS server may no longer be able to do so. Such applications may, if they deem appropriate, disable endpoint identification using a new system property: com.sun.jndi.ldap.object.disableEndpointIdentification. Define this system property (or set it to true) to disable endpoint identification algorithms. JDK-8200666 (not public)

One of these enhancements seem to be checking that the domain name is on the certificate. However, the default behavior of Active Directory seems to be to only have the name for the AD server that happens to be returned under the many A records of the AD domain name - and it seems rare that clients will support a list of hosts.

I also see this pattern outside of Java (i.e. Go programs will check this now as well see Go 1.10 release notes on Certificate.Verify).

There is a somewhat intimidating technet article on getting names on the cert in a way that will be renewed: https://blogs.technet.microsoft.com/russellt/2016/06/03/custom-ldap-certs/

I'm sure I'm not the only one here running into this:

  1. Has anyone had success in either adding the name to the cert, or maybe using a load balancer in front of LDAPS for generic non-AD specific LDAP clients?
  2. Does anyone know if Microsoft is on this issue in any way that might have changes coming in the future that make "disable verification and wait" a sane tactic?

bumped to the homepage by Community 15 hours ago

This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.

  • lol, and also Impacting my Internal Jira instance - noticed as I went to update our Internal Jira ticket on this issue :P – Kyle Brandt Sep 7 '18 at 15:27
  • Hmm... openssl says the cert is notBefore=Sep 6 18:10:18 2018 GMT so it is possible there has been a change and I am conflating things, is the AD domain name usually on the ldaps cert? – Kyle Brandt Sep 7 '18 at 15:50
  • I've always had multiple SAN's for DC certs, but not for this reason. – Greg Askew Sep 7 '18 at 20:45
  • Also, I believe the reason we have multiple SANs was due to the introduction of the setting "Require strict KDC validation", which is where the client validates the identity of the domain controller/name/correct cert EKU's it is connecting to (in smart card environments at least). – Greg Askew Sep 7 '18 at 22:44

We hit the same issue and there are few solutions to fix this.

Root cause: It would only NOT work when you use the pool hostname.

  • Fix 1: Include -Dcom.sun.jndi.ldap.object.disableEndpointIdentification=true to your application JAVA_OPTS and restart the tomcat/application server. This is to avoid strict end point verification.

  • Fix 2: Use the exact host name (FQDN) mentioned in LDAPS presentation certificate.

Know your LDAPS server FQDN: openssl s_client -connect [LDAPS server IP/DNS]:636. Try to connect LDAPS server using IP/DNS. It displays the exact FQDN in CN= attribute. Use that FQDN to configure LDAPS server.

  • Fix 3: Import the LDAPS presentation certificate (not the root or intermediate) in the application server.
  • Disabling validation is NOT a "fix"! There are a surprising amount of historical errors relating to this area in Java, but from 1.8.181 it seems to be relatively sensible. The caveat is that (like most modern browsers) the hostname from the URL MUST be present in the SAN of the certificate to be considered valid. – symcbean Feb 1 at 13:20

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.