Made to Order Software Corporation Logo

PHP eFax requires "ssl://" on RedHat EL7 and Ubuntu

We found out today that RedHat LE7 requires the use of the "ssl://" protocol instead of the default "tls://". The error we are getting from PHP looks like this:

PHP Warning:  stream_socket_client(): SSL operation failed with code 1. OpenSSL Error messages:
error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version in .../lib/http_request.php on line 294
PHP Warning:  stream_socket_client(): Failed to enable crypto in .../lib/http_request.php on line 294
PHP Warning:  stream_socket_client(): unable to connect to tls://secure.efaxdeveloper.com:443 (Unknown error) in .../lib/http_request.php on line 294

If you have a RedHat server, please make sure to edit the http_request.php file and search for "tls:". Then replace it with "ssl:".

The TLS protocol is defined in RedHat, but somehow it looks like PHP does not define it. The stream_socket_client() function returns immediately with an $errno = 0 and $errstr = "" and absolutely no other indications to what is wrong when that happens.

So in our PHP eFax, you need to do that edit if you run on RedHat LE7 to get things to work. We could look into a way to make things work automatically, but at this point asking you to do that small edit is the safest way to make sure we do not break other people's installations.

There is the current original code (v1.9+):

// the "tls://" may need to be replaced by "ssl://" on some
// systems if $s is NULL after the call to stream_socket_client()
// (i.e. RedHat EL7 still requires "ssl://")
//
$context = stream_context_create();
$s = stream_socket_client('tls://' . $server['host'] . ':' . $server['port'], $errno, $errstr, 60, STREAM_CLIENT_CONNECT, $context);

Edit the last line so it looks like this:

$s = stream_socket_client('ssl://' . $server['host'] . ':' . $server['port'], $errno, $errstr, 60, STREAM_CLIENT_CONNECT, $context);

Then you should be able to send faxes just like that.


Update Oct 2018:

In version 1.10 we actually try both protocols. We decided to try "ssl:" first though because it looks like most computers work as expected with that protocol. If that fails, though, we try again with "tls:". The only glitch is that the first attempt will generate errors. If that is the case on your server, feel free to edit the file and swap the order in which we try to connect. All you have to swap is the protocol ("ssl:"    "tls:").

We are currently hoping that pretty much everyone will be using "ssl:" successfully.