Hide Forgot
Description of problem: We failed to restart stunnel service due to bad openSSL rpm. It fails with the following errors: Starting stunnel: 2016.04.05 11:29:59 LOG7[14425:139853811828672]: Snagged 64 random bytes from /dev/urandom 2016.04.05 11:29:59 LOG7[14425:139853811828672]: RAND_status claims sufficient entropy for the PRNG 2016.04.05 11:29:59 LOG7[14425:139853811828672]: PRNG seeded successfully 2016.04.05 11:29:59 LOG7[14425:139853811828672]: Certificate: /usr/local/st/stunnel/stunnel.pem 2016.04.05 11:29:59 LOG7[14425:139853811828672]: Certificate loaded 2016.04.05 11:29:59 LOG7[14425:139853811828672]: Key file: /usr/local/st/stunnel/stunnel.pem 2016.04.05 11:29:59 LOG7[14425:139853811828672]: Private key loaded 2016.04.05 11:29:59 LOG7[14425:139853811828672]: Loaded verify certificates from /usr/local/st/stunnel/certs.pem 2016.04.05 11:29:59 LOG7[14425:139853811828672]: Loaded /usr/local/st/stunnel/certs.pem revocation lookup file 2016.04.05 11:29:59 LOG7[14425:139853811828672]: SSL context initialized for service st 2016.04.05 11:29:59 LOG3[14425:139853811828672]: FIPS_mode_set: 2D06C06E: error:2D06C06E:FIPS routines:FIPS_module_mode_set:fingerprint does not match The problem disappears after reinstalling using the following command: yum reinstall openssl We think it is problem of openSSL RPM and it should be repackaged. Version-Release number of selected component (if applicable): rpm -q openssl openssl-1.0.1e-42.el6.x86_64 rpm -q stunnel stunnel-4.29-3.el6_6.1.x86_64 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
No, the openssl rpm is OK. However stunnel tries to run openssl in FIPS mode even if the machine is not running in FIPS mode. The prelink modifies the openssl libraries when prelinking which should not happen when the machine is properly set up for the FIPS mode. Anyway, the stunnel will no longer be running in the FIPS mode by default in the erratum that is being prepared for RHEL-6.8 so you should not experience this problem after you update to that erratum once it is released. You can workaround it for now either by disabling prelink or by setting fips=no in the stunnel configuration.
Thanks for the fastest response! Can you explain why the problem disappear when we reinstall openSSL?
Additional questions: 1) was FIPS mode was changed with new builds of OpenSSL RPM? 2) How is possible to obtain stunnel RPMs thtan not use FIPS mode?
0) Because when you reinstall openssl the library files modified by prelink are replaced with the unmodified from the rpm package. 1) No, it was incorrectly changed with previous stunnel erratum. 2) Please use the regular Red Hat support channels to make this request, I cannot help you with that here. Or simply wait for the erratum to be released.
Tomas, Thank you for the fast and informative help! I will really appreciative if you will help with this: How we can reproduce the problem again? I mean we performed "yum reinstall openssl" and the problem disappear. Can we run some command to change openssl back? We want to see stunnel exceptions upon the restart of stunnel service once again. We need it since we have fixed the bug in the configuration in the new version and want to see that the stunel problem is reproduced in the old version. please please help
You can manually change .libcrypto.so.10.hmac file that is part of the openssl package on the file system to test. Just modify the hexadecimal checksum it contains - a single byte modification should be sufficient.
Tomas, I have changed /usr/lib/.libssl.so.1.0.1e.hmac (one character). Unfortunately I success to restart stunnel: service stunnel restart Stopping stunnel: [ OK ] Starting stunnel: [ OK ] Should I do anything else? We raaly want to reproduce the restart of stunnel with exception 2016.04.05 11:29:59 LOG3[14425:139853811828672]: FIPS_mode_set: 2D06C06E: error:2D06C06E:FIPS routines:FIPS_module_mode_set:fingerprint does not match
You need to modify /usr/lib64/.libssl.so.1.0.1e.hmac which is in the x86_64 package and not the one of the i686 package.
Thank you very much! The change of file in /usr/lib64 reproduce the problem.