Bug 824591
| Summary: | "Unknown Cipher" when using rhn-client-tools with FIPS mode enabled | ||
|---|---|---|---|
| Product: | [Community] Spacewalk | Reporter: | Ted W. <ted-redhat> |
| Component: | Clients | Assignee: | Milan Zázrivec <mzazrivec> |
| Status: | CLOSED NOTABUG | QA Contact: | Red Hat Satellite QA List <satqe-list> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 1.6 | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-02-01 10:13:15 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1484117 | ||
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. |
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