hi David,
For JSS with SSLServerSocket if you want to do a reconnect because your
orginal cert you configured has expired
is now INVALID you would have to re-call setServerCert or
setServerCertNickname first and configure the new cert.
For the JSS SSLSocket client connection you have the same methods.
http://www.mozilla.org/projects/security/pki/jss/javadoc/org/mozilla/jss/ssl/SSLSocket.html
http://www.mozilla.org/projects/security/pki/jss/javadoc/org/mozilla/jss/ssl/SSLServerSocket.html
If this is a JSS issue you should be able to recreate the issue by
modifying this JSS test program
http://mxr.mozilla.org/security/source/security/jss/org/mozilla/jss/tests/SSLClientAuth.java
Please modify the test program to create a reproducible test case with
the latest JSS, then attach it to a bug.
Please list your exact version of NSPR/NSS/JSS/platform you're using.
If your JSS stand alone test program works, then you should be able to
use the cert creation
from SSLClientAuth.java to add the Java LDAP SDK and reproduce the bug.
Then
make a bug on the Java Ldap SDK team.
I don't know how much development is being done on the Java LDAP SDK,
but you're
able to download the source build/debug/provide fix. Both JSS and the
Java LDAP SDK
are open source owned by the Mozilla Foundation and they welcome
contributions.
http://www.mozilla.org/directory/javasdk.html
Note: in your c++ application if you're able to call NSS_Shutdown and
re-initialize NSS,
you could do the same with JSS. Some code to help:
http://mxr.mozilla.org/security/source/security/jss/org/mozilla/jss/tests/CloseDBs.java
But you shouldn't need to shutdown NSS and re-initialize this is really
frowned upon.
Your application may be 24X7 but this re-reinitialization of NSS is
basically a
restart of your application.
Again once you installed your new certificates and your old certificates
have INVALID_CREDENTIALS, provided your code doesn't keep trying to use
the same handle to the
old certificates and instead before attempting to reconnect it obtains
new handles
to the new valid certificates then tries a new connection every thing
should work fine.
Please create a reproducible test case. I expect in the process of doing
so you
should fix this issue, if not when you have a reproducible JSS test case
I will
see what I can do. If the issue is with the Java LDAP SDK then likely a fix
would be needed to the reconnect method.
-glen
On 09/11/08 09:13, David B Hinz wrote:
We are still encountering the problem detailed below that was described by
Steve over a year ago.
Is there anyone that can provide some insight on how we can solve this
problem?
What happens is that some of our applications must run 24x7 yet the user
certificates are changed every 90 days (or sooner based on other
criteria).
When the certificates are changed while the applications are running
we get
the INVALID_CREDENTIALS error.
We were able to solve this problem on C++ using the "ldap_unbind_s();
ldapssl_shutdown();" API calls (ldapssl_shutdown() was provided with the
LDAP C SDK 6.x).
As Steve points out there doesn't seem to be a way to do this with the
Java
LDAP SDK.
After looking at the code the problem seems to be with a singleton that is
used as the JSS or libjss.so layer that is keeping the credentials from
being re-read. But a modification to the code would be difficult because
the entire design of JSS is based on this singleton.
How do other applications that run 24x7 deal with the problem with
certificates changing while they are running?
We ar using the latest versions of the Java LDAP SDK and JSS.
Is there any active development being done on the Java LDAP SDK that is
currently as version 4.17 and has been for several years?
Is there any active development being done on JSS and libjss.so?
We need to use the JSSSocketFactor() provided by JSS because we need
to use
the same type of certificates between the Java and C++ code.
JSSESocketFactory() provided by Java used PKCS12 or JKS keys.
We have looked at the Java version of OpenLDAP but it appears to be a
wrapper around the JSSESocketFactory.
Thanks for any info you can provide.
david.
> This is sort of a follow-on to Mike's message of last Sept. 12.
> It, and Bug 352673 discussion, led us to be able to have our
> applications handle new certificates being created while the apps are
> running. We detect the INVALID_CREDENTIALS error and call:
> ldap_unbind_s()
> ldapssl_shutdown() (which calls SSL_ClearSessionCache() and
> NSS_Shutdown())
> ...and re-initialize, and everybody's happy - in our C++ world.
> ____________________
>
> Now we need to accomplish the same thing in our Java apps, but
.can't seem to make them let go of and re-fetch certificates.
> We connect with:
> jsf = new JSSSocketFactory(certDir)
> conn = new LDAPConnection(jsf)
> conn.connect()
> conn.authenticate(), using EXTERNAL mechanism
> After re-creating certificates while running, on the
> INVALID_CREDENTIALS error, we call:
> connection.disconnect()
> (which calls LDAPConnThread::deregister() and thus
> sendUnbindRequest() )
> SSLServerSocket.clearSessionCache()
> ...and re-initialize as in the beginning.
> But, we continue to get INVALID_CREDENTIALS errors.
> I'm guessing we're not cleaning up enough before re-initializing,
> but don't know what else to try (e.g. can't find a Java handle to an
> NSS_Shutdown() call, as in C)
> Thanks for any help.
> Steve
=====================
David Hinz
720-858-4334
S75 / A1715H
------------------------------------------------------------------------
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
