Bug 824591 - "Unknown Cipher" when using rhn-client-tools with FIPS mode enabled
"Unknown Cipher" when using rhn-client-tools with FIPS mode enabled
Status: CLOSED NOTABUG
Product: Spacewalk
Classification: Community
Component: Clients (Show other bugs)
1.6
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Milan Zazrivec
Red Hat Satellite QA List
:
Depends On:
Blocks: space27
  Show dependency treegraph
 
Reported: 2012-05-23 15:29 EDT by Ted W.
Modified: 2017-09-28 13:56 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-02-01 05:13:15 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ted W. 2012-05-23 15:29:10 EDT
Description of problem: When FIPS mode is enabled the use of any rhn-client-tools fails with "Unknown Cipher" error.


Version-Release number of selected component (if applicable): rhn-client-tools-1.6.47-1.el6.noarch


How reproducible: Able to consistently reproduce the error


Steps to Reproduce:
1. Enable FIPS mode
2. On an already activated system you can run "rhn_check -vv"
  
Actual results:

Could not retrieve action item from server <RetryServer for xxx.xxx.xxx.xxx/XMLRPC>
Error code: 1While running 'queue.get': caught
<type 'exceptions.ValueError'> : error:060800A0:digital envelope routines:EVP_DigestInit_ex:unknown cipher


Expected results:

D: do_call packages.checkNeedUPdate('rhnsd=1',){}
Loaded plugins: product-id, rhnplugin
D: login(forceUpdate=False) invoked
D: readCachedLogin invoked
D: Checking pickled loginInfo, currentTime=1337801066.64, createTime=1337801052.22, expire-offset=3600.0
D: readCacheLogin(): using pickled loginInfo set to expire at 1337804652.22
D: rpcServer: Calling XMLRPC up2date.listChannels
D: local action status: (0, 'rpm database not modified since last update (or package list recently updated)', {})
D: rpcServer: Calling XMLRPC registration.welcome_message


Additional info:

uname -a
    Linux host.domain 2.6.32-220.7.1.el6.x86_64 #1 XMP Fri Feb 10 15:22:22 EST 2012 x86_64 x86_64 x86_64 GNU/Linux
Comment 2 Milan Zazrivec 2012-06-11 07:56:38 EDT
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
Comment 3 Ted W. 2012-06-11 11:31:25 EDT
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?
Comment 4 Milan Zazrivec 2012-06-12 03:25:15 EDT
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.
Comment 5 Ted W. 2012-06-12 10:58:17 EDT
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.
Comment 6 Milan Zazrivec 2012-06-14 07:44:58 EDT
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
Comment 7 Milan Zazrivec 2013-02-01 05:13:15 EST
I'm closing this report with notabug, as this does not seem to be
a problem in Spacewalk alone.
Comment 8 Eric Herget 2017-09-28 13:56:06 EDT
This BZ closed some time during 2.5, 2.6 or 2.7.  Adding to 2.7 tracking bug.

Note You need to log in before you can comment on or make changes to this bug.