Re: intermittent Apache/OpenSSL error hangs server
On Thursday, 9 January 2020 17:42:47 CET, Jerry Blasdel wrote: Here is more information. On the server that is having this issue, prior to the FIPS_drbg_generate errors (these show up every time that worker pid is selected to serve a request) we have a single OpenSSL error that shows up in the logs. SSL Library Error: error:2D06A07F: FIPS routines: FIPS_CHECK_EC:pairwise test failed Once we get that error, every time we try to serve a request in Apache using that pid, it errors out. So, it seems like something randomly corrupts that PID. Can someone provide some information about FIPS_CHECK_EC: pairwise test failed. I would try to eliminate hardware issue as a possible cause: run memcheck, cpu stress tests, etc. Thanks On Tue, Jan 7, 2020 at 7:21 AM Jerry Blasdel wrote: I have several servers configured the same, running Apache 2.4X/OpenSSL1.02 fips-enabled. On one server we periodically get the following errors in the Apache logs: SSL Library Error: error:xx:FIPS_drbg_generate:selftest failed. In some cases, the server continues to service requests, but in other cases ... -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic
Re: intermittent Apache/OpenSSL error hangs server
>Once we get that error, every time we try to serve a request in Apache using >that pid, it errors out. So, it seems like something randomly corrupts that >PID. Can someone provide some information about FIPS_CHECK_EC: pairwise test >failed. Once FIPS detects an error, it will stay stuck in error-state until you re-initialize. Sorry, can’t provide more details about the specific test that’s failing.
Re: intermittent Apache/OpenSSL error hangs server
Here is more information. On the server that is having this issue, prior to the FIPS_drbg_generate errors (these show up every time that worker pid is selected to serve a request) we have a single OpenSSL error that shows up in the logs. SSL Library Error: error:2D06A07F: FIPS routines: FIPS_CHECK_EC:pairwise test failed Once we get that error, every time we try to serve a request in Apache using that pid, it errors out. So, it seems like something randomly corrupts that PID. Can someone provide some information about FIPS_CHECK_EC: pairwise test failed. Thanks On Tue, Jan 7, 2020 at 7:21 AM Jerry Blasdel wrote: > I have several servers configured the same, running Apache > 2.4X/OpenSSL1.02 fips-enabled. > > On one server we periodically get the following errors in the Apache logs: > > SSL Library Error: error:xx:FIPS_drbg_generate:selftest failed. In > some cases, the server continues to service requests, but in other cases > the server hangs and will not process requests until the worker pid > receiving the error is killed, or a kill -HUP is issues on the Apache root > pid. > > I see someone else had a similar issue but I can't find any resolution. > > https://mta.openssl.org/pipermail/openssl-users/2016-October/004657.html > > Other information... > > We have looked at the entropy on the server when it is working properly vs > when it hangs and could not find any big differences. > > Also, SSLRandomSeed is configured for startup and connect in Apache. > > Any help would be appreciated. > > Thanks >
Fwd: Disabling SSL Issue Date Validation
I am trying to disable Server's Certificate Issue Date Validation in libcurl. For that, I have registered a own_verify_callback function by calling SSL_CTX_set_verify in sslContextVerify callback (set via curl_easy_setopt(curl, CURLOPT_SSL_CTX_FUNCTION, sslContextVerify)). The "own_verify_callback" gets called (I have print in this function and they are printed on console) and it returns 1 but still curl connection fails (i.e., curl_easy_perform returns with an error) with error "SSL certificate verify result: certificate is not yet valid (9)". However, it should allow the connection. I have set the system's date and time to 1990 and I was testing the Issue Date Validation. Looks like there is a bug in libcurl or I am missing something important?. Is there something I am doing wrong or is it a well-known bug? My code is below: https://stackoverflow.com/questions/59662414/disabling-ssl-issue-date-validation-in-libcurl
RE: Default certificate path taken by openssl
Hi Viktor, Thank you for the information. It was helpful. With Regards, Chethan Kumar -Original Message- From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Viktor Dukhovni Sent: Thursday, January 9, 2020 12:35 PM To: openssl-users@openssl.org Subject: Re: Default certificate path taken by openssl On Thu, Jan 09, 2020 at 06:42:36AM +, Chethan Kumar wrote: > In Linux, if any application which uses openssl does not specify the > path from which certificates should be read by openssl, does openssl > try to read from default path or something? OpenSSL has a default cert store path, but it is up to applications to request use of the default paths for certificate validation. Many do, some don't. > Need help in this as there is one > ca-bundle.crt(\usr\lib\ssl\certs\ca-bundle.crt)" file in machine and > we use our own ca-bundle.crt in another path. Is this a Linux machine or a Windows machine? You're using backslash as a path separator, which is not something that Works on POSIX systems (e.g. Linux). > Is it ok to remove \usr\lib\ssl\certs\ca-bundle.crt file if we don't use this? You can remove whatever you want, but if it is installed by an OS package, something might break if you do. This question is best asked of your Linux vendor, the upstream OpenSSL project does not bundle any trusted certificates. -- Viktor. The information contained in this e-mail message and in any attachments/annexure/appendices is confidential to the recipient and may contain privileged information. If you are not the intended recipient, please notify the sender and delete the message along with any attachments/annexure/appendices. You should not disclose, copy or otherwise use the information contained in the message or any annexure. Any views expressed in this e-mail are those of the individual sender except where the sender specifically states them to be the views of Toshiba Software India Pvt. Ltd. (TSIP),Bangalore. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or damage arising in any way from its use.
