On 06/10/2015 06:15 AM, Paul Wouters wrote:
The most likely cause is nss wasn't opened using /etc/ipsec.d as it's database. If this is a library, this could be caused by the application opening it's own database first, which means the default slot will be whatever the application openned. If you check the slot for your database, it should still be a FIPS slot.Hi, I'm trying to do various FIPS tests for libreswan. Our testing system using KVM is a little tricky to selectively boot with fips=1, so I did some scripting to get everything into faked FIPS mode. It basically comes down to first running a script that: - creates /etc/system-fips - disable selinux (for next step) - fake /proc/sys/crypto/fips_enabled by echo "1" > /tmp/fips_enabled mount --bind /tmp/fips_enabled /proc/sys/crypto/fips_enabled - running modutil: /usr/bin/modutil -dbdir /etc/ipsec.d -fips true -force /usr/bin/modutil -dbdir /etc/ipsec.d -chkfips true (which DOES output: (FIPS mode enabled.") - starting libreswan via systemctl start ipsec.service libreswan, which has its own checks for /proc/sys/crypto/fips_enabled and /etc/system-fips confirms it is in FIPS mode. But somehow, the NSS library is still not in FIPS mode. I suspect the dance through systemd might cause this? Do some environment variables get set and lost? Is there a way to export some environment variables to force NSS harder?
bob
Paul
smime.p7s
Description: S/MIME Cryptographic Signature
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
