my understanding is that one not forced to upgrade secdb tho its a good thing to do regardless. on my tests cert7 can still be used with LDAPCSDK 6.0.2 and NSS 3.11.4 and NSS doesnt complain. can we try setting something like export SSLDEBUG=99 / export SSLTRACE=99 and giving that failing test case another try ? there gotta be something specific about that particular secdb NSS does not like..
Rich Megginson wrote: > NSS_INIT_READONLY may cause NSS not to create the files if they don't > exist. But this hasn't changed since 2002 - we've used the readonly > option since then, and maybe before then too. So that covers most of > the 5.x releases. I'm using a very recent NSS (3.11.4). > > The workaround is easy - just create your key/cert databases first, > using certutil: > certutil -N -d /home/infwaer/test > or just copy cert8.db and key3.db from mozilla/firefox. > > I think the real fix will be to first check to see if cert8/key3 exist, > then NSS_Initialize in readwrite mode if they do not exist. In general > this is problematic with NSS because AFAIK there is no way to tell > NSS_Initialize to report an error if the key/cert db do not exist, or to > tell NSS_Initialize to open in readonly mode, but create the key/cert db > if they do not exist. > >> It is not a known issue - SSL/TLS works fine with the 6.0 code. I >> suggest starting with the source code for the command line programs, >> especially common.c which contains the SSL/TLS connection code common to >> all of the clients - >> http://lxr.mozilla.org/mozilla/source/directory/c-sdk/ldap/clients/tools/common.c#962 >> _______________________________________________ dev-tech-ldap mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-ldap
