[Bug 592442] Re: fopen fails on some SSL urls

Finjon Kiang 592442 at bugs.launchpad.net
Sat Dec 3 01:16:18 UTC 2011

@Clint, thanks for the test. I've created another bug


You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to openssl in Ubuntu.

  fopen fails on some SSL urls

Status in PHP: Hypertext Preprocessor:
Status in “openssl” package in Ubuntu:
Status in “php5” package in Ubuntu:
  Fix Released

Bug description:
  Binary package hint: php5

  Description:	Ubuntu 10.04 LTS
  Release:	10.04

    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:

  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

  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.

  [1] https://www.geotrust.com/resources/root-certificates/index.html

To manage notifications about this bug go to:

More information about the foundations-bugs mailing list