I don’t want to send you off in the wrong direction (too far) with that thought, as I’m not aware of a specific known issue in relation to FIPS and suspend (though we can check-around/test, and I’ve not tried suspending with it before), but since it might be related to ciphers/ssl the reasoning is that some libraries/applications will take different actions (not just the ciphers used). As an example,
gnupg can try to do a lot more to take care not not keep things in memory for very long, and some libraries try to unprelink themselves on the fly (or something similar) when loaded. That’s to say that I wonder if there could be any similar relation.
fips=0and the report of the policy I’d hope that would be enough, though I do remember that at least in past CentOS versions that a rebuild of the initramfs is needed when first setting it up. Some modules and
dracut scripts that take action. Per below, I’d at first assume at least those stages are ok if you added
fips=0, but will need to check on CentOS 8.
The CentOS *7* dracut modules
So I would not expect a need to rebuild the initramfs (it will just place the dracut module back in again if the packages are still installed), but it might not hurt to back up the initramfs, remove the packages for fips and rebuild. (Again my knowledge on that is CentOS7 based, at the moment.)
When you set it up did you use
modutil to set FIPS mode in any NSS related db? (trying to think of other places fips modes may be set)
Maybe having something like this leftover here or at another nssdb location:
# modutil -list -dbdir /etc/pki/nssdb | grep -i fips
1. NSS Internal FIPS PKCS #11 Module
slot: NSS FIPS 140-2 User Private Key Services
token: NSS FIPS 140-2 Certificate DB
### versus (example of false/unset):
# cp /etc/pki/nssdb nssdb_test
# modutil -fips false -dbdir nssdb_test/
# modutil -list -dbdir /etc/pki/nssdb| grep -i FIPS -c
### Another more general check (example of enabled):
# modutil -chkfips false -dbdir /etc/pki/nssdb; echo $?
FIPS mode enabled.
# modutil -chkfips true -dbdir /etc/pki/nssdb; echo $?
FIPS mode enabled.
(I’m unsure of how much the CentOS8
fisp-mode-setup helper sets/unsets at the moment.)
Possibly also within the user home directory (firefox profile), though you may not have gone out of your way to set that or I’d guess may remember doing so. (and that would be firefox specific and not chrome)
curl uses libnss and is working I’m not sure if that can be related. As for firefox/chrome I believe they are using nss; though they might behave differently application side than a simpler
wget will be different from
CentOS8/RHEL8 made things a little more convenient with
update-crypto-policies, though I’m not familiar with every place it changes things at the moment, so I’m unsure if it covers things that might affect firefox and chrome (nssdb) or if it’s just under openssl configuration etc. I wish I had a spare laptop at the moment to test some things out. I might be able to get it setup as a vm just to see.
It may be worth checking on the nssdb with the
-chkfips command above in case you took any separate actions to set things there when you initially setup fips enforcement.
Otherwise at the moment I really don’t want to suggest anything like backing up and reinstalling (or testing another similar system) while avoiding setting up fips just to see if it happens to work, since at the moment I can’t be so sure it’s FIPS as it’s just a thought if it’s crypto specific (and also seems to be limited to chrome/firefox or possibly other graphical applications).
It may be worth seeing where in the ssl connection it may be failing by testing with
openssl s_server locally and a connection to another host on your network that is running
s_server. (or to see if that happens to work during the time of issue, it will report back some openssl details in browser if it does)
Maybe another random test is to login as a different user over
ssh to the laptop at the time of issue, and use X11 forwarding with firefox and confirm if it’s able to connect to anything. This way it’s for sure a new instance and avoids profile settings, and avoids a full graphical session (though it may load dbus or require
dbus-launch. I suppose a test of logging in as a different user without a reboot could be an option too. None of that will affect global settings like the system/nssdb states but maybe at least rules out the specific user’s configuration in home (assuming no related global firefox/chrome settings are in place).
I’ll check on CentOS8 when I have a chance for the fips configuration tools since I’ll need to be familiar with that myself eventually anyway. I’m not sure if I’ll be able to test sleeping to cause the issue, but if I get a chance to try that I will let you know the results.