Leigh,
Please review my summary below, and tell me if I've made any mistakes.

As I understand it, the very same certs and private keys work in all 3
versions of the browser (4.8, 6.x, and 7.x) when the certs are imported
into the DBs by the browser itself. That is, when the certs are
imported by the browser itself, the browser is able to do SSL client authentication with the test server.


When the certs are loaded via NSS 3.8's pk12util, they work in NS7.
NS7 works either way, whether the certs are imported by the browser or
by pk12util.

When the certs are loaded via NSS 3.6's pk12util, they do NOT work
in either NS 4.8 or NS 6.x.

If the above summary is correct, then I think we can conclude that
there is nothing wrong with the certs themselves, but rather something
about importing certs with NSS 3.6 creates a DB that is incompatible
with NS 4.8 and 6.x, even though the name is the right name for those
versions of the browser.

NS 4.x used a very old version of NSS, version 1.4 (IIRC).  Since that
version, NSS produced a version 1.5, then 2.0-2.8, and 3.0-3.8.  Version
3.0 was the first open source version.  I'm not certain, but I think
NS 6.x used NSS 3.3.

Each new version of NSS claims to be able to use DBs from older versions
of NSS, but not necessarily to produce DBs that are usable by older
versions of NSS.  We have tried to keep all files with the name cert7.db
compatible, and AFAIK, haven't knowingly introduced any non-backward-
compatible changes into cert7.db along the way.  But it is conceivable
that at some point in the sequence of NSS releases, we made an
incompatible change.  If that happened, and if I were to guess in what
release that was most likely to have occured, I'd guess it was NSS 3.4.

So, let me suggest that you try using NSS 3.3, and see if that makes a
difference.  The NSS 3.3 sources are still available.  There might
even be binaries available on mozilla.org's ftp site.

--
Nelson B (on a day off)




Reply via email to