Red Hat Bugzilla – Bug 444348
mod_nss fails to process any request
Last modified: 2008-05-01 08:52:15 EDT
Description of problem:
Every request to mod_nss fails with the error:
[Fri Apr 25 17:48:09 2008] [error] SSL Library Error: -12215 MD5 digest function
Version-Release number of selected component (if applicable):
The NSS team tells me that I need to make sure I do and NSS_Shutdown and Init in
each new fork(). It is a newly enforced provision in the NSS softtokn but has
long been a requirement of PKCS#11 (new init required after a fork). Hardware
tokens would already be requiring this.
Created attachment 303918 [details]
I'm attaching my initial progress in case anyone else wants to look at this.
I have the server basically working using both the threaded and forked mpm but
have one error in each.
On the forked side every time a child exits NSS_Shutdown() is failing. If the
SSL cache is not enabled then it will shut down just fine. Still investigating
this. To see this error you need to either set MaxRequestsPerChild lower or run
ab: ab -f TLS1 -n 5000 -c 40 https://localhost/
On the threaded side an NSS_Shutdown() error is thrown in nss_init_ModuleKill()
because we really don't need to call it there. I've left it there for now.
Created attachment 303971 [details]
Proposed final patch
This patch works well for me with both threaded and forked mpms and doesn't
leak memory as far as I can tell.
I used the NSS strsclnt tool on it to check for leaks and general crashy-ness
and it looks ok.
Created attachment 304004 [details]
This is the final patch that was committed.
I needed to change the way init was done a little so that we could exit
gracefully if an NSS call failed (and prevent an ugly loop).
I also updated the .spec to change the location of libnssckbi.so from
/usr/lib to /lib/.
And since NSS_Initialize() needs to be called after root has dropped privs
Apache needs to be able to read the NSS cert and key databases so I added a
%post script to ensure that the apache group has read access. This will fix new
and updated installations.
I just tried httpd-2.2.8-3.ppc. This version seems to fix this problem on
PowerPC. Bug #439829 documents a similar problem fixed in another package.