We have upgraded our Nolio Release Automation server from 6.6 to 6.7. After completing the upgrade we are able to login with the superuser id/password. But we cannot login with any of our LDAP/AD users.
When trying to login with an LDAP/AD user it generates the following error
type Exception report
message simple bind failed: <ldap server name>:636; nested exception is javax.naming.CommunicationException: simple bind failed: <ldap server name>:636 [Root exception is javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative DNS name matching <ldap server name> found.]
description The server encountered an internal error that prevented it from fulfilling this request.
exception
org.springframework.ldap.CommunicationException: simple bind failed: <ldap server name>:636; nested exception is javax.naming.CommunicationException: simple bind failed: <ldap server name>:636 [Root exception is javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative DNS name matching <ldap server name> found.]
root cause
javax.naming.CommunicationException: simple bind failed: <ldap server name>:636 [Root exception is javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative DNS name matching <ldap server name> found.]
root cause
javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative DNS name matching <ldap server name> found.
root cause
java.security.cert.CertificateException: No subject alternative DNS name matching <ldap server name> found.
Release Automation 6.7 and 6.8.
There are a few key items involved here.
One of them is the fact that Nolio Release Automation was configured to use an LDAP/AD server over SSL (LDAPS). If it weren't configured to use LDAPS (ldap over ssl) then this error would not occur. However, that would mean that all of the users that log into the Nolio RA server would have their username and passwords sent (from the Nolio RA server to the LDAP server) over clear text. So ldap over ssl is ideal.
Another key item is that Nolio RA is likely configured to point to a server alias - not the actual/physical server. This is why
The other key item causing this is the version of OpenJDK being used by Nolio RA. In version 6.6.0 it used Oracle Java 1.8.0_u162. Version 6.7.0 of Nolio RA uses OpenJDK 1.8.0_u232. This was not an issue with Java 1.8.0_u162. It did not become an issue until 1.8.0_u181. Specifically, it was introduced by an update made in u181 to make things more secure as noted here:
https://www.oracle.com/technetwork/java/javase/8u181-relnotes-4479407.html
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.
Disable Endpoint Identification on Windows:
Here are the steps you can take to disable endpoint identification on Windows:
Disable Endpoint Identification on Linux:
Here are the steps you can take to disable endpoint identification on Linux:
*************
Starting on 6.8 release (actually on a later 6.7 release), "NolioService.bat" is not present anymore because the bundled Tomcat was upgraded to version 9.
Currently, only a file called "service.bat" can be found and this file has to be used for these purposes.
NOTE: This file is not merged during the CARA upgrade, which means in the future it may be overwritten with the upgraded tomcat's "service.bat" file and, because of this, you'll have to repeat all the steps again when changing the version.
Starting on 6.8, in order to solve the issue explained in this document, the following line must be changed in the "service.bat" file:
"%EXECUTABLE%" //IS//%SERVICE_NAME% ^
--Description "Apache Tomcat 9.0.73 Server - https://tomcat.apache.org/" ^
--DisplayName "Apache Tomcat 9.0 %SERVICE_NAME%" ^
--Install "%EXECUTABLE%" ^
--LogPath "%CATALINA_BASE%\logs" ^
--StdOutput auto ^
--StdError auto ^
--Classpath "%CLASSPATH%" ^
--Jvm "%JVM%" ^
--StartMode jvm ^
--StopMode jvm ^
--StartPath "%CATALINA_HOME%" ^
--StopPath "%CATALINA_HOME%" ^
--StartClass org.apache.catalina.startup.Bootstrap ^
--StopClass org.apache.catalina.startup.Bootstrap ^
--StartParams start ^
--StopParams stop ^
--JvmOptions "-Dcatalina.home=%CATALINA_HOME%;-Dcatalina.base=%CATALINA_BASE%;-D%ENDORSED_PROP%=%CATALINA_HOME%\endorsed;-Djava.io.tmpdir=%CATALINA_BASE%\temp;-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager;-Djava.util.logging.config.file=%CATALINA_BASE%\conf\logging.properties;%JvmArgs%" ^
--JvmOptions9 "--add-opens=java.base/java.lang=ALL-UNNAMED#--add-opens=java.base/java.io=ALL-UNNAMED#--add-opens=java.base/java.util=ALL-UNNAMED#--add-opens=java.base/java.util.concurrent=ALL-UNNAMED#--add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED" ^
--Startup "%SERVICE_STARTUP_MODE%" ^
--JvmMs "%JvmMs%" ^
--JvmMx "%JvmMx%"
The jvmOptions parameter must be updated by adding new parameter there:
--JvmOptions "-Dcatalina.home=%CATALINA_HOME%;-Dcatalina.base=%CATALINA_BASE%;-D%ENDORSED_PROP%=%CATALINA_HOME%\endorsed;-Djava.io.tmpdir=%CATALINA_BASE%\temp;-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager;-Djava.util.logging.config.file=%CATALINA_BASE%\conf\logging.properties ;-Dcom.sun.jndi.ldap.object.disableEndpointIdentification=true;%JvmArgs%" ^
NOTE:Is possible that, in order to make this to work, the certificates have to be reinstalled on the environment.