Use JXPlorer to connect to a Symantec Directory DSA through SSL
search cancel

Use JXPlorer to connect to a Symantec Directory DSA through SSL

book

Article ID: 379040

calendar_today

Updated On: 03-31-2025

Products

CA Directory

Issue/Introduction

The rapid advancement of computing power in the recent years has demanded higher communications security over a computer network. The Transport Layer Security (TLS) protocol and its outdated predecessor, the Secure Sockets Layer (SSL) protocol has been the industrial standard used to ensure that the communication between a client computer and a server is secure. Both TLS and the public key certificate it uses have been revamped to provide the enhanced communication security over a computer network.

JXplorer is a popular LDAP Browser among Broadcom/CA customers since it was originated from CA Technologies. This tool has since been donated to the open-source community by CA Technologies.

In this article, we focus on the impact the more recent TLS/public key certificate changes bring to the communication between JXplorer as a client program and Symantec Directory DSA server. In addition, JXplorer is actually a java program that uses JRE to provide its SSL/TLS functionality. As a result, we can change the JXplorer's SSL/TLS behavior by starting it using different JRE installations. This article has been tested using Oracle Java 8, OpenJDK 11, and OpenJDK 17.

Environment

CA Directory 14.1 SP3+, Linux and Windows

Cause

 

Resolution

Scope of Testing

In this article, we have the following two focuses:

  • JXPlorer connection to a Symantec Directory DSA using SSL/TLS
  • JXplorer connection to a Symantect Directory DSA using a Public Key Certificate.

In addition, we also ask ourselves to do our best to make the setup of the testing to be close what one may do in a real-world situation.

Setting Up Testing Environment

To demonstrate the different ways how JXplorer use SSL/TLS communication to connect to a Symantect Directory DSA, we need to have a workding Symantect Directory DSA that offers ldaps endpoint. Three out-of-the-box samples that come with a standard Directory Server installation allows us to easily set this up.

Setup the three samples, democorp, unspsc, and ssl

cd /d "%DXHOME%\samples\unspsc"
setup.bat -q
cd ..\democorp
setup.bat -q
cd ..\ssl
setup.bat SHA1 -q

or

cd "$DXHOME/samples/unspsc"
./setup.sh -q
cd ../democorp
./setup.sh -q
cd ../ssl
./setup.sh SHA1 -q

Install JRE and JXplorer

Download and install a release of JRE of your choice. In this article we used releases from Oracle JRE8, OpenJDK 11 and OpenJDK 17. The different releases of Oracle 8 download are currently located at Java Archive | Oracle. The OpenJDK releases can be downloaded from Archive | Adoptium.

Download and install the desired the JXplorer according to what is documented at https://www.jxplorer.org/.

Use Case Testing

Discover the IP address the DSA democorp Uses

netstat -an | findstr 19389

or

netstat -an | grep 19389

An entry similar to the following will appear when the democorp DSA is started correctly.

  TCP    ###.###.###.###:19389    0.0.0.0:0              LISTENING

Starts the JXplorer

On a Windows machine, the installer of JXplorer creates a shortcut to start the JXplorer by changing the current directory to the JXPloer subdirectory similar to:

"C:\Program Files (x86)\jxplorer"

and then start the JXplorer using something similar to:

"C:\Program Files\Java\jdk1.8.0_211\jre\bin\javaw.exe" -classpath .;jars/jxplorer.jar;jars/help.jar;jars/jhall.jar;jars/jxworkbench.jar;jars/junit.jar; -Dfile.encoding=utf-8 com.ca.directory.jxplorer.JXplorer

In this case, it shows that we are using the JRE under jdk1.8.0_211. To start the JXPlorer using different installation of the JRE, just change the program path to the desired installation of the javaw.exe file.

Test Case 1: JXplorer SSL+Anonymous Connection

Initial Attempt (fails)

  1. Lauch the JXplorer
  2. Set the Host to the IP address located: ###.###.###.###
  3. Set the Port to 19389
  4. Set the Protocol to LDAP v3
  5. Set the Base DN to O=DEMOCORP,c=au
  6. Set the Security Level: to "SSL + Anonymous"
  7. Click on OK to connect

