Bug 870856
| Summary: | cURL gets CKR_DEVICE_ERROR when posting over SSL since yum update | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Ross McKay <rmckay> | ||||
| Component: | php | Assignee: | Joe Orton <jorton> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 17 | CC: | fedora, garymayor10, jorton, nathanael, orlofsky, rcollet, rpm | ||||
| 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: | 2012-11-05 10:30:20 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: | |||||||
| Attachments: |
|
||||||
|
Description
Ross McKay
2012-10-29 02:01:08 UTC
So I'm having the same issue. Here's some of what I've done... Using curl directly I was able to perform a post via https with the same fields I was trying to use via php/curl. I downgraded php to 5.4.1 and the php curl page had the same error message I then downgraded all curl packages (curl,libcurl, libcurl-devel etc). The error changed to "SSL connect error". Yet curl from the command line my script works. I should mention I'm working with the google apis, so I'm not using the same script above but am posting to a form over SSL... http://www.sebdangerfield.me.uk/2012/10/nss-error-8023-using-aws-sdk-for-php/ Seems to shed some light on it as well I have the same problem which occurred after a yum update. Anyone using Fedora 17 as a server that relies on PHP Curl to call a secure webpage elsewhere is probably having the same problem. So people probably lost a lot of money in sales because of this i know we lost a few. These programs where in the update. Oct 25 16:48:49 Updated: btparser-0.20-1.fc17.x86_64 Oct 25 16:48:51 Updated: 1:dbus-libs-1.4.10-6.fc17.x86_64 Oct 25 16:48:55 Updated: 1:dbus-1.4.10-6.fc17.x86_64 Oct 25 16:48:59 Updated: systemtap-devel-2.0-1.fc17.x86_64 Oct 25 16:49:01 Updated: hplip-common-3.12.10-4.a.fc17.x86_64 Oct 25 16:49:04 Updated: hplip-libs-3.12.10-4.a.fc17.x86_64 Oct 25 16:49:07 Updated: systemtap-runtime-2.0-1.fc17.x86_64 Oct 25 16:49:14 Updated: systemtap-client-2.0-1.fc17.x86_64 Oct 25 16:49:18 Updated: libreport-filesystem-2.0.16-1.fc17.x86_64 Oct 25 16:49:21 Updated: libreport-python-2.0.16-1.fc17.x86_64 Oct 25 16:49:25 Updated: libreport-2.0.16-1.fc17.x86_64 Oct 25 16:49:25 Updated: abrt-libs-2.0.16-1.fc17.x86_64 Oct 25 16:49:27 Updated: abrt-2.0.16-1.fc17.x86_64 Oct 25 16:49:27 Updated: libreport-web-2.0.16-1.fc17.x86_64 Oct 25 16:49:28 Updated: libreport-plugin-kerneloops-2.0.16-1.fc17.x86_64 Oct 25 16:49:28 Updated: abrt-addon-kerneloops-2.0.16-1.fc17.x86_64 Oct 25 16:49:29 Updated: abrt-addon-vmcore-2.0.16-1.fc17.x86_64 Oct 25 16:49:30 Updated: libreport-plugin-ureport-2.0.16-1.fc17.x86_64 Oct 25 16:49:30 Updated: abrt-plugin-bodhi-2.0.16-1.fc17.x86_64 Oct 25 16:49:31 Updated: libreport-plugin-bugzilla-2.0.16-1.fc17.x86_64 Oct 25 16:49:32 Updated: abrt-addon-ccpp-2.0.16-1.fc17.x86_64 Oct 25 16:49:32 Updated: abrt-dbus-2.0.16-1.fc17.x86_64 Oct 25 16:49:34 Updated: abrt-retrace-client-2.0.16-1.fc17.x86_64 Oct 25 16:49:35 Updated: abrt-addon-python-2.0.16-1.fc17.x86_64 Oct 25 16:49:35 Updated: abrt-addon-xorg-2.0.16-1.fc17.x86_64 Oct 25 16:49:36 Updated: libreport-gtk-2.0.16-1.fc17.x86_64 Oct 25 16:49:37 Updated: abrt-gui-2.0.16-1.fc17.x86_64 Oct 25 16:49:37 Updated: libreport-plugin-logger-2.0.16-1.fc17.x86_64 Oct 25 16:49:37 Updated: abrt-desktop-2.0.16-1.fc17.x86_64 Oct 25 16:49:38 Updated: libreport-newt-2.0.16-1.fc17.x86_64 Oct 25 16:49:38 Updated: systemtap-2.0-1.fc17.x86_64 Oct 25 16:49:39 Updated: libsane-hpaio-3.12.10-4.a.fc17.x86_64 Oct 25 16:49:41 Updated: 1:dbus-x11-1.4.10-6.fc17.x86_64 Oct 25 16:49:41 Updated: 1:dbus-devel-1.4.10-6.fc17.x86_64 Oct 25 16:49:42 Updated: cagibi-0.2.0-4.fc17.x86_64 Oct 25 16:49:43 Updated: pyxdg-0.23-1.fc17.noarch Oct 25 16:50:01 Updated: 1:valgrind-3.8.1-4.fc17.x86_64 Oct 25 16:50:07 Updated: libzeitgeist-0.3.18-3.fc17.x86_64 Oct 25 16:50:08 Updated: xterm-284-1.fc17.x86_64 Oct 25 16:50:09 Updated: 1:oxygen-gtk3-1.1.1-1.fc17.x86_64 Oct 25 16:50:10 Updated: oxygen-gtk2-1.3.1-1.fc17.x86_64 Oct 25 16:50:11 Updated: systemtap-sdt-devel-2.0-1.fc17.x86_64 Nathanael i've seen that post as well and tried it but curl seems to be compiled into PHP which is giving Apache the problem. It's suddenly started using NSS which I think has got some permission problem because apache can't get it to find the correct certificate or something like that. 2 Files that got updated that are related to Curl are, curl is needed by (installed) libreport-plugin-kerneloops-2.0.16-1.fc17.x86_64 curl is needed by (installed) abrt-addon-kerneloops-2.0.16-1.fc17.x86_64 These are just reporting programs though. I'm wondering if it's giving an invalid report also. I've re-compiled PHP to include Curl which now looks like it's using OpenSSL but I don't want to install just because it might break everything so i'm holding off on that to see if we can figure it out here. Basically if i'm correct Curl has recently changed from OpenSSL to NSS and Apache can't see NSS properly because it works from the command line and it even works if I SU into the Apache user which is stranger. Steps to re-produce run this php program through apache <?php $url = "https://www.mysecurewebsite.co.uk/index.php"; $useragent = "hello"; $curlSession = curl_init(); curl_setopt($curlSession, CURLOPT_USERAGENT, $useragent); curl_setopt($curlSession, CURLOPT_URL, $url); curl_setopt($curlSession, CURLOPT_HEADER, 0); curl_setopt($curlSession, CURLOPT_POST, 1); curl_setopt($curlSession, CURLOPT_POSTFIELDS, $rd); curl_setopt($curlSession, CURLOPT_RETURNTRANSFER, 1); curl_setopt($curlSession, CURLOPT_TIMEOUT, 60); curl_setopt($curlSession, CURLOPT_SSL_VERIFYPEER, false); curl_setopt($curlSession, CURLOPT_SSL_VERIFYHOST, 0); $rawresponse = curl_exec($curlSession); print_r($rawresponse); if (curl_error($curlSession)) { echo "connection"; print_r(curl_error($curlSession)); } else { echo "no connection"; } curl_close($curlSession); echo "done"; ?> Just got it working again but had to re-compile curl to use OpenSSL and PHP. It's NSS causing this to break i'll post how to do it later. It's a temp work around until the Fedora team can get it working again. Personally I think nss has issues. I had to uninstall mod_nss since no site at all ever works if its installed. I get some lame messages in apache's log "Certificate not found: 'Server-Cert'" uninstalling mod_nss and it works fine. My shopping cart server crashed (Fedora 11) on Monday Monday Oct 29 and I rebuilt it using Fedora 17. After the default install I used "yum update" on Tuesday Oct 30. My shopping cart testing on Thursday Nov 1 reproduces the curl error "A PKCS #11 module returned CKR_DEVICE_ERROR, indicating that a problem has occurred with the token or slot." I can talk to the First Data server from the Web Browser but Curl never talks to the server. Needless to say the shopping cart is dead in the water. HTTPS is working correctly in Apache. I can confirm that have the PHP-5.4.7-10.fc17 (64 bit) installed. mod_nss-1.0.8-17.fc17 mentioned earlier is not installed. My preference would be to have normal update of Curl. Over the years, I have avoided having to compile a program on Fedora. There is always a first time. Can some one post a more detailed procedure to re-compile curl to use Open SSL and PHP? this is off the top of my head however the following should work yumdownloader --source curl yum install mock rpm -i curl...src.rpm vi path/to/curl.spec look at the %configure line in the spec - maybe bump the release version as well rpmbuild -bs path/to/curl.spec mock -r fedora-17-ARCH (i386 or x86_64) path/to/new/src.rpm then transfer the file to your server (you can run all of the following on any fedora version machine) Thanks to Hathanael for the detailed steps to compile the curl application. I concluded that I am going to need to practice this on a developmental server. Likely my first attempt will hose up a production server. As a short term work around, I migrated my shopping cart to a Fedora 16 server on my production network. As noted by the originator of this thread, Fedora 16 does not exhibit this particular failure. I cannot reproduce this issue using the attached reproducer. Tested with : httpd-2.2.2-4.fc17.x86_64 php-5.4.8-1.fc17.x86_64 curl-7.24.0-5.fc17.x86_64 nss-3.13.6-1.fc17.x86_64 And: httpd-2.4.3-12.fc18.x86_64 php-5.4.8-1.fc18.x86_64 curl-7.27.0-4.fc18.x86_64 nss-3.13.6-1.fc18.x86_64 I always get the expected response: <ewayResponse> <ewayTrxnStatus>True</ewayTrxnStatus> <ewayTrxnNumber>10167</ewayTrxnNumber> <ewayTrxnReference/><ewayTrxnOption1/><ewayTrxnOption2/><ewayTrxnOption3/> <ewayAuthCode>123456</ewayAuthCode> <ewayReturnAmount>1000</ewayReturnAmount> <ewayTrxnError>00,Transaction Approved(Test CVN Gateway)</ewayTrxnError> </ewayResponse> Can you please confirm the version used, and if the problem still occurs with the latest (php 5.4.8 is available in updates-testing) @Remi Collet: I can still reproduce the problem. Please note the version of httpd, it differs from yours, and httpd-2.4.3 is not offered (to me) in updates-testing. Tested with: httpd-2.2.22-4.fc17.x86_64 php-5.4.7-10.fc17.x86_64 curl-7.24.0-5.fc17.x86_64 nss-3.13.6-1.fc17.x86_64 And: httpd-2.2.22-4.fc17.x86_64 php-5.4.8-1.fc17.x86_64 curl-7.24.0-5.fc17.x86_64 nss-3.13.6-1.fc17.x86_64 Sorry for the typo, of course, I test with httpd-2.2.22-4.fc17.x86_64 (and httpd 2.4 is only available on f18). @Remi Collet: problem is now resolved on my laptop. I just updated with latest packages (not from updates-testing) and got the following packages. I rebooted system. NB: I rebooted system after updating PHP also! abrt-2.0.18-1.fc17.x86_64 abrt-addon-ccpp-2.0.18-1.fc17.x86_64 abrt-addon-kerneloops-2.0.18-1.fc17.x86_64 abrt-addon-python-2.0.18-1.fc17.x86_64 abrt-addon-vmcore-2.0.18-1.fc17.x86_64 abrt-addon-xorg-2.0.18-1.fc17.x86_64 abrt-dbus-2.0.18-1.fc17.x86_64 abrt-desktop-2.0.18-1.fc17.x86_64 abrt-gui-2.0.18-1.fc17.x86_64 abrt-libs-2.0.18-1.fc17.x86_64 abrt-plugin-bodhi-2.0.18-1.fc17.x86_64 abrt-retrace-client-2.0.18-1.fc17.x86_64 btparser-0.22-1.fc17.x86_64 less-444-6.fc17.x86_64 libreport-2.0.18-1.fc17.x86_64 libreport-filesystem-2.0.18-1.fc17.x86_64 libreport-gtk-2.0.18-1.fc17.x86_64 libreport-newt-2.0.18-1.fc17.x86_64 libreport-plugin-bugzilla-2.0.18-1.fc17.x86_64 libreport-plugin-kerneloops-2.0.18-1.fc17.x86_64 libreport-plugin-logger-2.0.18-1.fc17.x86_64 libreport-plugin-ureport-2.0.18-1.fc17.x86_64 libreport-python-2.0.18-1.fc17.x86_64 libreport-web-2.0.18-1.fc17.x86_64 openssh-5.9p1-27.fc17.x86_64 openssh-askpass-5.9p1-27.fc17.x86_64 openssh-clients-5.9p1-27.fc17.x86_64 openssh-server-5.9p1-27.fc17.x86_64 Something seems to have fixed it anyway! @Nathanael, Gary, Thomas: can you confirm that the issue is also fixed for you ? Hi Remi, Yes after a yum update,reboot,reinstall php and curl,restart apache and test it all works. Thanks @Gary, Ross: Thanks for the feedback. I close this one. |