It looks like php5 was changed to accomodate whatever openssl was doing. It's difficult to tell whether something has been changed on the openssl side in the meantime but considering how long it's been, I see no reason to keep this bug open.
-- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/592442 Title: fopen fails on some SSL urls Status in php: Unknown Status in openssl package in Ubuntu: Confirmed Status in php5 package in Ubuntu: Fix Released Bug description: Binary package hint: php5 Description: Ubuntu 10.04 LTS Release: 10.04 php5: Installed: 5.3.2-1ubuntu4.2 Candidate: 5.3.2-1ubuntu4.2 Version table: *** 5.3.2-1ubuntu4.2 0 500 http://archive.ubuntu.com/ubuntu/ lucid-updates/main Packages 100 /var/lib/dpkg/status 5.3.2-1ubuntu4 0 500 http://archive.ubuntu.com/ubuntu/ lucid/main Packages For some reason I can't seem to get the following to work. I suspect a SSL problem. Maybe the intermediate SSL cert is not being recognized properly? The server cert is signed by geotrust (which is an intermediate of equifax[1]). I put the following in a file called /tmp/fopen.php: <?php if (fopen("https://www.google.com","r";)) { print "www.google.com worked\n"; } if (fopen("https://cas.ucdavis.edu","r";)) { print "cas.ucdavis.edu worked\n"; } ?> Then I run the php via an apache web and/or via the php5-cli (the results are the same in both cases): $ php /tmp/fopen.php www.google.com worked PHP Warning: fopen(): SSL operation failed with code 1. OpenSSL Error messages: error:140773F2:SSL routines:func(119):reason(1010) in /tmp/fopen.php on line 3 PHP Warning: fopen(): Failed to enable crypto in /tmp/fopen.php on line 3 PHP Warning: fopen(https://cas.ucdavis.edu): failed to open stream: operation failed in /tmp/fopen.php on line 3 $ When I run the above command on a karmic or jaunty machine it works fine for both fopen() calls. I've attached a tcpdump of the above script. As you can see from the dump, Google is working but my server is not. I get an SSL alert packet (packet #29) back with code 10 (unexpected message). Maybe this is an intermediate cert verification problem? What is funny is that I get an ACK right before that. It seems like maybe the server is sending an ACK, client starts talking, server isn't ready and sends an out-of-order message. Scott ----------- [1] https://www.geotrust.com/resources/root-certificates/index.html To manage notifications about this bug go to: https://bugs.launchpad.net/php/+bug/592442/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
