Today we discovered that our SSL system on our server broke when we upgraded the server to Ubuntu 8.10 (Intrepid.)

The technical error message is rather cryptic:

  SSL connect error; error:140773F2:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 ...  
          ... alert unexpected message (https://secure.example.com/path.php)

I also get this message from HttpRequest (in our PHP server running with Apache):

   Empty or too short HTTP message

And according to some people, if the load of your server is too high, you may get that error. So I guess that error is just not describing what the error really is because our load is very small (1% processor...)

As you can see, the SSL breaks, it does not tell us why. Just that something broke.

Testing with curl, I found out that there was no certificate for the SSL system to work, so says curl at least:

*   CAfile: none
    CApath: /etc/ssl/certs

The error is pretty clear, right?

I found a site where the error is inverted. The CAfile is found, but not the path.

*   CAfile: /etc/ssl/certs/ca-certificates.crt
    CApath: none

The solution, in this case, is to make sure that you have the CA certificate package installed. This is done with sudo and apt-get like this:

    > sudo apt-get install ca-certificates

This will install the ca-certificates.crt file. In my case, however, the file is there and looks proper.

Now when I try to find out what package it is from, that fails:

   > dpkg -S /etc/ssl/certs/ca-certificates.crt
   dpkg: /etc/ssl/certs/ca-certificates.crt not found.

But the CAfile/CApath maybe either way and it works with curl in the command line!

However, I found a page on PHP.net with the error and that's definitively the same problem I'm having. This was with PHP 5.2. The interesting thing is that they have one more line to setup the HttpRequest, they setup 2 options like this:

$o = array(
  'redirect' => '3',
  'ssl' => array(
    'version' => '3',
    'verifyhost' => '1'
  ));

By adding that code to my PHP function the HttpRequest started working again just like before. I think the problem was with the SSL version, although it is not clear. It could have been the redirect, but the error had nothing to do with a redirect (Any 3xx, usually 301 or 302 from the destination server, can be any number between 300 and 399 inclusive.)

I use the $o variable with the HttpRequest::setOptions() function before calling send() and it works!