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 se: /var/lib/pki-ra/alias. [Tue Jan 20 05:31:51 2009] [error] SSL Library Error: -8053 SEC_ERROR_BUSY Version-Release number of selected component (if applicable): mod_nss-1.0.3-6.el5.i386.rpm How reproducible: Always 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: Expected results: 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 (mod_nss-1.0.7-8.fc8.i386.rpm): Starting pki-ra: [ OK ] PKI service(s) are available at https://meatpie.dsdev.sjc.redhat.com:12889 Additional info:
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: >> Guys, >> >> 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. bob
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] PKI-RA nss.conf
Created attachment 329531 [details] PKI-TPS nss.conf
NOTE: No changes are made to these files whether they are on Fedora or RHEL.
Created attachment 329533 [details] PKI-RA nss_pcache
Created attachment 329534 [details] PKI-TPS nss_pcache
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.
requesting acks
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. http://rhn.redhat.com/errata/RHEA-2009-0403.html