UnauthorizedException when using Stripe LIVE keys

[webriq]

I don't know what I'm missing here. I've used this package for one of our app. We didn't encountered any errors using a Stripe TEST account until recently we made a go for this on a Stripe LIVE account. Somehow, an UnauthorizedException from this package is thrown.

Environment: Laravel 5.1 Stripe-laravel v3.0.2 Service Providers is set up properly. Added in config/app.php

$providers =[
     ...
     'Cartalyst\Stripe\Laravel\StripeServiceProvider' 
];

...

$aliases = [
     ...
     'Stripe' => 'Cartalyst\Stripe\Laravel\Facades\Stripe',
];

Added keys in config/services.php

return [
    ....
    'stripe' => [
         'model'  => App\User::class,
         'key'    => '<LIVE_PK_KEY_HERE>',
         'secret' => '<LIVE_SECRET_KEY_HERE>',
    ]
    ...

Steps made:

1. php artisan tinker
2. use Stripe
3. Stripe::customers()->all()

Returns below: Cartalyst\Stripe\Exception\UnauthorizedException with message 'Stripe no longer supports API requests made with TLS 1.0. Please initiate HTTPS connections with TLS 1.2 or later. You can learn more about this at https://stripe.com/blog/upgrading-tls.'

OR

1. php artisan tinker
2. Cartalyst\Stripe\Laravel\Facades\Stripe::make('<LIVE_SECRET_KEY_HERE>')
3. Cartalyst\Stripe\Laravel\Facades\Stripe::customers()->all(),

Returns same error above.

I can conclude that this package is at fault and that my TLS is updated and is working with the code snippet below and its result:

<?php
// Include stripe-php as you usually do, either with composer as shown,
// or with a direct require, as commented out.
require_once("vendor/autoload.php");
// require_once("/path/to/stripe-php/init.php");

\Stripe\Stripe::setApiKey("<LIVE_SECRET_KEY_HERE>");
\Stripe\Stripe::$apiBase = "https://api-tls12.stripe.com";
try {
  \Stripe\Charge::all();
  echo "TLS 1.2 supported, no action required.";
} catch (\Stripe\Error\ApiConnection $e) {
  echo "TLS 1.2 is not supported. You will need to upgrade your integration.";
}
?>

OUTPUTS: TLS 1.2 supported, no action required.

[brunogaspar]

Can't reproduce any issues.

[brunogaspar]

As i mentioned on my previous reply, locally works as expected and no errors are thrown.

As i mentioned on my previous reply, i can't reproduce any issues.

I tested locally and on two different DigitalOcean droplets, one is running Ubuntu 16.04 x64 and the other CentOS 7.11 x64. All environments has the same PHP version, 7.0.8 are for the most part updated to latest versions.

I've also tested hitting https://api.stripe.com or https://api-tls12.stripe.com and it worked fine.

So it seems that something on your server is not setup correctly and my guess os that you might need to upgrade your OpenSSL.

[webriq]

Thanks for the quick response. Perhaps there's something wrong in my environment. CentOS release 6.6 (Final) with OpenSSL 1.0.1e-fips 11 Feb 2013 with PHP 5.6.

[brunogaspar]

No problem.

I would try to update OpenSSL and see if it solves the problem otherwise we need to figure out why it doesn't work on your environment.

[webriq]

That's the latest version I had there. It seems odd. I tried, changing endpoints and used https://api-tls12.stripe.com and I got a different error by now related with Guzzle GuzzleHttp\Exception\ConnectException with message 'cURL error 35: SSL connect error'.

[brunogaspar]

I'm not the best to tell, as i'm no server expert, but it's related to SSL and probably the certificate you have and if Guzzle can't connect to the server there's an issue there and is unrelated to our library.

But what is the built on date of your OpenSSL install? Run openssl version -a and it will return that.

[webriq]

# openssl version -a
OpenSSL 1.0.1e-fips 11 Feb 2013
built on: Mon May  9 07:30:30 CDT 2016
platform: linux-x86_64
options:  bn(64,64) md2(int) rc4(16x,int) des(idx,cisc,16,int) idea(int) blowfish(idx)
compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT -m64 -DL_ENDIAN -DTERMIO -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wa,--noexecstack -DPURIFY -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
OPENSSLDIR: "/etc/pki/tls"
engines:  rdrand dynamic

[brunogaspar]

It looks correct and i don't know what might be the issue but i believe the reason it worked with the other Stripe library is because they use their own certificate that's bundled with the library. We don't do that, nor we will so Guzzle is using your own certificate and is having a hard time it seems.

Probably i'm wrong, but the issue relies on your environment or on Guzzle itself and since i don't have a way to reproduce this i can't provide you with a fix for this issue :(

[webriq]

Does an SSL certificate might have something to do with this? I do have another Laravel app on the same server. Configuration as below, I highly doubt this.

server {
    listen 80;
    server_name example.com www.example.com;
    return  301 https://www.example.com$request_uri;
}

server {
    listen 443;
    server_name www.example.com;

    # SSL
    ssl on;
    ssl_certificate /etc/ssl/certs/afs.crt;
    ssl_certificate_key /etc/ssl/certs/services.afs.key;

    #access_log /var/log/afs/services.access.log;
    error_log /var/log/afs/services.error.log warn;

    root /srv/www/example/public;
    index index.php;
...

[webriq]

I am using Guzzle 5.3 on my package, btw as per this required a lower version of that on 6.

[brunogaspar]

Does an SSL certificate might have something to do with this? I do have another Laravel app on the same server. Configuration as below, I highly doubt this.

As i said i'm no server expert so i can't give you a proper answer and since i can't reproduce i have no way to try to find a fix.

I would try to ask on Guzzle and see if someone else had the same issue and probably provide a fix for it.

[webriq]

Thanks for your help @brunogaspar. Appreciate it a lot.