116315 - built-in root certs don't show in web server admin UI - root cert module not added to secmod.db

Status: VERIFIED FIXED

(NSS :: Libraries, defect, P1)

Description

[Julien Pierre]

The web server admin UI enumerates root certs with a call to
PK11_ListCerts(PK11CertListRootUnique, NULL);
 
When dropping NSS 3.4 binaries from 12/20 into the web server tree, and clicking
on the "security/manage certificates" page of the admin UI, it occasionally will
completely skip the display of root certs. Only the server cert and the CA
installed in the database is shown. This is even though I have the proper
version of libnssckbi.so installed. The problem is intermittent and seems to
depend on the state of memory, indicating possible corruption.

Comment 1

[Julien Pierre]

This problem is still occurring on a fresh build of NSS today. The root certs
are not listed.

Comment 2

[Wan-Teh Chang]

Assigned the bug to Ian.

Comment 3

[Ian McGreer]

Does this still happen?

Comment 4

[Julien Pierre]

Yes. And actually right now the root certs don't show at all in the admin UI of
the web server.

Comment 5

[Ian McGreer]

at least it's not intermittent anymore :)

Does the admin UI have a way of showing what PKCS#11 modules are loaded?  Is it
possible to isolate whether this is due to the module not being loaded properly
or not?

Comment 6

[Julien Pierre]

Ian,

The admin UI only shows the tokens that require a login, in order to show the
password prompt. Otherwise it lists certs in all tokens.

I just investigated this problem with modutil. It is related to the path of the
root cert module.

The admin initializes NSS in a directory of server_root/alias . Eg. in my test
/export/home/jpierre/60/SunOS_5.8_depend/ns/server/work/B1/SunOS5.6_DBG.OBJ/alias
. NSS is initialized read/wirte, so the secmod.db is created .
The alias directory contains a copy of the libnssckbi.so file.

With 3.3.x, the secmod.db is created with a reference containing an absolute
path to the libnssckib.so, as shown by modutil below fdr 3.3.2 :

(strange)/export/home/jpierre/60/SunOS_5.8_depend/ns/server/work/B1/SunOS5.6_DBG.OBJ/alias{86}
modutil -dbdir . -dbprefix https-test-strange- -list
Using database directory ....

Listing of PKCS #11 Modules
-----------------------------------------------------------
  1. Root Certs
        library name: ./libnssckbi.so
         slots: 1 slot attached
        status: loaded

         slot: 
        token: Builtin Object Token

  2. NSS Internal PKCS #11 Module
         slots: 2 slots attached
        status: loaded

         slot: NSS Internal Cryptographic Services Version 3.2
        token: NSS Generic Crypto Services

         slot: NSS User Private Key and Certificate Services
        token: NSS Certificate DB
-----------------------------------------------------------



If I remove the secmod.db, copy over the NSS 3.4 shared libraries (including the
new libnssckbi.so to the alias directory), and click the UI to create another
secmod.db, the secmod.db is created with a relative reference to libnssckbi.so .
Here is the output of modutil with NSS 3.4 :

(strange)/export/home/jpierre/60/SunOS_5.8_depend/ns/server/work/B1/SunOS5.6_DBG.OBJ/alias{88}
modutil -dbdir . -dbprefix https-test-strange- -list
Using database directory ....

Listing of PKCS #11 Modules
-----------------------------------------------------------
  1. NSS Internal PKCS #11 Module
         slots: 2 slots attached
        status: loaded

         slot: NSS Internal Cryptographic Services Version 3.2
        token: NSS Generic Crypto Services

         slot: NSS User Private Key and Certificate Services
        token: NSS Certificate DB

  2. Root Certs
        library name: ./libnssckbi.so
         slots: 1 slot attached
        status: loaded

         slot: 
        token: Builtin Object Token
-----------------------------------------------------------

Note the ./libnssckbi.so with 3.4 .

BTW, the "cryptographic services" version remains at 3.2 in both cases. We might
want to change that for 3.4 RTM.

Comment 7

[Julien Pierre]

Due, I pasted the wrong output for 3.2 . I had a secmod.db created with 3.4 with
the wrong link, forgot to erase it. Here is the right output for 3.3.2 after the
secmod.db is erased and recreated :

(strange)/export/home/jpierre/60/SunOS_5.8_depend/ns/server/work/B1/SunOS5.6_DBG.OBJ/alias{91}
modutil -dbdir . -dbprefix https-test-strange- -list
Using database directory ....

Listing of PKCS #11 Modules
-----------------------------------------------------------
  1. Root Certs
        library name:
/export/home/jpierre/60/SunOS_5.8_depend/ns/server/work/B1/SunOS5.6_DBG.OBJ/alias/libnssckbi.so
         slots: 1 slot attached
        status: loaded

         slot: 
        token: Builtin Object Token

  2. NSS Internal PKCS #11 Module
         slots: 2 slots attached
        status: loaded

         slot: NSS Internal Cryptographic Services Version 3.2
        token: NSS Generic Crypto Services

         slot: NSS User Private Key and Certificate Services
        token: NSS Certificate DB
-----------------------------------------------------------

Comment 8

[Wan-Teh Chang]

The relative pathname of the root cert module stored in
secmod.db seems to be the same problem that Jamie reported
in bug 119371.

Comment 9

[Julien Pierre]

Wan-Teh,

Yes, it is the same bug, and the web server admin UI depends on it because the
root cert module is automatically added to secmod.db, rather than manually
added. This is a must fix for 3.4 RTM.

Comment 10

[Wan-Teh Chang]

*** Bug 119371 has been marked as a duplicate of this bug. ***

Comment 11

[Ian McGreer]

As bug 119371 was Bob's bug, I'm reassigning this.

Comment 12

[Robert Relyea]

OK, I'll take a look, but I'm pretty sure that NSS 3.3 did not find the whole
path. I'm pretty sure the code that adds the DB did not change. I'm wondering if
we have an install/setup issue, where there's a path where the secmod.db gets
created with a full path and one where it gets created with a relative path, and
in your testing you ran into the first one when doing the 3.3 run, and the
second one when doing the 3.4 run?

In the mean time I'll go look at the code and *verify* that we are still doing
the same thing.

bob

Comment 13

[Julien Pierre]

Bob,

In the web server, the admin is passing an absolute path to NSS_Initialize as
the secmodpath. But it somehow gets translated to a relative path in secmod.db
when using NSS 3.4 . When using NSS 3.3 the absolute path is saved as-is.

Comment 14

[Julien Pierre]

FYI, the reason it was intermittent was that sometimes I was using a secmod.db
created with 3.3, and sometimes with 3.4 . The error occurred with the
3.4-created secmod.db files.

Bob determined - using "strings secmod.db" that the problem in this case was
that the root cert module did not get automatically added to secmod.db . But
when I ran modutil from 3.3, it was adding it, with a relative path.

Comment 15

[Julien Pierre]

verified fixed

Comment 16

[Julien Pierre]

verified fixed on 1/24 build