JXplorer will prompt you a "Server CA Certificate missing" Window, throughout this article, we can simply click the "This Session Only" to continue. You will then see two "Error Encountered" Windows, one states, "Unable to perform Extended request Connection Request operation." and another states, "Error opening connection: No subject alternative names present".

Correct "No subject alternative names present" Error

There are the following ways to correct this error.

1. Configure the host-name value in the democorp.dxc under the config/knowledge

Add a single host-name  entry in the config/kowledge/democorp.dxc so that it has a snippet simiar to:

set dsa DEMOCORP = 
{ 
...
     host-name     = "###.###.###.###"
     disp-psap     = DISP 
...
}; 

and re-run the the "setup SHA1 -q" under samples/ssld. This will create a new democorp certificate that has the IP address set as itssubject alternative name.

The single-value host-name entry can actually be a machine name that can be resolved into an IP address on the Directory server where the "setup SHA1 -q" is run.

 

2. Allow the name DXserver to resolve into the IP address the democorp is listening at

This can be achieved by adding an entry likes the following into the hosts file of the machine where the JXplorer is launched:

###.###.###.### DXserver

This wroks because the out-of-the-box democorp DSA is set to the following in the knowledge dxc file:

  dsa-name      = <c AU><o DEMOCORP><cn DXserver>

which cause the samples/ssl to create a certificate for democorp DSA to use the subject DN of

        Subject: C = AU, O = DEMOCORP, CN = DXserver

This also means that you can configure the dsa-name using the fully qualified machine name that will resolve into the IP address that can reach the democorp DSA. If you do, please use double quote for the name as in:

  dsa-name      = <c AU><o DEMOCORP><cn "DXserver.sample.com">

For our testing, we also need to re-run the the "setup SHA1 -q" under samples/ssld. Please note that unlike the host-name example, in place of this CN value, it cannot be an IP address.

3. Use dxcertgen to set SAN directly without using the setup under the samples/ssl

In the previous two solutions to address the "No subject alternative names present" error, we have been relying on the samples/ssl. The magic behind it was actually the Symantec Directory utility dxcertgen. To find more details about it, please see the following documentation link:

DXcertgen Tool -- Generate and Work with Certificates 

So, a quick way to resolve this error without modifying the democorp.dxc under config/knowledge and continue to use IP address to connect to the democorp DSA is simply to run the following command:


dxcertgen -e "SAN=IP:###.###.###.###" certs

and then stop and restart the democorp DSA.

This "dxcertgen -e" command actually adds the same subject alternate name to all the certificates recreated for all the DSAs. In a real-world scenario, however, there is the management aspect of managing the CA file, known as trusted.pem, and all other certificate files under the config/ssld/personalilities to consider. This issue is a separate subject beyond the scope of this article and needs to be addressed separately.

4. Use a release of JRE that does not check subject alternate name all

This approach is certainly not recommended. However, for completeness's sake, it is worth-while to point out that the security requirement to check the certificates used by an ldaps endpoint start with Oracle JRE 8U181. The public release of the one prior to that was 8U172. So, using a release prior to and include 8U172 will just work without having to worry about the checking of subject alternate name.

5. Use a java option to disable checking of the subject alternative name

This option is actually documented in the product documentation

SSL Handshake Error When Connecting to Directory

and the following KB article:

JXplorer connection to DSA and SSL Handshake Exception in Symantec Directory

 

Test Case 2: JXplorer SSL + User + Password Connection

After going through the Test Case 1: JXplorer SSL. + Anonyous Connection, we can also set a password for an entry likes "cn=Marco DREW,ou=Information,ou=Corporate,o=DEMOCORP,c=au". The we can proceed with this test case, and it should just work:

  1. Lauch the JXplorer
  2. Set the Host to the IP address located or the DXserver if host file was modified
  3. Set the Port to 19389
  4. Set the Protocol to LDAP v3
  5. Set the Base DN to O=DEMOCORP,c=au
  6. Set the Security Level to "SSL + User + Password"
  7. Set the User DN to cn=Marco DREW,ou=Information,ou=Corporate,o=DEMOCORP,c=au
  8. Set the Password to the password set previously
  9. Click on OK to connect

