Bug 450349 - Enabling FIPS mode does not work in mod_nss
Enabling FIPS mode does not work in mod_nss
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: mod_nss (Show other bugs)
5.2
All Linux
high Severity high
: rc
: ---
Assigned To: Rob Crittenden
Chandrasekar Kannan
:
Depends On: 446851
Blocks:
  Show dependency treegraph
 
Reported: 2008-06-06 17:02 EDT by Martin Poole
Modified: 2015-01-04 18:32 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-20 15:34:48 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Fix NSSFips mode (2.22 KB, patch)
2008-07-01 22:40 EDT, Rob Crittenden
no flags Details | Diff

  None (edit)
Description Martin Poole 2008-06-06 17:02:03 EDT
+++ This bug was initially created as a clone of Bug #446851 +++

As reported in directory-fedora-users list:

I am having trouble getting mod_nss to work in FIPS mode.  Summary of
the problem:  mod_nss works fine before FIPS mode is enabled, then
cannot find the certificate after enabling it.

Here is my setup:

CentOS 5 64-bit
Apache 2.2.3 from distro RPM, pre-fork MPM
NSS libraries, tools, etc from distro RPMs (3.11.7-1.3)
I have tried both mod_nss from distro rpm (1.0.3-4) and 1.0.7 compiled
from source


Here is the configuration for mod_nss I am using in Apache.  It is
basically the defaults


Listen 443
AddType application/x-x509-ca-cert .crt
AddType application/x-pkcs7-crl    .crl
NSSPassPhraseDialog  builtin
NSSPassPhraseHelper /usr/sbin/nss_pcache
NSSSessionCacheSize 10000
NSSSessionCacheTimeout 100
NSSSession3CacheTimeout 86400
NSSRandomSeed startup builtin
<VirtualHost _default_:443>
LogLevel warn
NSSEngine on
NSSCipherSuite
+rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_null_md5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_128_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+rsa_aes_256_sha
NSSProtocol SSLv3,TLSv1
NSSNickname Server-Cert
NSSCertificateDatabase /etc/httpd/alias
<Files ~ "\.(cgi|shtml|phtml|php3?)$">
    NSSOptions +StdEnvVars
</Files>
<Directory "/etc/httpd/cgi-bin">
    NSSOptions +StdEnvVars
</Directory>
</VirtualHost>



This is using the /etc/httpd/alias cert database, that the mod_nss RPM
created with a default certificate named Server-Cert.

Using that default configuration, the Apache server starts fine and
loads mod_nss.

However, when I enable FIPS mode in mod_nss (By adding "NSSFIPS on" to
Apache config), I can't get it to find the same server certificate


[Thu May 15 13:41:21 2008] [info] Init: Initializing NSS library
[Thu May 15 13:41:21 2008] [info] Initializing SSL Session Cache of
size 10000. SSL2 timeout = 100, SSL3/TLS timeout = 86400.
[Thu May 15 13:41:21 2008] [error] The server key database has not
been initialized.
[Thu May 15 13:41:21 2008] [info] Init: Initializing (virtual) servers for SSL
[Thu May 15 13:41:21 2008] [error] Certificate not found: 'Server-Cert'


I also tried using modutil to enable FIPS mode on the cert database,
but that did not help:

# modutil -fips true -dbdir /etc/httpd/alias
<snipped warning>
Using database directory /etc/httpd/alias...
FIPS mode enabled.


# modutil -chkfips true -dbdir /etc/httpd/alias
Using database directory /etc/httpd/alias...
FIPS mode enabled.

Could someone please clue me in here.  Is there some more extensive
process I need to go through in converting the certificate database to
FIPS mode?  I have searched for more relevant info with certutil and
modutil but haven't been able to find anything.

-- Additional comment from rcritten@redhat.com on 2008-05-16 09:34 EST --
I verified this in FC-6 (similar component versions to EL 5 and CentOS 5) and F-7.

