Wan-Teh Chang wrote, On 2008-09-24 11:24:
> On Tue, Sep 23, 2008 at 11:35 PM, Nelson B Bolyard <[EMAIL PROTECTED]> wrote:
>> David B Hinz wrote:
>>>In the Java code the JSS (or libjss.so) code is apparently holding on to
>>>the certificates when it first reads them. When the certs are chan
On Tue, Sep 23, 2008 at 11:35 PM, Nelson B Bolyard <[EMAIL PROTECTED]> wrote:
> David B Hinz wrote:
>>In the Java code the JSS (or libjss.so) code is apparently holding on to
>>the certificates when it first reads them. When the certs are changed
>>in the /home/user/.ldapcerts/key3.db
David B Hinz wrote:
>Some of the client applications are written in C++ using the Mozilla
>LDAP 6.0.2 C API. Other client applications are written in Java using
>Mozilla LDAP JDK 4.17 and JSS 3.4 (we have just upgraded to JSS 4.25).
Mozilla's LDAP JDK does not support client authenti
Hi Glen, Thanks for the response. I haven't had time to run the tests you suggested but hopefully this week I will be able to. > 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
David B Hinz wrote, On 2008-09-11 09:13:
> 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
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
6 matches
Mail list logo
