Red Hat Bugzilla – Bug 480853
mod_nss does not work with NSS 3.12 for pki-ra or pki-tps
Last modified: 2015-01-04 18:36:03 EST
Description of problem:
The latest available "mod_nss" running on RHEL 5.3 does not work correctly with NSS 3.12 when attempting to run the CS 8.0 "pki-ra" or "pki-tps" subsystems.
For example the following log message occurs upon installation:
[Tue Jan 20 05:31:51 2009] [info] Init: Initializing NSS library
[Tue Jan 20 05:31:51 2009] [error] NSS initialization failed. Certificate databa
[Tue Jan 20 05:31:51 2009] [error] SSL Library Error: -8053 SEC_ERROR_BUSY
Version-Release number of selected component (if applicable):
Steps to Reproduce (Actual results):
Performing an "/etc/init.d/pki-ra start" causes the application to
prompt for a password (that should automatically be read-in):
Starting pki-ra: Please enter password for "internal" token:
Correct behavior can be seen by replacing "/usr/lib/httpd/modules/libmodnss.so" with the same file from the latest Fedora 8 "mod_nss" package
Starting pki-ra: [ OK ]
PKI service(s) are available at https://meatpie.dsdev.sjc.redhat.com:12889
As CS 8.0 is targeted to be released on RHEL 5.3, this bug needs to be fixed as an erratta on that version of the product.
Additional info from email correspondence:
Rob Crittenden wrote:
> Matthew Harmsen wrote:
>> This is in reference to Bugzilla Bug #480104 -- I believe that I may have fixed the reported problem by making sure that perl-DBI is loaded -- however, I run into the following problem:
>> [Sat Jan 17 14:34:50 2009] [info] Init: Initializing NSS library
>> [Sat Jan 17 14:34:50 2009] [error] NSS initialization failed. Certificate database: /var/lib/pki-ra/alias.
>> [Sat Jan 17 14:34:50 2009] [error] SSL Library Error: -8053 SEC_ERROR_BUSY
>> Which reminded me that it might be a mismatch between MOD_NSS and the system NSS 3.12.
>> I looked on Koji at http://koji.fedoraproject.org/koji/packageinfo?packageID=2554, and this seems to have a version of mod_nss which does the proper forking to work with NSS 3.12.
>> However, looking on Brew at https://brewweb.devel.redhat.com/packageinfo?packageID=3235, I didn't see this particular bug applied (although some of the later bugs were). I downloaded and installed the latest one, but still get the message above.
>> Do we need to build a mod_nss for RHEL 5 that works with NSS 3.12, or this some other problem?
> Well, it is a bit strange that mod_nss works with NSS 3.12 at all since it lacks the fork patch but it does. I'm not really sure why.
NSS 3.12 on RHEL5 is still using the 3.11.5 softoken because of FIPS. The fork check was added to softoken 3.12. That's why only fedora versions of the products need to fork fix.
If you start it from the command-line and enter the correct PIN does the server start up properly?
Can you attach your nss.conf?
Yes, I am able to startup the server if I use the internal PIN located in my "/etc/pki-ra/password.conf" and "/etc/pki-tps/password.conf".
Created attachment 329530 [details]
Created attachment 329531 [details]
NOTE: No changes are made to these files whether they are on Fedora or RHEL.
Created attachment 329533 [details]
Created attachment 329534 [details]
The reason it is failing is because mod_nss 1.0.3 doesn't support the defer directive. That was introduced in 1.0.4. I'll see about backporting the feature.
A workaround may be to use file: instead of defer:
The purpose of defer is to not attempt to initialize all tokens, just those with a password defined.
Setting rhel‑5.3.z flag.
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.