Test Case 3: JXplorer SSL + SASL + Keystore Password Connection

Instead of traditional ID/password authentication, this test case is about using a Public key certificate to authenticate against a Symantec Directory DSA through the Simple Authentication and Security Layer (SASL) framework. JXplorer uses a Client Certificates keystore to store a Public key certificate and its corresponding private key. The default keystore password for this keystore is "passphrase".

Initial SASL Attempt (fails)

  1. Lauch the JXplorer
  2. Set the Host to the IP address or host name that works in the previous test cases to avoid the subject alternative name error.
  3. Set the Port to 19389
  4. Set the Protocol to LDAP v3
  5. Set the Base DN to O=DEMOCORP,c=au
  6. Set the Security Level to "SSL + SASL + Keystore Password"
  7. Set the Password to the passphrase
  8. Click on OK to connect

This initial attempt fails with the two Error Encountered Windows. One states, "Unable to perform Extended request Connection Request operation.", another states, "Error opening connection: SASL bind failed: ###.###.###.###:19389".

The reason why this initial SASL attempt fails is because the certificate/private key stored in the out-of-the-box JXplorer Client Certificate keystore is unlikely to be acceptable by the Symantec Directory DSA. Further, during our tests, we may have just run the samples/ssl setup multiple times and each time it would create a set of brand-new certificates and a brand-new certificate authority that signed them.

Resolve the SASL Attempt Failure

It makes sense to use a particular client certificate to connect to a Directory DSA as the certificate is meant to represent the user's identity. However, JXplorer does not seem to provide a way to clearly identify a particular certificate to use when there are more than one of them exist in the keystore. An easy way to address it is to first delete all the existing certificates in the keystore and then only import the desired certificate/private key.

  1. On JXplorer, Security > Client Certificates > select and Delete Certificate > provide "passphrase" as the Key Store Password to delete all the existing certificates.
  2. Import the marco drew certificate/private key created by the samples/ssl setup into the keystore.
    1. We first need to prepare a simple private key file, macro_drew.key,
      by copying the marco_drew.pem under "%DXHOME%\config\ssld\personalities" to a file named as "marco_drew.key", removing all the lines before the line "-----BEGIN PRIVATE KEY-----" to create a private key file that starts with the "BEGIN PRIVATE KEY" line and ends with an "END PRIVATE KEY line".
    2. Then on JXplorer, Security > Client Certificates > Add Certificate > select the marco_drew.pem, click Open, click OK, provides a Certificate Alias, click OK, click Set Private Key, select the marco_drew.key created manually, click OK, and then OK.
  •  Please note that the macro_drew.pem file may need to be regenerated if one has ever run dxcertgen manually without using the samples/ssl setup as it was generated within the setup using a command similar to
    dxcertgen -u "%DXHOME%\samples\ssl\user.ldif" -p "%DXHOME%\config\ssld\personalities" certs
    The marco drew is included in the usesr.ldif file

Repeat the same steps performed in the Initial SASL Attempt will now work. To confirm this, we can telnet to the democorp console port,

telnet localhost 19390

and use get users; to confirm:

Welcome to the DSA Management Console
dsa> get users;

Association 9: connected for 606 seconds, idle for 606 seconds (SSL: TLSv1.2)
Association 9: bound using LDAP (peer xxx.xxx.xxx.xxx:54001) as SSL AUTH

 user:
      <countryName "au">
      <organizationName utf8 "Democorp">
      <organizationalUnitName utf8 "Corporate">
      <organizationalUnitName utf8 "Information">
      <commonName utf8 "User Name">


Total Associations: 1

dsa>

Invalid Certificate Credetial

The content in the user.ldif syntax is rather simple, all we need is to specify a valid dn. It is therefore easy to ask the dxcertgen to create more signed certificate that are trusted by our DSAs. The dn specified in the file is used as the Subject DN of a certificate, but if it does not match any of the dn in the Data DSA, then it will give an invalid credential response as:

