Active Directory LDAPS and Java 181 LDAPS Verification

Question

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?

Solution

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.

Comments

[Kyle Brandt]

lol, and also Impacting my Internal Jira instance - noticed as I went to update our Internal Jira ticket on this issue :P

[Kyle Brandt]

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?

[Greg Askew]

I've always had multiple SAN's for DC certs, but not for this reason.

[Greg Askew]

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).

[symcbean]

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.

[Sujai SR]

I also have faced the same issue and the issue has been resolved after disableEndpointIdentification but planning to use FQDN as a permanent solution.