Bug 1742190

This does not seem specific to foreman_scap_client but rather ssl certificates that subscription-manager/capsule uses. More specifically what keys are used in them.

Onkar,

is the Satellite host running in FIPS mode too? Can we have a reproducer for that? Do other features (yum, puppet) work fine in that setup?

Thanks!

Here are my observations about this bug. 

Satellite 6.6 running non-FIPS mode
RHEL 8 client with FIPS enabled

When setting the crypto policy to FUTURE, it doesn't even allow to install the katello-ca-consumer package
  # update-crypto-policies --set FUTURE
  # rpm -ivh katello-ca-consumer-latest.noarch.rpm
Verifying...                          ################################# [100%]
Preparing...                          ################################# [100%]
package katello-ca-consumer-satellite.example.com-1.0-4.noarch does not verify: no digest

  # rpm -ivh katello-ca-consumer-latest.noarch.rpm --nofiledigest --nodigest   -----> forcing a way to install the package

Even after forcing the package to be installed, subscription-manager register will fail as below

  # subscription-manager register --org="RedHat" --environment="Library" --auto-attach 
  Registering to: satellite.example.com:443/rhsm
  Unable to verify server's identity: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:877)

Per https://access.redhat.com/articles/3642912 FUTURE crypto policies should have a key length of 3071 or greater 

Checking the public key cert on my satellite (which is 2048 bytes)
  # echo | openssl s_client -connect $(hostname):443 2>/dev/null | openssl x509 -text -noout | grep 'Public-Key'
                Public-Key: (2048 bit)

We have an RFE opened to customize the key length in the satellite-installer itself https://bugzilla.redhat.com/show_bug.cgi?id=1749916

With crypto policy set to FUTURE, foreman_scap_client would fail with below error

 # foreman_scap_client 1
 DEBUG: running: oscap xccdf eval  --profile xccdf_org.ssgproject.content_profile_standard  --results-arf /tmp/d20191129-16243-1qx7hiu/results.xml /var/lib/openscap/content/96c2a9d5278d5da905221bbb2dc61d0ace7ee3d97f021fccac994d26296d986d.xml
 WARNING: This content points out to the remote resources. Use `--fetch-remote-resources' option to download them.
 WARNING: Skipping https://www.redhat.com/security/data/oval/com.redhat.rhsa-RHEL7.xml.bz2 file which is referenced from XCCDF content
 DEBUG: running: /usr/bin/env bzip2 /tmp/d20191129-16243-1qx7hiu/results.xml
 Uploading results to https://satellite.example.com.com:9090/compliance/arf/1
 Upload failed: SSL_connect returned=1 errno=0 state=error: sslv3 alert handshake failure

Resetting the crypto policy back to DEFAULT

 # update-crypto-policies --set DEFAULT
 # foreman_scap_client 1
 DEBUG: running: oscap xccdf eval  --profile xccdf_org.ssgproject.content_profile_standard  --results-arf /tmp/d20191129-16063-siiurm/results.xml /var/lib/openscap/content/96c2a9d5278d5da905221bbb2dc61d0ace7ee3d97f021fccac994d26296d986d.xml
 WARNING: This content points out to the remote resources. Use `--fetch-remote-resources' option to download them.
 WARNING: Skipping https://www.redhat.com/security/data/oval/com.redhat.rhsa-RHEL7.xml.bz2 file which is referenced from XCCDF content
 DEBUG: running: /usr/bin/env bzip2 /tmp/d20191129-16063-siiurm/results.xml
 Uploading results to https://satellite.example.com:9090/compliance/arf/1
 Report uploaded, report id: 41

Conclusion:

With RHEL8 crypto policy set to FUTURE, 
 1. Installation of Bootstrap RPM would fail 
 2. Registration would fail
 3. foreman_scap_client runs would fail

The only way to work around this is to set the crypto policy to DEFAULT or LEGACY (DEFAULT is preferred as it provides additional security as compared to LEGACY refer to https://access.redhat.com/articles/3642912 for more info on these crypto policies shipped with RHEL8)

Looks like https://community.theforeman.org/t/ciphers-inconsistent-with-documentation/17187 explains why it's failing (I'm having the same problem).. It would be really nice if RedHat could fix so you actually can scan a machine with crypto policy fips/future..

Until Satellite 6.8, the certificate key lengths generated by Satellite were 2048. On fresh install of Satellite 6.8, certificates default to 4096. For upgraded Satellite 6.8, the user has to take an additional action to increase the key size and has implications on already deployed certificates.

With the introduction of the KCS article and 4096 being the default key size on new installations I am going to officially set this to CLOSED CURRENTRELEASE.


https://access.redhat.com/solutions/5393241