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 authentication. When it creates an SSL socket, it does not register a callback for SSL client certificate selection. See http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/directory/java-sdk/ldapjdk/netscape/ldap/factory/JSSSocketFactory.java&rev=1.3&mark=146#129 It also has another problem. It blindly accepts ANY server cert without doing any verification, making it vulnerable to MITM attacks. See http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/directory/java-sdk/ldapjdk/netscape/ldap/factory/JSSSocketFactory.java&rev=1.3&mark=170-172,181#166 It may be possible to correct some of these issues by subclassing the ldap JDK public class JSSSocketFactory. Have you done that? > 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 and /home/user/.ldapcerts/cert7.db > they are not re-read so the user cannot be re-authenticated. cert7 ?? Is that a typo? Any version of NSS/JSS that uses cert7 is at least 10 years old. NSS hasn't used cert7 for over 10 years. Are you really using a version of NSS/JSS that old? Or is it perhaps the case that JSS/NSS is using a different certificate database file than the one you think it is using? >> Are these certificates self-signed? >> Or are they issued by a CA (perhaps your own enterprise internal CA)? >> And, if by a CA, are you replacing the CA cert every 90 days? > > They are self-signed for internal use only. Ouch! Things could be simpler for you if you at least ran your own in-house CA, and let it issue the client and server certs, rather than using self-signed client and server certs. >> Is the problem that you cannot insert the new certificate into the DB of >> the application (client or server) that is sending the certificate to its >> peer? > > It doesn't seem to be. I'm aware of the problems with multi-user access > to the DBs that the certs are stored in. NSS uses an ancient version of Berkeley DB for cert7 and cert8.db files. That version of the code reads in and caches the key DB in memory the first time it is used. After that, it will not notice changes to the key DB file, because it is relying on its in-memory copy. But if it has opened the DB file for read and write, then when it closes the DB, it writes the DB header back out, overwriting any changes that were made to the DB file header while the DB was in use, potentially corrupting the DB if it was changed by another program while the DB was held open. cert9.db, based on sqlite3, should eliminate that particular problem. But it's only available in NSS 3.12.x, and no version of NSS that uses cert7.db has it. _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
