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.
CA Directory 14.1 SP3+, Linux and Windows
The examples are based on the three out-of-the-box samples that come with a standard Directory Server installation.
cd /d "%DXHOME%\samples\unspsc"
setup.bat -q
cd ..\democorp
setup.bat -q
cd ..\ssl
setup.bat SHA1 -q
Download and install the JXplorer according to what is docuumented at https://www.jxplorer.org/.
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
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".
There are two different ways to quickly correct this error.
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.
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:
The default keystore password for the Client Certificate on JXplorer is "passphrase".
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".
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>
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.
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.