PHP cannot use SSL

[joepvd]

There was a report that PHP cannot use SSL/TLS with php's curl. Normal curl does work.

The error: string(76) "gnutls_handshake() failed: A TLS packet with unexpected length was received."

This happens with a wide array of SSL options.

Log: https://travis-ci.org/joepvd/travis-experiment/jobs/146108809
Test case (courtesy @TextControl): https://github.com/joepvd/travis-experiment/tree/17a779c65604f2df07d9227811ed7970f4bc593a

[BanzaiMan]

In http://stackoverflow.com/a/38429611/136333, @jonathanmaron reports that the official Ubuntu packages (php5-cli and php5-curl) are sufficient to have this issue resolved.

Our binaries are compiled using https://github.com/php-build/php-build with our build process shown in https://github.com/travis-ci/php-src-builder (in particular https://github.com/travis-ci/php-src-builder/blob/default/bin/compile). The process needs to be updated (either via php-build or via our compile script), but I have very few ideas as to how to make that happen.

[rdok]

@joepvd have you proceeded with rebuilding the PHP package? I've been having the same problem. https://travis-ci.org/rdok/elasticemail-php/jobs/157308268

@BanzaiMan I did try @jonathanmaron suggestion. I did not manage to make it work. Moreover, this suggestion is viable only for PHP 5.5 according to @jonathanmaron

Thanks in advance!

[hohl]

I'm using php7-curl and got the same issue. So this issue seems not to be related to PHP 5.5 only. Does anybody ever found a workaround for this issue?

[BanzaiMan]

My understanding is that the PHP binary will have to be recompiled (I indicated the process in the comment above), but I don't know how to make that happen.

[hohl]

Yes, I had the same issue on my local (macOS) testing machine where I used the preinstalled PHP7 and cURL. Since I got the same issue I updated cURL and then recompiled PHP which solved the issue.

[andig]

For me this issue has started just a few days ago. Before that PHP builds were going fine.

[Stafox]

Got the same, guys.
Builds on php 7.0 and hhvm always passed successfully. But on php 5.5, 5.6 and 7.1 with error:
cURL error 35: gnutls_handshake() failed: A TLS fatal alert has been received
After 7-8 restarts the build on I got green light on php 5.5 only.

Whilst I had writing this message all builds have passed successfully

[Kolyunya]

I can confirm the issue for the PHP 5.4 environment. 5.5, 5.6, 7.0, 7.1, hhvm and nightly are just fine. Not sure about 5.3 though. Looking forward for a fix. Thank you!

[jonnybarnes]

I still get this issue if I use a non-https endpoint with sensiolab’s security checker.

[alexfinnarn]

Yeah, I don't think this issue is fixed...

I only have

language: php
sudo: false

php:
  - '7.1'

in my .travis.yml file relating to PHP. I'm not sure how this works for other people other than the HTTPS to HTTP URL switching I see in some referenced commits above.

      GuzzleHttp\Exception\ConnectException: cURL error 35: gnutls_handshake() failed: A TLS packet with unexpected length was received. (see http://curl.haxx.se/libcurl/c/libcurl-errors.html) in vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php:186

[rpkamp]

I just ran into this problem yet again.

@joepvd any update on this? It's been more that a year now.

[markdza]

Still an issue. Can we get a fix for this please? Our case is with issue #8912 (above)

[markdza]

Can this issue be resolved please?

[MrPetovan]

I just got this issue, Travis Git can't retrieve a repository from a TLS 1.2-only SNI-enabled domain: https://travis-ci.org/friendica/friendica/jobs/434668926#L566

Full error:

[RuntimeException]                                                           
Failed to execute git clone --no-checkout 'https://git.friendi.ca/friendica/php-json-ld'
'/home/travis/build/friendica/friendica/vendor/friendica/json-ld'
&& cd '/home/travis/build/friendica/friendica/vendor/friendica/json-ld'
&& git remote add composer 'https://git.friendi.ca/friendica/php-json-ld'  
&& git fetch composer                                                       

Cloning into '/home/travis/build/friendica/friendica/vendor/friendica/json-ld'...                                                                       
fatal: unable to access 'https://git.friendi.ca/friendica/php-json-ld/': gnutls_handshake() failed: Handshake failed

SSLabs report: https://www.ssllabs.com/ssltest/analyze.html?d=git.friendi.ca&s=138.201.30.223

It still sounds like updating GNU TLS would fix the issue.

[afk11]

A project of ours encountered this issue a while back, around the time we moved our infrastructure. I only stumbled across this issue because I noticed curl was using gnutls, whereas my laptop was using openssl.

Testing against 7.1.18 did make the issue go away. I gave the c code a brief scan, and not 100% sure it's the issue, but I can't see it scanning the certificates directory like openssl does - just the certificates bundle file.

[MrPetovan]

It appears the PHP CLI used by Travis to run Composer uses GNU TLS no matter the PHP version: https://travis-ci.org/friendica/friendica/builds/437234785

[mlwilkerson]

I had the same problem on Trusty with 7.1 and specifying 7.1.18 resolved it for me as well.

On Precise with 7.1 it works. On Trusty with 7.1.18, it works.

Can anyone shed light on what this means out in the wild? I'm trying to anticipate customer support issues that may come up when I ship this WordPress plugin and—maybe—in some WordPress installations, my code will fail like it does running in Travis CI on Trusty with Php 7.1. Based on what we're seeing here in Travis CI, those failures might be because... why? Because the php interpreter is built with older GnuTLS instead of newer OpenSSL and is thus failing to handle some newer SSL certificates?

[mlwilkerson]

Update: I needed to get a test matrix working with some older php versions as well, but when specifying 5.6 in .travis.yml, or 7.0 I was just getting more php versions that failed on the GnuTLS thing. So I did some poking around and found that all of the following versions work. I have a nice, clean, green test matrix now:

(These first two were mentioned above)

• 7.2.6
• 7.1.18
  (I dug around to find a couple more older ones)
• 7.0.32
• 5.6.37

So, I'm just specifying these in my .travis.yml like this:

matrix:
  include:
  - php: 7.2.6
    env: WP_VERSION=latest
  - php: 7.1.18
    env: WP_VERSION=latest
  - php: 7.0.32
    env: WP_VERSION=latest
  - php: 5.6.37
    env: WP_VERSION=4.4
  - php: 5.6.37
    env: WP_VERSION=latest

[louwie17]

Updating from trusty to xenial fixed this issue for me, as they contain newer minor version of php.