I haven't seen any replies here, but I have made some progress and realized I am overlooking something.  Our C/C++ apps are working, but I had forgotten there is an extra step when I setup SSL in those apps.  I make a call to:

ldap_enable_clientauth( ... );

which tells the code the name of the cert and/or key to use.  On Java, there is no equivalent call, so how is it supposed to know which cert to use from the cert8.db and key key3.db files??  I believe this is my problem now because I can securely connect to LDAP server, but I can't do anything since I cannot authenticate.  In Java all I do is:

LDAPConnection conn = new LDAPConnection(new JSSSocketFactory( certDir ));
conn.connect(host, port);
conn.authenticate(userDN, new String[] {"EXTERNAL"}, null, null);

Somewhere, either in the JSS layer or when I do the authenticate, it needs to know the certficate nickname, but I don't know where this should occur.  The authenticate command takes a Hashtable of properties and I was thinking maybe in here I could specify the cert name, but I haven't seen any documentation that says this is the way to go.

Sorry to send to both LDAP and crypto groups about this, but it seems my answer could be either one.

Thanks, Mike

On 2/15/06, Michael Pratt <[EMAIL PROTECTED]> wrote:
I've been struggling with this for some time...I'm trying to setup our apps to connect via SSL to our iPlanet LDAP server.  Our C++ apps are working fine with the C SDK: I've got the cert.db, key3.db, and secmod.db files created and the apps are able to use them to establish the SSL connection, as well as authenticate with them (so instead of providing a password, I just do a SASL bind with the EXTERNAL mechanism).

With our Java apps, however, I'm having less luck.  I'm creating a JSSSocketFactory (to pass in to the LDAPConnection object) and passing it the same directory of the certificate DBs as I am in our C++ apps, but I keep getting some general error saying unable init security subsystem (it's just a Java Exception, not even one of the four exceptions that CryptoManager.initialize() declares it can throw).  Just reading through documentation I have a couple of questions...

1) I'm assuming that since both the C and Java APIs are from Mozilla, both should support the cert7.db , key3.db, and secmod.db databases, right?  Is the C side using NSS for all its security handling when I establish an SSL connection?

2) I downloaded JSS 3.4 with NSS 3.7.3 and NSPR 4.2.2.  I have the binaries for NSS and NSPR, but I'm compiling jss.jar myself.  I read somewhere that when you get this jar from Mozilla, it's signed, and if you plan on building it yourself, you should also sign the jar.  Could the fact that my own jar isn't signed be causing problems?  Also, the name of the jar shouldn't matter ( i.e. jss.jar vs. jss34.jar) right?  Seems like a stretch but at this point I'm running out of ideas.

3) Does JSS need any env variables or system properties set at runtime?

Thanks for any help.

Mike

_______________________________________________
dev-tech-crypto mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-crypto

Reply via email to