JXplorer connection to DSA and SSL Handshake Exception in Symantec Directory
search cancel

JXplorer connection to DSA and SSL Handshake Exception in Symantec Directory

book

Article ID: 229600

calendar_today

Updated On:

Products

CA Directory

Issue/Introduction

You may experience SSL handshake error when connecting to Symantec Directory DSA over SSL channel. The error may be related to hostname (i.e. SAN) not being present in the certificate that is being used.

e.g.

 

 

Environment

Release : 14.1

Component : CA Directory

Component : Symantec Identity Manager 14.X

Cause

- Java update Java8U181 and higher now requires a matching Subject Alternative Name declared in the SSL Certificate.

- Self signed certs and or older Certs in use previously loaded in cacerts keystore may not have SAN - Subject Alternative Name, and will cause the error.

Resolution

The above depends on version of JAVA in use. In newer versions of java there is requirement for SAN (Subject Alternative Name) to be present in the certificate that is being used to connect over SSL while in the older versions this was not a requirement.

To overcome this problem we need to pass "-Dcom.sun.jndi.ldap.object.disableEndpointIdentification=true" to java while launching JXplorer.

Try the following when using JXplorer:

For example: Use jxplorer.bat (located under the path where JXplorer is installed on your Windows system) to launch JXplorer after editing the .bat file and add the argument like shown below. Save the changes and launch.

Original:
java -classpath ".;jars/;jasper/lib/" -Dfile.encoding=utf-8 %JXOPTS% com.ca.directory.jxplorer.JXplorer %*

Modified:
java -classpath ".;jars/;jasper/lib/" -Dfile.encoding=utf-8 -Dcom.sun.jndi.ldap.object.disableEndpointIdentification=true %JXOPTS% com.ca.directory.jxplorer.JXplorer %*

Once done, save the file and launch the LDAP browser using JXplorer.bat

Additional Information

This has actually been included in the product document at the following link:

SSL Handshake Error When Connecting to Directory

This suggested workaround has been tested against Oracle Java8U181, OpenJDK JRE 11 and 17.