Looks like the problem is in NSS itself. To prevent hammering on tokens the NSS
PKCS#11 interface has a timer for logins so a new one may only take place every
'x' seconds (I didn't look up what 'x' defaults to).

Since mod_nss is loaded and unloaded by Apache adn we need to authenticate
multiple times basically what we're seeing is we log in ok once and subsequent
logins fail because they are coming too fast, hence the certificate can't be found.

This patch provides a workaround:

Index: nss_engine_pphrase.c
===================================================================
RCS file: /cvs/dirsec/mod_nss/nss_engine_pphrase.c,v
retrieving revision 1.10
diff -u -r1.10 nss_engine_pphrase.c
--- nss_engine_pphrase.c        22 Feb 2007 16:50:14 -0000      1.10
+++ nss_engine_pphrase.c        16 May 2008 13:34:07 -0000
@@ -62,6 +62,8 @@
     {
         PK11SlotInfo *slot = listEntry->slot;
 
+        PK11_Logout(slot);
+
         if (PK11_NeedLogin(slot) && PK11_NeedUserInit(slot)) {
             if (slot == PK11_GetInternalKeySlot()) {
                 ap_log_error(APLOG_MARK, APLOG_ERR, 0, s,


-- Additional comment from rcritten@redhat.com on 2008-05-16 10:29 EST --
File bug against NSS 3.11.7 https://bugzilla.mozilla.org/show_bug.cgi?id=434043

-- Additional comment from rcritten@redhat.com on 2008-05-16 11:17 EST --
Committed to HEAD:

Checking in nss_engine_init.c;
/cvs/dirsec/mod_nss/nss_engine_init.c,v  <--  nss_engine_init.c
new revision: 1.32; previous revision: 1.31
done
Checking in nss_engine_pphrase.c;
/cvs/dirsec/mod_nss/nss_engine_pphrase.c,v  <--  nss_engine_pphrase.c
new revision: 1.11; previous revision: 1.10
done
Comment 1 RHEL Product and Program Management 2008-06-06 17:14:05 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 2 Rob Crittenden 2008-07-01 16:04:58 EDT
The error message is the same but the patch that works in Fedora isn't working
for EL 5. Must require some other fix found in 1.0.7. Continuing investigation.
Comment 3 Rob Crittenden 2008-07-01 22:40:44 EDT
Created attachment 310750 [details]
Fix NSSFips mode

This fixes 4 problems:

1. It forces the token to logout between Apache process restarts
2. It fixes a parsing error in nss_pcache where if there was no password sent
in a STOR request the last tab would be considered part of the token name and
the slot lookup would fail.
3. If the stored token in nss_pcache is empty return a 1-byte empty string.
4. The NSS FIPS security policy requires that a database password be set.
Comment 4 Rob Crittenden 2008-07-02 11:22:50 EDT
There are 4 things to test:

1. Non-FIPS with no database password (should work)
2. FIPS with no database password (should fail)
3. Non-FIPS with a database password (should work)
4. FIPS with a database password (should work)

fails means Apache doesn't start up. works means it starts and serves pages.

To enable/disable FIPS add NSSFips on/off to /etc/httpd/conf.d/nss.conf before
the <VirtualServer> definition (I put it right after NSSEngine on)

To not prompt for a password once one is set you need to change:

NSSPassPhraseDialog  builtin

to

NSSPassPhraseDialog /path/to/password.conf (I use /etc/httpd/conf/password.conf)

The format of password.conf is 'token:password'

So if you set the database password to 'httptest' the file should look like:

internal:httptest
NSS FIPS 140-2 Certificate DB:httptest

Use modutil to set the password: 

# modutil -dbdir /etc/httpd/alias -changepw "NSS Certificate DB"

To set a blank password just press ENTER twice when prompted.
Comment 8 Rob Crittenden 2008-08-14 16:54:52 EDT
NSS doesn't support DSA ciphers on the server side (yet). DSA is a FIPS approved cipher but so is RSA.

Also, there is no need to explicitly put the database into FIPS mode. mod_nss will do that automatically if NSSFips is set to on.
Comment 13 Chandrasekar Kannan 2008-12-02 02:20:49 EST
rob, with these httpd doesn't start up.

[root@dhcp-126 conf.d]# rpm -q mod_nss httpd
mod_nss-1.0.3-6.el5
httpd-2.2.3-22.el5

[root@dhcp-126 conf.d]# cat /etc/httpd/conf/password.conf 
internal:httptest
NSS FIPS 140-2 Certificate DB:httptest


[root@dhcp-126 conf.d]# cat nss.conf | egrep -i -e engine -e fips -e dialog
#   Pass Phrase Dialog:
#   The filtering dialog program (`builtin' is a internal
#   terminal dialog) has to provide the pass phrase on stdout.
NSSPassPhraseDialog  builtin
#   SSL Engine Switch:
NSSEngine on
NSSFips on
NSSPassPhraseDialog /etc/httpd/conf/password.conf


[root@dhcp-126 conf.d]# service httpd start
Starting httpd: Please enter password for "NSS FIPS 140-2 Certificate DB" token:[Mon Dec 01 15:12:23 2008] [notice] SELinux policy enabled; httpd running as context root:system_r:httpd_t:s0
[Mon Dec 01 15:12:23 2008] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)

                                                           [FAILED]
[root@dhcp-126 conf.d]# [Mon Dec 01 15:12:35 2008] [error] The FIPS security policy requires that a password be set.
Comment 14 Chandrasekar Kannan 2008-12-02 02:28:38 EST
I noticed I had a error in nss.conf, but even after I fixed it I see the same error message.

NSSEngine on
NSSFips on
NSSPassPhraseDialog /etc/httpd/conf/password.conf
Comment 16 Rob Crittenden 2008-12-02 12:48:47 EST
The syntax on NSSPassPhraseDialog is wrong. It should read: file:/etc/httpd/conf/password.conf
Comment 17 Chandrasekar Kannan 2008-12-02 13:23:40 EST
ok. the following 4 tests were performed and can confirm that
they are working.

1. Non-FIPS with no database password (should work) - Works OK
2. FIPS with no database password (should fail) - httpd fails to start
3. Non-FIPS with a database password (should work) - works OK
4. FIPS with a database password (should work) - works OK

marking bug verified
Comment 19 errata-xmlrpc 2009-01-20 15:34:48 EST
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-0075.html

Note You need to log in before you can comment on or make changes to this bug.