For some reason, I wasn't able to reproduce the problem described in the initial
comment; not with stock RHEL-6.2 rhn-client-tools, nor with
rhn-client-tools-1.7.14-1.el6 from Spacewalk Client 1.7.

I installed RHEL-6.2 as a Xen para virtualized guest, appended fips=1 to
the installation kernel command line. After the installation:

# cat /proc/sys/crypto/fips_enabled 
1

Anyway, I was able to run rhn_check just fine.

In your case, is there something different from the above? Is it a RHEL,
CentOS, Scientific or Unbreakable system? How was it installed? How was
the fips mode set? Is there something special about server's certificate?

Thanks

We are running RHEL 6.2

FIPS is enabled with the kernel flag fips=1.

The certs are issued by a third party and using a 2048bit key. The only odd thing with the certs is that they do not have the CommonName or ServerName in the Subject field of the certificate.

I will try updating to rhn-client-tools 1.7.14-1.el6 and see if I still experience this issue.

In the meantime, is there any additional checks I can run or information I can gather which may be beneficial?

I doubt that upgrading rhn-client-tools would help in this situation.

I'm more interested in the signature algorithm of your certificate,
because it seems like fips mode and the algorithm do not like each other.

Signature Algorithm: sha256WithRSAEncryption

As an aside, We are running mod_ssl on the server. We've attempted to switch to mod_nss and have run into additional errors (below):

Stopping httpd:                                            [FAILED]
Starting httpd: [Tue Jun 12 10:49:44 2012] [notice] SELinux policy enabled; httpd running as context unconfined_u:system_r:httpd_t:s0
[Tue Jun 12 10:49:44 2012] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Tue Jun 12 10:49:44 2012] [error] The server key database has not been initialized.
[Tue Jun 12 10:49:44 2012] [warn] Cipher rsa_rc4_128_md5 is enabled but this is not a FIPS cipher, disabling.
[Tue Jun 12 10:49:44 2012] [warn] Cipher rsa_rc4_128_sha is enabled but this is not a FIPS cipher, disabling.
[Tue Jun 12 10:49:44 2012] [error] Certificate not found: 'Server-Cert'
                                                           [FAILED]

Here is some additional information:

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

Server-Cert                                                  u,u,u
My Local CA                                                  CT,, 

Do you see anything wrong with our nss.conf?

NSSFIPS on
NSSPassPhraseDialog  file:////etc/httpd/conf/password.conf
NSSPassPhraseHelper /usr/sbin/nss_pcache
NSSSessionCacheSize 10000
NSSSessionCacheTimeout 100
NSSSession3CacheTimeout 86400
NSSRandomSeed startup builtin
NSSRenegotiation off
NSSRequireSafeNegotiation off
NSSEngine on
NSSCipherSuite +rsa_rc4_128_md5,+rsa_rc4_128_sha,+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

modutil -chkfips true -dbdir /etc/httpd/alias
FIPS mode enabled.

Not really sure about that mod_nss thing.

About that rhn_check and fips problem -- it's really odd, although
I doubt this really is a rhn-client-tools (or Spacewalk client if you will)
problem, since the error you're seeing is propagated to the user all
the way from libcrypt (openssl).

Could you perhaps try this command run from the problematic client machine
to see whether it would work:

openssl s_client \
        -host your.spacewalk.hostname \
        -port 443 \
        -CAfile /path/to/ca-certificate

?

Thanks

I'm closing this report with notabug, as this does not seem to be
a problem in Spacewalk alone.

This BZ closed some time during 2.5, 2.6 or 2.7.  Adding to 2.7 tracking bug.