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:

Products

CA Directory

Issue/Introduction

JXplorer is a popular LDAP Browser among Broadcom/CA customers because of its origin as being delivered through CA Technologies. This tool has since been donated to the open-source community by CA Technologies.

As IT security continues to evolve, there have been changes including the more recent SAN support to the connections from a JXplorer to a Symantec Directory DSA.

Environment

CA Directory 14.1 SP3+, Linux and Windows

Cause

 

Resolution

The examples are based on the three out-of-the-box samples that come with a standard Directory Server installation.

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

Install JXplorer

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

Locate the IP address of the DSA democorp is listening at

netstat -an | findstr 19389

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

  TCP    xxx.xxx.xxx.xxx:19389    0.0.0.0:0              LISTENING

Test Case 1: JXplorer SSL+Anonymous Connection

Initial Attempt (fails)

  1. Lauch the JXplorer
  2. Set the Host to the IP address located: xxx.xxx.xxx.xxx
  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 two different ways to quickly correct this error.

  1. Modify host file of the machine where you launch the JXplorder
    to include an entry similar to the following:

    xxx.xxx.xxx.xxx DXserver

  2. Modify the "%DXHOME%\samples\ssl\setup.bat (or .sh for Linux), so that the dxcertgen in the setup script contains something similar to the following:

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

    and rerun the
cd /d "%DXHOME%\samples\ssl"
setup.bat SHA1 -q

If 1 of the above is used, instead of using the IP address, you would use the DXserver as the Host instead. This is because out-of-the-box, democorp has its dsa name set to

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

and we are now using DXserver, the cn of the democorp dsa name.

If 2 of the above is used, we continue to use the IP address. The IP address now works because dxcertgen now supports subject alternative name attribute. The -e "SAN=IP:xxx.xxx.xxx.xxx" portion off the dxcertgen set the subject alternative name of the certificate used by democorp corp to offer SSL connection.  Please consult product documentation

DXcertgen Tool -- Generate and Work with Certificates 

for more details.

The "No subject alternative names present" Error is now resolved.

We now set a password for entry "cn=Marco DREW,ou=Information,ou=Corporate,o=DEMOCORP,c=au" to be used for the next example.

Test Case 2: JXplorer SSL + User + Password Connection

After going through the previous JXplorer SSL. + Anonyous Connection, steps and having a password set for "cn=Marco DREW,ou=Information,ou=Corporate,o=DEMOCORP,c=au", the following will 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

The default keystore password for the Client Certificate on JXplorer is "passphrase".

Initial SASL Attempt (fails)

  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 + 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: xxx.xxx.xxx.xxx:19389".

Correct "No subject alternative names present" Error

The reason why this initial fails is because the current certificate/private key stored in the Client Certificate does not work as any of the existing certificate/private key store there is unlikely to be acceptable to the Symantec Directory DSA as we have just run the samples ssl setup which created a set of brand-new certificates and certificate authority.

Since we actually want to use a particular client certificate to connect to, so we have to remove all the certificates if any within the Client Certificate and import the certificate/private key we want to use.

On JXplorer, Security > Client Certificates > select and Delete Certificate > provide "passphrase" as the Key Store Password to delete the desire certificate.

Then to import the marco drew certificate/private key into the Client Certificate keystore. To do that, we first need to prepare a simple private 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-----".

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.

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>

Test Case 4: JXplorer SSL + SASL + Keystore Password Connection Using another 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 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 to be used in place of the marco_drew certificate example above, we will need to append the root CA and other intermediate CA to the trusted.pem file and restart the DSA. This is to establish the trust. 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

If the certificate Subject does not match any of the dn in the DSA, then it will give an invalid credential response.

 

 

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