Closed Bug 116315 Opened 23 years ago Closed 23 years ago

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

Categories

(NSS :: Libraries, defect, P1)

Product:
NSS
Component:
Libraries
Platform:
Sun
Solaris
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: julien.pierre, Assigned: rrelyea)

References

Details

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.
OS: other → Solaris
Priority: -- → P1
Hardware: Other → Sun
Target Milestone: --- → 3.4
Summary: built-in root certs sometimes don't show in web server admin UI → built-in root certs sometimes don't show in web server admin UI - not returned by PK11_ListCerts
Blocks: 115954
This problem is still occurring on a fresh build of NSS today. The root certs
are not listed.

Assigned the bug to Ian.
Assignee: wtc → ian.mcgreer
Does this still happen?
Yes. And actually right now the root certs don't show at all in the admin UI of
the web server.
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?
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.

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
-----------------------------------------------------------

The relative pathname of the root cert module stored in
secmod.db seems to be the same problem that Jamie reported
in bug 119371.
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.

*** Bug 119371 has been marked as a duplicate of this bug. ***
As bug 119371 was Bob's bug, I'm reassigning this.
Assignee: ian.mcgreer → 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
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.
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.
Summary: built-in root certs sometimes don't show in web server admin UI - not returned by PK11_ListCerts → built-in root certs don't show in web server admin UI - root cert module not added to secmod.db
verified fixed
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
verified fixed on 1/24 build
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.