[LDAP: error code 49 - Invalid Credentials]

Test Case 4: JXplorer SSL + SASL + Keystore Password Connection Using a CA issued Certificate

During the Test Case 3, we used the marco_drew.pem that was generated by the samples/ssld setup. Interestingly, other than the certificate file, the certificate is actually not stored on the Data DSA at all. This means that so long as the certificate is trusted, the certificate Subject matches the desired dn of a user in the directory, and both the certificate and key are set in the "Client Certificate" of the JXplorer, then it will allow us to bind with the democorp DSA using the certificate.

To allow a regular CA-issued certificate, or even a self-signed certificate, to be used in place of the marco_drew certificate example above, we will need to import the root CA and other intermediate CA to the trusted.pem file and restart the DSA. This is to establish the trust. The command to do the import:

dxcertgen -n certPEMfile importca

Otherwise, we will see the following error in the trace console:

dsa> set trace=all;
dsa> Accepting call from TCP xx.xxx.xx.xxx:59341
GetRemoteHostName:Skipping local host-name validation
Warning: Verify error 7: certificate signature failure
STATE: SSL3 alert write: fatal: decrypt error
Warning: SSL Error
Warning: 9d9afff8-   16030303 3f0b0003 3b000338 00033530    ....?...;..8..50
Warning: 9d9b0008-   82033130 820219a0 03020102 02010c30    ..10...........0
Warning: 9d9b0018-   0d06092a 864886f7 0d01010b 0500303a    ...*.H........0:
Warning: 9d9b0028-   310b3009 06035504 06130241 55311530    1.0...U....AU1.0
Warning: 9d9b0038-   13060355 040a0c0c 44584365 72744765    ...U....DXCertGe
Warning: 220:error:0407008A:rsa routines:RSA_padding_check_PKCS1_type_1:invalid padding:rsa_pk1.c:116:
220:error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check failed:rsa_eay.c:693:
220:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:a_verify.c:218:
220:error:14089086:SSL routines:ssl3_get_client_certificate:certificate verify failed:s3_srvr.c:3356:
Warning: ssld_ssl_request failed
Warning: TLS/SSL handshake failed for call from xx.xxx.xx.xxx:59341

 

 



Additional Information

Even though the examples provided are using Windows syntax, they can be easily replaced with Linux syntax when one is using a Linux implementation. Also, to run through the examples, we assume that one will login as user dsa.

When there are multiple private keys in the Client Certificate keystore, it is simply hard to know which certificate is used to connect. To troubleshooting, we can also use

set trace=all;

when telneting to the democorp console port. When it fails because of the certificate issue, you may be seeing something likes the following:

dsa> set trace=all;
dsa> Accepting call from TCP xxx.xxx.xxx.xxx:54052
GetRemoteHostName:Skipping local host-name validation
Warning: Verify error 7: certificate signature failure
STATE: SSL3 alert write: fatal: decrypt error
Warning: SSL Error
Warning: 127ec688-   16030303 500b0003 4c000349 00034630    ....P...L..I..F0
Warning: 127ec698-   82034230 82022aa0 03020102 02010530    ..B0..*........0
Warning: 127ec6a8-   0d06092a 864886f7 0d01010b 0500303a    ...*.H........0:
Warning: 127ec6b8-   310b3009 06035504 06130241 55311530    1.0...U....AU1.0
Warning: 127ec6c8-   13060355 040a0c0c 44584365 72744765    ...U....DXCertGe
Warning: 252:error:0407008A:rsa routines:RSA_padding_check_PKCS1_type_1:invalid padding:rsa_pk1.c:116:
252:error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check failed:rsa_eay.c:693:
252:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:a_verify.c:218:
252:error:14089086:SSL routines:ssl3_get_client_certificate:certificate verify failed:s3_srvr.c:3356:
Warning: ssld_ssl_request failed
Warning: TLS/SSL handshake failed for call from xxx.xxx.xxx.xxx:54052

Interestingly, this message is almost identical to the error message we see in the Test Case 4 above.

 

Powered by Wolken Software