FIPS compatible config. This will guide will cover 64 bit Linux installation only.
1.) First update the repo cache, then install the NSS package on the host
RHEL6/7 family: yum update yum install nss-pkcs11-devel
Debian 8 family: apt-get update apt install libnss3-tools
2.) Create the FIPS-140 compliant PKCS-11 cryto provider and security token
The "token" practically is a database, we'll use this in Crush as the SSL cert store (in opposite to normal operation mode PKCS12 compliant "file" ). In case the Crush process isn't running as root, will need to change the ownership and permissions on the database folder accordingly.
mkdir -p /var/opt/nss/crush-nssdb modutil -create -dbdir /var/opt/nss/crush-nssdb
Create the NSS config file
touch /var/opt/nss/nss_pkcsll_fips.cfg
then edit it
vi /var/opt/nss/nss_pkcsll_fips.cfg
and paste into the following ( Centos/Redhat)
name = NSS nssLibraryDirectory=/usr/lib64 nssSecmodDirectory=/var/opt/nss/crush-nssdb nssModule = fips
On Debian/Ubuntu the NSS libraries are located at /usr/lib/x86_64-linux-gnu/nss
Now enable FIPS mode on the token
modutil -fips true -dbdir /var/opt/nss/crush-nssdb
should get a confirmation message prompt, indicating all operations until this step were successful.
At this point, we can set the password on the token
modutil -changepw "NSS FIPS 140-2 Certificate DB" -dbdir /var/opt/nss/crush-nssdb
when prompted for , enter a password or just hit Enter for blank, will need to use the password in Crush later, if set. In the below steps, no password was used.
3.) Import or issue FIPS-140 compliant certificate
Certutil allows any regular PKI operations to generate key pair and issue certs, import, etc. By this example will just import from a PKCS12 cert store, most real life-like scenario, for an existing cert
pk12util -i intranet_local.p12 -d /var/opt/nss/crush-nssdb
If the .p12 file was password protected, there will be a prompt to enter the password.
Check if key and cert chain in place
certutil -K -d /var/opt/nss/crush-nssdb certutil -L -d /var/opt/nss/crush-nssdb
4.) Configure Java crypto bridge for FIPS-140 mode
Can modify the server wide Java environment, though, for easy switching (or emergency reversal) between FIPS and non-FIPS mode, it's recommanded to use a Java alternative installation for Crush only. In this example , Oracle Java JRE 8 with JCE plicy files applied (mandatory), placed into /var/opt/java8-fips/ folder. Edit the java.security config file
vi /var/opt/java8-fips/lib/security/java.security
Find this line
"# List of providers and their preference orders"
edit the crypto provider list to be:
security.provider.1=sun.security.provider.Sun security.provider.2=sun.security.rsa.SunRsaSign security.provider.3=sun.security.ec.SunEC security.provider.4=com.sun.net.ssl.internal.ssl.Provider SunPKCS11-NSS security.provider.5=com.sun.crypto.provider.SunJCE security.provider.6=sun.security.jgss.SunProvider security.provider.7=com.sun.security.sasl.Provider security.provider.8=org.jcp.xml.dsig.internal.dom.XMLDSigRI security.provider.9=sun.security.smartcardio.SunPCSC security.provider.10=sun.security.pkcs11.SunPKCS11 /var/opt/nss/nss_pkcsll_fips.cfg security.provider.11=sun.security.pkcs11.SunPKCS11-NSScrypto
5.) Configure Crush
First, we need to switch over to the FIPS compliant Java environment, for that edit the init script , modify the $JAVA local environment variable to point to the new Java main binary
vi /var/opt/CrushFTP8_PC/crushftp_init.sh
find the line
JAVA="java"
comment it out then add in place
JAVA="/var/opt/java8-fips/bin/java"
then edit the main server config file prefs.XML , set the <fips140>false</fips140> key value to "true". After this step, before restarting the service, log in into the Webinterface as the main admin, navigate to Preferences->Encryption->SSL page enter into the "Keystore Location" field the "PKCS11" literal (without the quotes), supply the PKCS11 token password, if any set in Step 2. In both "Tls versions" fields leave only "TLSv1,TLSv1.1" , save.
<screencap image placeholder [1] >
Restart the Crush service afterwards
systemctl restart crushftp
Normally, all SSL ports should come on line after this step ( HTTPS, FTPES, FTPS ), can test with a client application. SSL cypher assessment should reveal now only FIPS-140-2 compliant cyphers.
<screencap image placeholder [2] >
Warning: At this point the HTTPS port may go offline, if token password was incorrect, or the PKCS11 token bad, etc., make sure there is an plain HTTP port available for adminstration. In case the java.security config file has syntax errors, the Crush service may not come on line at all.
Running in FIPS mode has a few drawbacks:
- online updates won't work, for our update repo server is not running in FIPS compliant mode, can only use the manual update method ( from file) - server to server connections against a non-FIPS compliant server won't work either, when using VFS proxy or CrushTask. - ldaps:// connections for the SAML or LDAP Group plugin don't work as well unless the directory controller is also set to FIPS mode, the trusted cert needs to be imported into the PKCS11 trust store; plain ldap:// will work just fine - some web browsers may not work with the FIPS compliant cypher set - SSL cypher strength assessment will never give the server "A" or close rating, for many of the FIPS compliant cyphers are "B"-rated, or lower.
HIPPA certification. CrushFTP is not HIPPA compliant by default, but can be 'hardened' in a few simple steps, to be HIPPAA compliant. Practically, we need to use latest Java with JCE policy files installed then remove the plain HTTP ports, set enforce FTP to FTPES or use FTPS, disable all insecure SSL cyphers, possibly set <fips140>false</fips140> to true in the main config file, prefs.XML. That and paired with on premises hosting will make crush HIPPAA compliant ( actually we have quite a large number of customers from within healthcare environments). Please see our related docs, let us know if need further info
- Replication*http://www.crushftp.com/crush8wiki/Wiki.jsp?page=Hardening