Verified
Status Update
No update yet.
Comments
pa...@google.com
It appears that 1.2 is in fact working in dev for python, according to this issue [1]. Could you show the error you receive when attempting to connect?
[1]https://code.google.com/p/googleappengine/issues/detail?id=10591
[1]
pa...@google.com
Additionally, could you show the code you use to connect?
ro...@royleban.com
Here is the information we have.
1) Stripe sent us this email:
In 2017, we'll be deprecating some of the older security protocols (TLS 1.0,
TLS 1.1, and SHA-1) used to make connections with Stripe's APIs. I'm reaching
out to give you an early heads up because your Stripe integration might be
impacted.
Here are some of the key upcoming dates:
* On January 1, 2017, we'll drop support for TLS 1.0 connections and SHA-1
certificates.
* On May 1, 2017, we'll drop support for TLS 1.1 connections.
We've noticed that your Stripe integration appears to be using TLS 1.0, so
you'll want to follow the steps in this upgrade guide [1] to ensure that your
Stripe integration isn't interrupted in the next year.
To be clear, upgrading to TLS 1.2 will generally not involve any changes to
your code, but may require that you update your operating systems, system
packages, or language runtime libraries. (The exact methodology depends on your
technology stack.)
While you'll be required to make these changes to ensure that your Stripe
integration isn't interrupted, I'd like to stress that TLS 1.0, TLS 1.1, and
SHA-1 are widely considered to be dangerously weak and upgrading as early as
possible is an important part of keeping your business secure. If you'd like
more information about the topic, we've written up a blog post [2].
If you have any questions about this change, or need help in upgrading your
systems, please don't hesitate to ask—you can just reply to this email!
Thanks,
[1]https://support.stripe.com/questions/how-do-i-upgrade-my-stripe-integration-from-tls-1-0-to-tls-1-2
[2]https://stripe.com/blog/upgrading-tls
____________________________
2) Their instructions say to run a test. Here's the test:
import stripe
def test_stripe(request):
stripe.api_key = "sk_test_BQokikJOvBiI2HlWgH4olfQ2"
stripe.api_base = "https://api-tls12.stripe.com "
if stripe.VERSION in ("1.13.0", "1.14.0", "1.14.1", "1.15.1", "1.16.0", "1.17.0", "1.18.0", "1.19.0"):
return "Bindings update required."
try:
stripe.Charge.all()
return "TLS 1.2 supported, no action required."
except stripe.error.APIConnectionError:
return "TLS 1.2 is not supported. You will need to upgrade your integration."
When this test is run on the live server, including those underappspot.com , we get the first message, "TLS 1.2 supported, no action required."
When this test is run on a dev server, we get the second message, "TLS 1.2 is not supported. You will need to upgrade your integration." Note that we run our dev servers on MacOS, if that matters.
____________________________
3) Stripe tells us that calls made from the test environment are incorrect:
We've monitored all the accounts for TLS < 1.2 usage over the past few months to ensure that we caught anyone that could potentially be impacted. The reason is that some users have multiple integrations for one Stripe account and some of those are used less often but still need an upgrade.
I just looked into your Stripe account requests on our end to better understand what's causing this and I can confirm what you found. The issue seems to only happen in Test mode where your requests are made over TLS 1.0 instead of TLS 1.2. On the other end, all the requests made in production in Live mode have used TLS 1.2 for the past 30 days.
On our end, we have to deprecate those protocols as it's a requirement for PCI compliance. If we were to only enable this in Test it would be even worse as everything would seem to work fine and then fail once you go to production if you use the wrong protocol.
What I'd recommend here is to reach out to the AppEngine team so that they upgrade their installation to properly use TLS 1.2 in the Test environment too. The deprecation won't happen until January 2017 so I'm fairly confident this is something that will be fixed by then.
I hope this clarifies the situation but please do not hesitate to get back to me if you need more details.
____________________________
4) This is all the information we have. It's not our code, we're just one of tens of thousands of Stripe customers, and we have no special insight, nor any ability to change anything. We told Stripe that they should work with you directly, but they requested that we contact you, so we have. They said:
There are unfortunately thousands of host providers and we can't reach out to every single one especially as we're not their users and most will just ignore what we ask them to do.
I'd really recommend that you do contact them first as I'm sure they are aware of the upgrade requirements but I'll make a note to our engineering team to see if we could reach out to Google on our end.
The people who have communicated with us are:
Brandur Leach <brandur.leach@stripe.com>
Some guy named Thomas at integration@stripe.com
So ... it's up to you guys, not us. We just have to hope that you and Stripe get together and figure out what's going on.
Thanks
1) Stripe sent us this email:
In 2017, we'll be deprecating some of the older security protocols (TLS 1.0,
TLS 1.1, and SHA-1) used to make connections with Stripe's APIs. I'm reaching
out to give you an early heads up because your Stripe integration might be
impacted.
Here are some of the key upcoming dates:
* On January 1, 2017, we'll drop support for TLS 1.0 connections and SHA-1
certificates.
* On May 1, 2017, we'll drop support for TLS 1.1 connections.
We've noticed that your Stripe integration appears to be using TLS 1.0, so
you'll want to follow the steps in this upgrade guide [1] to ensure that your
Stripe integration isn't interrupted in the next year.
To be clear, upgrading to TLS 1.2 will generally not involve any changes to
your code, but may require that you update your operating systems, system
packages, or language runtime libraries. (The exact methodology depends on your
technology stack.)
While you'll be required to make these changes to ensure that your Stripe
integration isn't interrupted, I'd like to stress that TLS 1.0, TLS 1.1, and
SHA-1 are widely considered to be dangerously weak and upgrading as early as
possible is an important part of keeping your business secure. If you'd like
more information about the topic, we've written up a blog post [2].
If you have any questions about this change, or need help in upgrading your
systems, please don't hesitate to ask—you can just reply to this email!
Thanks,
[1]
[2]
____________________________
2) Their instructions say to run a test. Here's the test:
import stripe
def test_stripe(request):
stripe.api_key = "sk_test_BQokikJOvBiI2HlWgH4olfQ2"
stripe.api_base = "
if stripe.VERSION in ("1.13.0", "1.14.0", "1.14.1", "1.15.1", "1.16.0", "1.17.0", "1.18.0", "1.19.0"):
return "Bindings update required."
try:
stripe.Charge.all()
return "TLS 1.2 supported, no action required."
except stripe.error.APIConnectionError:
return "TLS 1.2 is not supported. You will need to upgrade your integration."
When this test is run on the live server, including those under
When this test is run on a dev server, we get the second message, "TLS 1.2 is not supported. You will need to upgrade your integration." Note that we run our dev servers on MacOS, if that matters.
____________________________
3) Stripe tells us that calls made from the test environment are incorrect:
We've monitored all the accounts for TLS < 1.2 usage over the past few months to ensure that we caught anyone that could potentially be impacted. The reason is that some users have multiple integrations for one Stripe account and some of those are used less often but still need an upgrade.
I just looked into your Stripe account requests on our end to better understand what's causing this and I can confirm what you found. The issue seems to only happen in Test mode where your requests are made over TLS 1.0 instead of TLS 1.2. On the other end, all the requests made in production in Live mode have used TLS 1.2 for the past 30 days.
On our end, we have to deprecate those protocols as it's a requirement for PCI compliance. If we were to only enable this in Test it would be even worse as everything would seem to work fine and then fail once you go to production if you use the wrong protocol.
What I'd recommend here is to reach out to the AppEngine team so that they upgrade their installation to properly use TLS 1.2 in the Test environment too. The deprecation won't happen until January 2017 so I'm fairly confident this is something that will be fixed by then.
I hope this clarifies the situation but please do not hesitate to get back to me if you need more details.
____________________________
4) This is all the information we have. It's not our code, we're just one of tens of thousands of Stripe customers, and we have no special insight, nor any ability to change anything. We told Stripe that they should work with you directly, but they requested that we contact you, so we have. They said:
There are unfortunately thousands of host providers and we can't reach out to every single one especially as we're not their users and most will just ignore what we ask them to do.
I'd really recommend that you do contact them first as I'm sure they are aware of the upgrade requirements but I'll make a note to our engineering team to see if we could reach out to Google on our end.
The people who have communicated with us are:
Brandur Leach <brandur.leach@stripe.com>
Some guy named Thomas at integration@stripe.com
So ... it's up to you guys, not us. We just have to hope that you and Stripe get together and figure out what's going on.
Thanks
pa...@google.com
Thanks for the detailed reply. I'll try to get as much information about your situation as I can to determine next steps, but I'll need some help from your end in checking some things on your system:
1 .Could you check the version of tls used by your dev system by sending a urlfetch request tohttps://howsmyssl.com ?
The response is a web page (html), so you'll want to echo that to the browser to view the results. This will tell you which version of tls you're using.
2. In the same code, could you attempt to run the following?
import google.appengine.api.urlfetch as urlfetch
import ssl
print urlfetch.__file__
print ssl.__file__
print ssl.OPENSSL_VERSION
This will show where on your system the urlfetch and ssl modules are being sourced from, and the openssl version.
3. Next, can you also run the following commands?
which dev_appserver.py
^^^ this will give you the location of your devserver process
4. Finally, if the dev_appserver.py script is in the google-cloud-sdk folder (gcloud), could you report the output of "gcloud info"? Otherwise, could you check what version of the App Engine SDK the script is residing in, and find the VERSION file in there, reporting its contents?
1 .Could you check the version of tls used by your dev system by sending a urlfetch request to
The response is a web page (html), so you'll want to echo that to the browser to view the results. This will tell you which version of tls you're using.
2. In the same code, could you attempt to run the following?
import google.appengine.api.urlfetch as urlfetch
import ssl
print urlfetch.__file__
print ssl.__file__
print ssl.OPENSSL_VERSION
This will show where on your system the urlfetch and ssl modules are being sourced from, and the openssl version.
3. Next, can you also run the following commands?
which dev_appserver.py
^^^ this will give you the location of your devserver process
4. Finally, if the dev_appserver.py script is in the google-cloud-sdk folder (gcloud), could you report the output of "gcloud info"? Otherwise, could you check what version of the App Engine SDK the script is residing in, and find the VERSION file in there, reporting its contents?
ro...@royleban.com
This isn't my problem or my company's problem. It's between you and Stripe. You want me to work on it. Stripe wants me to work on it. Why should I waste my time working on a problem that I have nothing to do with? Can't you people get together and work on it together?
Here's everything I have time for. Please direct future questions to the folks at Stripe.
I'm running El Capitan on MacOS. Another developer who tried it is also on El Capitan.
Just for grins, here's the answer to #1 in Chrome (which, of course, isn't being used when the problem occurs!) and in Safari (which, of course, also isn't being used when the problem occurs!). I have no idea what this stuff means and, frankly, I don't care.
The results of gcloud info are at the bottom. There's a warning in there. If it's an issue, then your installer has a bug because I have only installed (and updated) GAE with your installer and I do not have any other Google Cloud products installed. Here's my PATH:
/Users/REDACTED/google-cloud-sdk/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/Frameworks/Mono.framework/Versions/Current/Commands:/misc/android-sdk-mac/tools
______
CHROME:
How's My SSL?
Home
About
API
Your SSL client is Probably Okay.
Check out the sections below for information about the SSL/TLS client you used to render this page.
Yeah, we really mean "TLS", not "SSL".
Version
Good Your client is using TLS 1.2, the most modern version of the encryption protocol. It gives you access to the fastest, most secure encryption possible on the web.
Learn More
Ephemeral Key Support
Good Ephemeral keys are used in some of the cipher suites your client supports. This means your client may be used to provide forward secrecy if the server supports it. This greatly increases your protection against snoopers, including global passive adversaries who scoop up large amounts of encrypted traffic and store them until their attacks (or their computers) improve.
Learn More
Session Ticket Support
Good Session tickets are supported in your client. Services you use will be able to scale out their TLS connections more easily with this feature.
Learn More
TLS Compression
Good Your TLS client does not attempt to compress the settings that encrypt your connection, avoiding information leaks from the CRIME attack.
Learn More
BEAST Vulnerability
Good Your client is not vulnerable to the BEAST attack because it's using a TLS protocol newer than TLS 1.0. The BEAST attack is only possible against clients using TLS 1.0 or earlier using Cipher-Block Chaining cipher suites that do not implement the 1/n-1 record splitting mitigation.
Learn More
Insecure Cipher Suites
Good Your client doesn't use any cipher suites that are known to be insecure.
Learn More
Given Cipher Suites
The cipher suites your client said it supports, in the order it sent them, are:
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
Learn More
_______
SAFARI:
How's My SSL?
Home
About
API
Your SSL client is Improvable.
Check out the sections below for information about the SSL/TLS client you used to render this page.
Yeah, we really mean "TLS", not "SSL".
Version
Good Your client is using TLS 1.2, the most modern version of the encryption protocol. It gives you access to the fastest, most secure encryption possible on the web.
Learn More
Ephemeral Key Support
Good Ephemeral keys are used in some of the cipher suites your client supports. This means your client may be used to provide forward secrecy if the server supports it. This greatly increases your protection against snoopers, including global passive adversaries who scoop up large amounts of encrypted traffic and store them until their attacks (or their computers) improve.
Learn More
Session Ticket Support
Improvable Session tickets are not supported in your client. Without them, services will have a harder time making your client's connections fast. Generally, clients with ephemeral key support get this for free.
Learn More
TLS Compression
Good Your TLS client does not attempt to compress the settings that encrypt your connection, avoiding information leaks from the CRIME attack.
Learn More
BEAST Vulnerability
Good Your client is not vulnerable to the BEAST attack because it's using a TLS protocol newer than TLS 1.0. The BEAST attack is only possible against clients using TLS 1.0 or earlier using Cipher-Block Chaining cipher suites that do not implement the 1/n-1 record splitting mitigation.
Learn More
Insecure Cipher Suites
Good Your client doesn't use any cipher suites that are known to be insecure.
Learn More
Given Cipher Suites
The cipher suites your client said it supports, in the order it sent them, are:
TLS_EMPTY_RENEGOTIATION_INFO_SCSV
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
Learn More
_____
gcloud info
Google Cloud SDK [0.9.89]
Platform: [Mac OS X, x86_64]
Python Version: [2.7.10 (default, Oct 23 2015, 19:19:21) [GCC 4.2.1 Compatible Apple LLVM 7.0.0 (clang-700.0.59.5)]]
Python Location: [/usr/bin/python]
Site Packages: [Disabled]
Installation Root: [/Users/REDACTED/google-cloud-sdk]
Installed Components:
core: [2015.11.30]
core-nix: [2015.11.24]
gcloud: []
gsutil-nix: [4.15]
gsutil: [4.16]
bq: [2.0.18]
bq-nix: [2.0.18]
System PATH: [/Users/REDACTED/google-cloud-sdk/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/Frameworks/Mono.framework/Versions/Current/Commands:/misc/android-sdk-mac/tools:/Users/REDACTED/workspace/puzzazz/websetup]
Cloud SDK on PATH: [True]
WARNING: There are old versions of the Google Cloud Platform tools on your system PATH.
/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/dev_appserver.py
Installation Properties: [/Users/REDACTED/google-cloud-sdk/properties]
User Config Directory: [/Users/REDACTED/.config/gcloud]
User Properties: [/Users/REDACTED/.config/gcloud/properties]
Current Workspace: [None]
Workspace Config Directory: [None]
Workspace Properties: [None]
Account: [REDACTED]
Project: [None]
Current Properties:
[core]
account: [REDACTED]
disable_usage_reporting: [False]
Logs Directory: [/Users/REDACTED/.config/gcloud/logs]
Last Log File: [/Users/REDACTED/.config/gcloud/logs/2016.08.18/14.18.17.249691.log]
Here's everything I have time for. Please direct future questions to the folks at Stripe.
I'm running El Capitan on MacOS. Another developer who tried it is also on El Capitan.
Just for grins, here's the answer to #1 in Chrome (which, of course, isn't being used when the problem occurs!) and in Safari (which, of course, also isn't being used when the problem occurs!). I have no idea what this stuff means and, frankly, I don't care.
The results of gcloud info are at the bottom. There's a warning in there. If it's an issue, then your installer has a bug because I have only installed (and updated) GAE with your installer and I do not have any other Google Cloud products installed. Here's my PATH:
/Users/REDACTED/google-cloud-sdk/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/Frameworks/Mono.framework/Versions/Current/Commands:/misc/android-sdk-mac/tools
______
CHROME:
How's My SSL?
Home
About
API
Your SSL client is Probably Okay.
Check out the sections below for information about the SSL/TLS client you used to render this page.
Yeah, we really mean "TLS", not "SSL".
Version
Good Your client is using TLS 1.2, the most modern version of the encryption protocol. It gives you access to the fastest, most secure encryption possible on the web.
Learn More
Ephemeral Key Support
Good Ephemeral keys are used in some of the cipher suites your client supports. This means your client may be used to provide forward secrecy if the server supports it. This greatly increases your protection against snoopers, including global passive adversaries who scoop up large amounts of encrypted traffic and store them until their attacks (or their computers) improve.
Learn More
Session Ticket Support
Good Session tickets are supported in your client. Services you use will be able to scale out their TLS connections more easily with this feature.
Learn More
TLS Compression
Good Your TLS client does not attempt to compress the settings that encrypt your connection, avoiding information leaks from the CRIME attack.
Learn More
BEAST Vulnerability
Good Your client is not vulnerable to the BEAST attack because it's using a TLS protocol newer than TLS 1.0. The BEAST attack is only possible against clients using TLS 1.0 or earlier using Cipher-Block Chaining cipher suites that do not implement the 1/n-1 record splitting mitigation.
Learn More
Insecure Cipher Suites
Good Your client doesn't use any cipher suites that are known to be insecure.
Learn More
Given Cipher Suites
The cipher suites your client said it supports, in the order it sent them, are:
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
Learn More
_______
SAFARI:
How's My SSL?
Home
About
API
Your SSL client is Improvable.
Check out the sections below for information about the SSL/TLS client you used to render this page.
Yeah, we really mean "TLS", not "SSL".
Version
Good Your client is using TLS 1.2, the most modern version of the encryption protocol. It gives you access to the fastest, most secure encryption possible on the web.
Learn More
Ephemeral Key Support
Good Ephemeral keys are used in some of the cipher suites your client supports. This means your client may be used to provide forward secrecy if the server supports it. This greatly increases your protection against snoopers, including global passive adversaries who scoop up large amounts of encrypted traffic and store them until their attacks (or their computers) improve.
Learn More
Session Ticket Support
Improvable Session tickets are not supported in your client. Without them, services will have a harder time making your client's connections fast. Generally, clients with ephemeral key support get this for free.
Learn More
TLS Compression
Good Your TLS client does not attempt to compress the settings that encrypt your connection, avoiding information leaks from the CRIME attack.
Learn More
BEAST Vulnerability
Good Your client is not vulnerable to the BEAST attack because it's using a TLS protocol newer than TLS 1.0. The BEAST attack is only possible against clients using TLS 1.0 or earlier using Cipher-Block Chaining cipher suites that do not implement the 1/n-1 record splitting mitigation.
Learn More
Insecure Cipher Suites
Good Your client doesn't use any cipher suites that are known to be insecure.
Learn More
Given Cipher Suites
The cipher suites your client said it supports, in the order it sent them, are:
TLS_EMPTY_RENEGOTIATION_INFO_SCSV
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
Learn More
_____
gcloud info
Google Cloud SDK [0.9.89]
Platform: [Mac OS X, x86_64]
Python Version: [2.7.10 (default, Oct 23 2015, 19:19:21) [GCC 4.2.1 Compatible Apple LLVM 7.0.0 (clang-700.0.59.5)]]
Python Location: [/usr/bin/python]
Site Packages: [Disabled]
Installation Root: [/Users/REDACTED/google-cloud-sdk]
Installed Components:
core: [2015.11.30]
core-nix: [2015.11.24]
gcloud: []
gsutil-nix: [4.15]
gsutil: [4.16]
bq: [2.0.18]
bq-nix: [2.0.18]
System PATH: [/Users/REDACTED/google-cloud-sdk/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/Frameworks/Mono.framework/Versions/Current/Commands:/misc/android-sdk-mac/tools:/Users/REDACTED/workspace/puzzazz/websetup]
Cloud SDK on PATH: [True]
WARNING: There are old versions of the Google Cloud Platform tools on your system PATH.
/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/dev_appserver.py
Installation Properties: [/Users/REDACTED/google-cloud-sdk/properties]
User Config Directory: [/Users/REDACTED/.config/gcloud]
User Properties: [/Users/REDACTED/.config/gcloud/properties]
Current Workspace: [None]
Workspace Config Directory: [None]
Workspace Properties: [None]
Account: [REDACTED]
Project: [None]
Current Properties:
[core]
account: [REDACTED]
disable_usage_reporting: [False]
Logs Directory: [/Users/REDACTED/.config/gcloud/logs]
Last Log File: [/Users/REDACTED/.config/gcloud/logs/2016.08.18/14.18.17.249691.log]
pa...@google.com
Thank you for your patience.
In order to help you determine what's going on in your system, it would be necessary to work with you to gather information. I had requested that you use urlfetch in the devserver to hithttps://howsmyssl.com/ so that we could determine whether your devserver is using TLS 1.0 or 1.2. In an up-to-date SDK and system, 1.2 should be default, as I confirmed on my end, so it appears there's something going on in your system which won't be fixed by any change we make, even to the SDK, if you weren't to download a new one or take any further action. This would result in your inability to make calls in development to the Stripe API after they deprecate TLS 1.0 connections.
The other questions I asked about your system, about the python modules you have, were also directed towards determining where exactly the problem lies on your system. If you'd like to continue working on this issue, feel free to let me know, I'll be happy to assist.
In order to help you determine what's going on in your system, it would be necessary to work with you to gather information. I had requested that you use urlfetch in the devserver to hit
The other questions I asked about your system, about the python modules you have, were also directed towards determining where exactly the problem lies on your system. If you'd like to continue working on this issue, feel free to let me know, I'll be happy to assist.
pa...@google.com
Just to cut down some of the detail and make that more clear:
TLS 1.2 should be the default in an up-to-date system. The problem appears to exist on your installation, not with anything Google can change from our end, or which Stripe could influence from their end. I'm here and happy to help you ensure that you can get TLS 1.2 up and running. Feel free to ask any questions you may have, and if possible, run some of the diagnostics recommended in my prior comments.
TLS 1.2 should be the default in an up-to-date system. The problem appears to exist on your installation, not with anything Google can change from our end, or which Stripe could influence from their end. I'm here and happy to help you ensure that you can get TLS 1.2 up and running. Feel free to ask any questions you may have, and if possible, run some of the diagnostics recommended in my prior comments.
ro...@royleban.com
This is very frustrating. I understand that there may be a problem in my configuration, but I don't see any way this could be something that we've done wrong. We've tested on multiple machines and they all exhibit the same problem. We have the current GAE SDK. We always update using the official installer. We are running El Capitan with nothing weird installed. I go out of my way to not install anything weird. Our app uses Python 2.7. The local version of Python is 2.7.10. The only thing that I can think of that might be unusual about our systems is that we have had GAE installed for a very long time, since 2010 and have continuously upgraded since then. Perhaps your installers have a problem in cases like this.
There's a limit to what I have time to deal with for a bug I haven't caused (we have plenty of our own things to deal with!) but I have done the four things you requested (see below). If you look at #3, you'll see that the import ssl fails because it can't import _ssl. Googling this finds we're not the only ones with this problem (no surprise there!). See:
*http://stackoverflow.com/questions/5128845/importerror-no-module-named-ssl
*http://stackoverflow.com/questions/16192916/importerror-no-module-named-ssl-with-dev-appserver-py-from-google-app-engine
*https://bugs.python.org/issue25526
Potential workarounds include building Python from source code (no, we won't be doing that, see above that I don't do anything weird)
There's also the suggestion of adding the following to app.yaml:
libraries:
- name: ssl
version: latest
Yeah, pretty weird that, supposedly, we wouldn't get the latest SSL unless we explicitly ask for it, and no, it doesn't make a difference.
Hopefully, this is enough information that you can fix whatever the problem is in the next installer. This isn't urgent, but the sooner you fix it, the more likely it will be that GAE users will have the fix when Stripe turns off TLS 1.0.
____________
1. urlfetchhttps://howsmyssl.com/
How's My SSL?
Home
About
API
Your SSL client is Bad.
Check out the sections below for information about the SSL/TLS client you used to render this page.
Yeah, we really mean "TLS", not "SSL".
Version
Bad Your client is using TLS 1.0, which is very old, possibly susceptible to the BEAST attack, and doesn't have the best cipher suites available on it. Additions like AES-GCM, and SHA256 to replace MD5-SHA-1 are unavailable to a TLS 1.0 client as well as many more modern cipher suites.
Learn More
Ephemeral Key Support
Good Ephemeral keys are used in some of the cipher suites your client supports. This means your client may be used to provide forward secrecy if the server supports it. This greatly increases your protection against snoopers, including global passive adversaries who scoop up large amounts of encrypted traffic and store them until their attacks (or their computers) improve.
Learn More
Session Ticket Support
Good Session tickets are supported in your client. Services you use will be able to scale out their TLS connections more easily with this feature.
Learn More
TLS Compression
Good Your TLS client does not attempt to compress the settings that encrypt your connection, avoiding information leaks from the CRIME attack.
Learn More
BEAST Vulnerability
Good Your client is not vulnerable to the BEAST attack. While it's using TLS 1.0 in conjunction with Cipher-Block Chaining cipher suites, it has implemented the 1/n-1 record splitting mitigation.
Learn More
Insecure Cipher Suites
Good Your client doesn't use any cipher suites that are known to be insecure.
Learn More
Given Cipher Suites
The cipher suites your client said it supports, in the order it sent them, are:
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_EMPTY_RENEGOTIATION_INFO_SCSV
Learn More
____________
2. Importing SSL gets the following error shown in the console:
File "/Users/REDACTED/admin.py", line 2104, in test_tls
import ssl
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ssl.py", line 97, in <module>
import _ssl # if we can't import it, let the error propagate
File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/devappserver2/python/sandbox.py", line 963, in load_module
raise ImportError('No module named %s' % fullname)
____________
3. which dev_appserver.py gets:
/Users/REDACTED/google-cloud-sdk/bin/dev_appserver.py
There are no other copies of dev_appserver.py on my hard disk.
____________
4. gcloud info, same as reported earlier:
Google Cloud SDK [0.9.89]
Platform: [Mac OS X, x86_64]
Python Version: [2.7.10 (default, Oct 23 2015, 19:19:21) [GCC 4.2.1 Compatible Apple LLVM 7.0.0 (clang-700.0.59.5)]]
Python Location: [/usr/bin/python]
Site Packages: [Disabled]
Installation Root: [/Users/REDACTED/google-cloud-sdk]
Installed Components:
core: [2015.11.30]
core-nix: [2015.11.24]
gcloud: []
gsutil-nix: [4.15]
gsutil: [4.16]
bq: [2.0.18]
bq-nix: [2.0.18]
System PATH: [/Users/REDACTED/google-cloud-sdk/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/Frameworks/Mono.framework/Versions/Current/Commands:/misc/android-sdk-mac/tools:/Users/REDACTED/workspace/puzzazz/websetup]
Cloud SDK on PATH: [True]
WARNING: There are old versions of the Google Cloud Platform tools on your system PATH.
/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/dev_appserver.py
Installation Properties: [/Users/REDACTED/google-cloud-sdk/properties]
User Config Directory: [/Users/REDACTED/.config/gcloud]
User Properties: [/Users/REDACTED/.config/gcloud/properties]
Current Workspace: [None]
Workspace Config Directory: [None]
Workspace Properties: [None]
Account: [REDACTED]
Project: [None]
Current Properties:
[core]
account: [REDACTED]
disable_usage_reporting: [False]
Logs Directory: [/Users/REDACTED/.config/gcloud/logs]
Last Log File: [/Users/REDACTED/.config/gcloud/logs/2016.08.18/14.18.17.249691.log]
There's a limit to what I have time to deal with for a bug I haven't caused (we have plenty of our own things to deal with!) but I have done the four things you requested (see below). If you look at #3, you'll see that the import ssl fails because it can't import _ssl. Googling this finds we're not the only ones with this problem (no surprise there!). See:
*
*
*
Potential workarounds include building Python from source code (no, we won't be doing that, see above that I don't do anything weird)
There's also the suggestion of adding the following to app.yaml:
libraries:
- name: ssl
version: latest
Yeah, pretty weird that, supposedly, we wouldn't get the latest SSL unless we explicitly ask for it, and no, it doesn't make a difference.
Hopefully, this is enough information that you can fix whatever the problem is in the next installer. This isn't urgent, but the sooner you fix it, the more likely it will be that GAE users will have the fix when Stripe turns off TLS 1.0.
____________
1. urlfetch
How's My SSL?
Home
About
API
Your SSL client is Bad.
Check out the sections below for information about the SSL/TLS client you used to render this page.
Yeah, we really mean "TLS", not "SSL".
Version
Bad Your client is using TLS 1.0, which is very old, possibly susceptible to the BEAST attack, and doesn't have the best cipher suites available on it. Additions like AES-GCM, and SHA256 to replace MD5-SHA-1 are unavailable to a TLS 1.0 client as well as many more modern cipher suites.
Learn More
Ephemeral Key Support
Good Ephemeral keys are used in some of the cipher suites your client supports. This means your client may be used to provide forward secrecy if the server supports it. This greatly increases your protection against snoopers, including global passive adversaries who scoop up large amounts of encrypted traffic and store them until their attacks (or their computers) improve.
Learn More
Session Ticket Support
Good Session tickets are supported in your client. Services you use will be able to scale out their TLS connections more easily with this feature.
Learn More
TLS Compression
Good Your TLS client does not attempt to compress the settings that encrypt your connection, avoiding information leaks from the CRIME attack.
Learn More
BEAST Vulnerability
Good Your client is not vulnerable to the BEAST attack. While it's using TLS 1.0 in conjunction with Cipher-Block Chaining cipher suites, it has implemented the 1/n-1 record splitting mitigation.
Learn More
Insecure Cipher Suites
Good Your client doesn't use any cipher suites that are known to be insecure.
Learn More
Given Cipher Suites
The cipher suites your client said it supports, in the order it sent them, are:
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_EMPTY_RENEGOTIATION_INFO_SCSV
Learn More
____________
2. Importing SSL gets the following error shown in the console:
File "/Users/REDACTED/admin.py", line 2104, in test_tls
import ssl
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ssl.py", line 97, in <module>
import _ssl # if we can't import it, let the error propagate
File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/devappserver2/python/sandbox.py", line 963, in load_module
raise ImportError('No module named %s' % fullname)
____________
3. which dev_appserver.py gets:
/Users/REDACTED/google-cloud-sdk/bin/dev_appserver.py
There are no other copies of dev_appserver.py on my hard disk.
____________
4. gcloud info, same as reported earlier:
Google Cloud SDK [0.9.89]
Platform: [Mac OS X, x86_64]
Python Version: [2.7.10 (default, Oct 23 2015, 19:19:21) [GCC 4.2.1 Compatible Apple LLVM 7.0.0 (clang-700.0.59.5)]]
Python Location: [/usr/bin/python]
Site Packages: [Disabled]
Installation Root: [/Users/REDACTED/google-cloud-sdk]
Installed Components:
core: [2015.11.30]
core-nix: [2015.11.24]
gcloud: []
gsutil-nix: [4.15]
gsutil: [4.16]
bq: [2.0.18]
bq-nix: [2.0.18]
System PATH: [/Users/REDACTED/google-cloud-sdk/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/Frameworks/Mono.framework/Versions/Current/Commands:/misc/android-sdk-mac/tools:/Users/REDACTED/workspace/puzzazz/websetup]
Cloud SDK on PATH: [True]
WARNING: There are old versions of the Google Cloud Platform tools on your system PATH.
/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/dev_appserver.py
Installation Properties: [/Users/REDACTED/google-cloud-sdk/properties]
User Config Directory: [/Users/REDACTED/.config/gcloud]
User Properties: [/Users/REDACTED/.config/gcloud/properties]
Current Workspace: [None]
Workspace Config Directory: [None]
Workspace Properties: [None]
Account: [REDACTED]
Project: [None]
Current Properties:
[core]
account: [REDACTED]
disable_usage_reporting: [False]
Logs Directory: [/Users/REDACTED/.config/gcloud/logs]
Last Log File: [/Users/REDACTED/.config/gcloud/logs/2016.08.18/14.18.17.249691.log]
ar...@google.com
I apologize for the frustration. The TLS v1.2 support was indeed fixed for the Python development server as of Jan 29, 2016. However the URL Fetch implementation on the development server depends directly on the local machine's installation of OpenSSL, which is most likely the reason you're only seeing TLS v1.0.
Even on El Capitan, it's a known issue that the default OpenSSL included is out of date, circa v0.9.8. You can check your OpenSSL version from the command line using 'openssl version'. The best way to update OpenSSL on Mac is to use Homebrew, and instructions for doing so are given on the Stripe support site:
How do I upgrade my OpenSSL to support TLS 1.2?
https://support.stripe.com/questions/how-do-i-upgrade-my-openssl-to-support-tls-1-2
To show that I've tested this, below is the code I'm using on the development server, with the output fromhttps://howsmyssl.com (note the 'libraries' directive in app.yaml isn't needed unless you 'import ssl' directly). If you still have problems, you may want to test on a clean system using the latest SDK version (1.9.42) from the ZIP installer, which is now the same SDK used on Windows, Mac and Linux:
----- app.yaml:
application: <redacted>
version: <redacted>
runtime: python27
api_version: 1
threadsafe: true
handlers:
- url: /.*
script:main.app
----- main.py:
import webapp2
from google.appengine.api import urlfetch
class MainPage(webapp2.RequestHandler):
def get(self):
from google.appengine.api import urlfetch
url = 'https://howsmyssl.com '
fetched = urlfetch.fetch(url, validate_certificate=False)
self.response.write(fetched.content)
app = webapp2.WSGIApplication([('/', MainPage)], debug=True)
---- application output:
Your SSL client is Probably Okay.
Check out the sections below for information about the SSL/TLS client you used to render this page.
Yeah, we really mean "TLS", not "SSL".
Version
Good Your client is using TLS 1.2, the most modern version of the encryption protocol. It gives you access to the fastest, most secure encryption possible on the web.
Ephemeral Key Support
Good Ephemeral keys are used in some of the cipher suites your client supports. This means your client may be used to provide forward secrecy if the server supports it. This greatly increases your protection against snoopers, including global passive adversaries who scoop up large amounts of encrypted traffic and store them until their attacks (or their computers) improve.
Session Ticket Support
Good Session tickets are supported in your client. Services you use will be able to scale out their TLS connections more easily with this feature.
TLS Compression
Good Your TLS client does not attempt to compress the settings that encrypt your connection, avoiding information leaks from the CRIME attack.
BEAST Vulnerability
Good Your client is not vulnerable to the BEAST attack because it's using a TLS protocol newer than TLS 1.0. The BEAST attack is only possible against clients using TLS 1.0 or earlier using Cipher-Block Chaining cipher suites that do not implement the 1/n-1 record splitting mitigation.
Insecure Cipher Suites
Good Your client doesn't use any cipher suites that are known to be insecure.
Given Cipher Suites
The cipher suites your client said it supports, in the order it sent them, are:
<long list of supported ciphers>
Even on El Capitan, it's a known issue that the default OpenSSL included is out of date, circa v0.9.8. You can check your OpenSSL version from the command line using 'openssl version'. The best way to update OpenSSL on Mac is to use Homebrew, and instructions for doing so are given on the Stripe support site:
How do I upgrade my OpenSSL to support TLS 1.2?
To show that I've tested this, below is the code I'm using on the development server, with the output from
----- app.yaml:
application: <redacted>
version: <redacted>
runtime: python27
api_version: 1
threadsafe: true
handlers:
- url: /.*
script:
----- main.py:
import webapp2
from google.appengine.api import urlfetch
class MainPage(webapp2.RequestHandler):
def get(self):
from google.appengine.api import urlfetch
url = '
fetched = urlfetch.fetch(url, validate_certificate=False)
self.response.write(fetched.content)
app = webapp2.WSGIApplication([('/', MainPage)], debug=True)
---- application output:
Your SSL client is Probably Okay.
Check out the sections below for information about the SSL/TLS client you used to render this page.
Yeah, we really mean "TLS", not "SSL".
Version
Good Your client is using TLS 1.2, the most modern version of the encryption protocol. It gives you access to the fastest, most secure encryption possible on the web.
Ephemeral Key Support
Good Ephemeral keys are used in some of the cipher suites your client supports. This means your client may be used to provide forward secrecy if the server supports it. This greatly increases your protection against snoopers, including global passive adversaries who scoop up large amounts of encrypted traffic and store them until their attacks (or their computers) improve.
Session Ticket Support
Good Session tickets are supported in your client. Services you use will be able to scale out their TLS connections more easily with this feature.
TLS Compression
Good Your TLS client does not attempt to compress the settings that encrypt your connection, avoiding information leaks from the CRIME attack.
BEAST Vulnerability
Good Your client is not vulnerable to the BEAST attack because it's using a TLS protocol newer than TLS 1.0. The BEAST attack is only possible against clients using TLS 1.0 or earlier using Cipher-Block Chaining cipher suites that do not implement the 1/n-1 record splitting mitigation.
Insecure Cipher Suites
Good Your client doesn't use any cipher suites that are known to be insecure.
Given Cipher Suites
The cipher suites your client said it supports, in the order it sent them, are:
<long list of supported ciphers>
ro...@royleban.com
So it's Apple's fault. At least that clears up where the problem is.
I do not have a brew command on my system, nor do any of the other machines at our company. It is my strong preference to keep machines as stock as possible and I don't like the idea of installing unofficial system software or some third party package installer I've never heard of before. And our new machine setup instructions are already complicated enough. Are you aware of any more official way of upgrading openssl?
Also, when I google for the openssl issue, I find many, many people have encountered this problem in many different ways. Is there some way for Google (and Stripe) to help communicate this better? It seems like perhaps we could have short-circuited this whole process with a "you probably have the outdated version of openssl known to exist in El Capitan".
I do not have a brew command on my system, nor do any of the other machines at our company. It is my strong preference to keep machines as stock as possible and I don't like the idea of installing unofficial system software or some third party package installer I've never heard of before. And our new machine setup instructions are already complicated enough. Are you aware of any more official way of upgrading openssl?
Also, when I google for the openssl issue, I find many, many people have encountered this problem in many different ways. Is there some way for Google (and Stripe) to help communicate this better? It seems like perhaps we could have short-circuited this whole process with a "you probably have the outdated version of openssl known to exist in El Capitan".
pa...@google.com
I hope this message finds you well. We've identified a possible workaround for this case.
You could start by installinghttps://www.python.org/ftp/python/2.7.12/python-2.7.12-macosx10.6.pkg and seeing what OpenSSL it comes with. We tested this and found that it is still using version 0.9.8zh, even when upgraded with the latest pyOpenSSL from PyPi.
According tohttps://eclecticlight.co/2016/03/23/the-tls-mess-in-os-x-el-capitan/ :
"""
among the many security fixes in OS X 10.11.4, LibreSSL was updated to version 2.1.8, and OpenSSL to 0.9.8zh.
"""
It appears you were using version 0.9.8.zg (a pre-10.11.4 version), and while even version zh is not sufficient for TLS 1.2, this possibly points to the need (not essential to this specific issue but good in general) to install OS X security fixes. We can confirm the version is zh on a 10.11.6 Mac using Apple's own Python.
To get a more modern openssl, miniconda works -- seehttp://conda.pydata.org/miniconda.html (the installer also prepends the path to the binaries it installs in .bash_profile -- the new PATH is activated when a new Terminal app is opened).
With miniconda (We're running it explicitly from the path where it got installed):
```
$ /Users/username/miniconda2/bin/python
Python 2.7.12 |Continuum Analytics, Inc.| (default, Jul 2 2016, 17:43:17)
[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
Anaconda is brought to you by Continuum Analytics.
Please check out:http://continuum.io/thanks and https://anaconda.org
>>> import ssl
>>> ssl.OPENSSL_VERSION
'OpenSSL 1.0.2h 3 May 2016'
>>>
```
Could you attempt this and let us know the results when using dev_appserver.py? You may need to work with your path to ensure that version of python is running rather than the system default.
You could start by installing
According to
"""
among the many security fixes in OS X 10.11.4, LibreSSL was updated to version 2.1.8, and OpenSSL to 0.9.8zh.
"""
It appears you were using version 0.9.8.zg (a pre-10.11.4 version), and while even version zh is not sufficient for TLS 1.2, this possibly points to the need (not essential to this specific issue but good in general) to install OS X security fixes. We can confirm the version is zh on a 10.11.6 Mac using Apple's own Python.
To get a more modern openssl, miniconda works -- see
With miniconda (We're running it explicitly from the path where it got installed):
```
$ /Users/username/miniconda2/bin/python
Python 2.7.12 |Continuum Analytics, Inc.| (default, Jul 2 2016, 17:43:17)
[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
Anaconda is brought to you by Continuum Analytics.
Please check out:
>>> import ssl
>>> ssl.OPENSSL_VERSION
'OpenSSL 1.0.2h 3 May 2016'
>>>
```
Could you attempt this and let us know the results when using dev_appserver.py? You may need to work with your path to ensure that version of python is running rather than the system default.
ro...@royleban.com
Thanks for the thoughts. What I'm going to do is wait and install macOS Sierra and see if Apple has updated the SSL sufficiently that the problem goes away. If not, I'll look into your suggestions.
ar...@google.com
It's not likely that the next version of macOS will update OpenSSL, as per this statement on the Apple Developer Site [1]:
"Although OpenSSL is commonly used in the open source community, OpenSSL does not provide a stable API from version to version. For this reason, although OS X provides OpenSSL libraries, the OpenSSL libraries in OS X are deprecated, and OpenSSL has never been provided as part of iOS. Use of the OS X OpenSSL libraries by apps is strongly discouraged.
If your app depends on OpenSSL, you should compile OpenSSL yourself and statically link a known version of OpenSSL into your app. This use of OpenSSL is possible on both OS X and iOS. However, unless you are trying to maintain source compatibility with an existing open source project, you should generally use a different API.
Common Crypto and Security Transforms are the recommended alternatives for general encryption. CFNetwork and Secure Transport are the recommended alternatives for secure communications."
The alternative APIs mentioned only work within the Apple ecosystem, so for cross-platform environments such as Python it's necessary to manually update OpenSSL as per Apple's recommendation.
[1]https://developer.apple.com/library/mac/documentation/Security/Conceptual/cryptoservices/GeneralPurposeCrypto/GeneralPurposeCrypto.html
"Although OpenSSL is commonly used in the open source community, OpenSSL does not provide a stable API from version to version. For this reason, although OS X provides OpenSSL libraries, the OpenSSL libraries in OS X are deprecated, and OpenSSL has never been provided as part of iOS. Use of the OS X OpenSSL libraries by apps is strongly discouraged.
If your app depends on OpenSSL, you should compile OpenSSL yourself and statically link a known version of OpenSSL into your app. This use of OpenSSL is possible on both OS X and iOS. However, unless you are trying to maintain source compatibility with an existing open source project, you should generally use a different API.
Common Crypto and Security Transforms are the recommended alternatives for general encryption. CFNetwork and Secure Transport are the recommended alternatives for secure communications."
The alternative APIs mentioned only work within the Apple ecosystem, so for cross-platform environments such as Python it's necessary to manually update OpenSSL as per Apple's recommendation.
[1]
pa...@google.com
Since this has been located as an issue on the development machine rather than the SDK, this issue should close WorkAsIntended soon. Would you like to make a specific feature request in connection with this issue?
pa...@google.com
This issue will close soon due to inactivity. Feel free to reply to the last comment some time in the next 5 days and we'll be happy to assist.
pa...@google.com
This issue has now closed due to inactivity. If you'd like to make a feature request or issue report in future, please feel free to do so. We'll be happy to assist!
[Deleted User] <[Deleted User]>
I do have the same issue. Please help to resolve this.
Ran
import ssl
urlfetch.__file__ = '/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/api/urlfetch.pyc'
ssl.__file__ = '/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ssl.pyc'
ssl.OPENSSL_VERSION = 'OpenSSL 0.9.8zh 14 Jan 2016'
Note: In terminal when I give "openssl version", the response is 'OpenSSL 1.1.0c 10 Nov 2016'. This is after I went through a series of steps to upgrade OpenSSL in /usr/bin in mac.
Ran urlfetch on 'https://howsmyssl.com/? '. Following is the response.
Your SSL client is Bad.
Check out the sections below for information about the SSL/TLS client you used to render this page.
Yeah, we really mean "TLS", not "SSL".
Version
Bad Your client is using TLS 1.0, which is very old, possibly susceptible to the BEAST attack, and doesn't have the best cipher suites available on it. Additions like AES-GCM, and SHA256 to replace MD5-SHA-1 are unavailable to a TLS 1.0 client as well as many more modern cipher suites.
Learn More
Ephemeral Key Support
Good Ephemeral keys are used in some of the cipher suites your client supports. This means your client may be used to provide forward secrecy if the server supports it. This greatly increases your protection against snoopers, including global passive adversaries who scoop up large amounts of encrypted traffic and store them until their attacks (or their computers) improve.
Learn More
Session Ticket Support
Good Session tickets are supported in your client. Services you use will be able to scale out their TLS connections more easily with this feature.
Learn More
TLS Compression
Good Your TLS client does not attempt to compress the settings that encrypt your connection, avoiding information leaks from the CRIME attack.
Learn More
BEAST Vulnerability
Good Your client is not vulnerable to the BEAST attack. While it's using TLS 1.0 in conjunction with Cipher-Block Chaining cipher suites, it has implemented the 1/n-1 record splitting mitigation.
Learn More
Insecure Cipher Suites
Good Your client doesn't use any cipher suites that are known to be insecure.
Learn More
Given Cipher Suites
The cipher suites your client said it supports, in the order it sent them, are:
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_EMPTY_RENEGOTIATION_INFO_SCSV
Learn More
Ran
import ssl
urlfetch.__file__ = '/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/api/urlfetch.pyc'
ssl.__file__ = '/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ssl.pyc'
ssl.OPENSSL_VERSION = 'OpenSSL 0.9.8zh 14 Jan 2016'
Note: In terminal when I give "openssl version", the response is 'OpenSSL 1.1.0c 10 Nov 2016'. This is after I went through a series of steps to upgrade OpenSSL in /usr/bin in mac.
Ran urlfetch on '
Your SSL client is Bad.
Check out the sections below for information about the SSL/TLS client you used to render this page.
Yeah, we really mean "TLS", not "SSL".
Version
Bad Your client is using TLS 1.0, which is very old, possibly susceptible to the BEAST attack, and doesn't have the best cipher suites available on it. Additions like AES-GCM, and SHA256 to replace MD5-SHA-1 are unavailable to a TLS 1.0 client as well as many more modern cipher suites.
Learn More
Ephemeral Key Support
Good Ephemeral keys are used in some of the cipher suites your client supports. This means your client may be used to provide forward secrecy if the server supports it. This greatly increases your protection against snoopers, including global passive adversaries who scoop up large amounts of encrypted traffic and store them until their attacks (or their computers) improve.
Learn More
Session Ticket Support
Good Session tickets are supported in your client. Services you use will be able to scale out their TLS connections more easily with this feature.
Learn More
TLS Compression
Good Your TLS client does not attempt to compress the settings that encrypt your connection, avoiding information leaks from the CRIME attack.
Learn More
BEAST Vulnerability
Good Your client is not vulnerable to the BEAST attack. While it's using TLS 1.0 in conjunction with Cipher-Block Chaining cipher suites, it has implemented the 1/n-1 record splitting mitigation.
Learn More
Insecure Cipher Suites
Good Your client doesn't use any cipher suites that are known to be insecure.
Learn More
Given Cipher Suites
The cipher suites your client said it supports, in the order it sent them, are:
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_EMPTY_RENEGOTIATION_INFO_SCSV
Learn More
pa...@google.com
Please see post #11 to see that the issue on your system is related to the version of openssl you're using
https://code.google.com/p/googleappengine/issues/detail?id=13207#c11
[Deleted User] <[Deleted User]>
[Comment deleted]
[Deleted User] <[Deleted User]>
It worked like a charm.. !!
But now another error is being thrown
'Network error: Invalid and/or missing SSL certificate for URL:https://api.stripe.com/ '.
I got a workaround to disable verifying SSL certificate.
import os
if os.environ.get('SERVER_SOFTWARE', '').startswith('Development'):
stripe.verify_ssl_certs = False
But is there any other solution to his issue?
But now another error is being thrown
'Network error: Invalid and/or missing SSL certificate for URL:
I got a workaround to disable verifying SSL certificate.
import os
if os.environ.get('SERVER_SOFTWARE', '').startswith('Development'):
stripe.verify_ssl_certs = False
But is there any other solution to his issue?
pa...@google.com
It's definitely not advised to turn off SSL (security) when dealing with an API for online payments. You should use the advice in
ro...@royleban.com
Since Stripe only allows you to use specific fake credit card numbers with their test server, turning off SSL verification for testing is not a bad thing. Turning off SSL itself is not allowed with their API.
ga...@gmail.com
I did follow the post #11. But I was able to update openssl version used by urlfetch to the latest running in my machine using miniconda.
What other step have I missed?
And thanks for the info #22
What other step have I missed?
And thanks for the info #22
pa...@google.com
Do you still see the error? What version of SSL / TLS is your UrlFetch service now using? You can use the domain mentioned earlier in this thread to test:
https://howsmyssl.com/
[Deleted User] <[Deleted User]>
No, I do not encounter the error related to SSL version. What I'm currently encountering is Post #20
Following is the response to urlfetch on 'https://howsmyssl.com/ '.
Your SSL client is Probably Okay.
Check out the sections below for information about the SSL/TLS client you used to render this page.
Yeah, we really mean "TLS", not "SSL".
Version
Good Your client is using TLS 1.2, the most modern version of the encryption protocol. It gives you access to the fastest, most secure encryption possible on the web.
Learn More
Ephemeral Key Support
Good Ephemeral keys are used in some of the cipher suites your client supports. This means your client may be used to provide forward secrecy if the server supports it. This greatly increases your protection against snoopers, including global passive adversaries who scoop up large amounts of encrypted traffic and store them until their attacks (or their computers) improve.
Learn More
Session Ticket Support
Good Session tickets are supported in your client. Services you use will be able to scale out their TLS connections more easily with this feature.
Learn More
TLS Compression
Good Your TLS client does not attempt to compress the settings that encrypt your connection, avoiding information leaks from the CRIME attack.
Learn More
BEAST Vulnerability
Good Your client is not vulnerable to the BEAST attack because it's using a TLS protocol newer than TLS 1.0. The BEAST attack is only possible against clients using TLS 1.0 or earlier using Cipher-Block Chaining cipher suites that do not implement the 1/n-1 record splitting mitigation.
Learn More
Insecure Cipher Suites
Good Your client doesn't use any cipher suites that are known to be insecure.
Learn More
Given Cipher Suites
The cipher suites your client said it supports, in the order it sent them, are:
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
TLS_DH_DSS_WITH_AES_256_GCM_SHA384
TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
TLS_DH_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DH_DSS_WITH_AES_128_GCM_SHA256
TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
TLS_DH_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
TLS_DH_RSA_WITH_AES_256_CBC_SHA256
TLS_DH_DSS_WITH_AES_256_CBC_SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_DH_RSA_WITH_AES_256_CBC_SHA
TLS_DH_DSS_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
TLS_DH_RSA_WITH_AES_128_CBC_SHA256
TLS_DH_DSS_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_DH_RSA_WITH_AES_128_CBC_SHA
TLS_DH_DSS_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA
TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA
TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA
TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA
TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_EMPTY_RENEGOTIATION_INFO_SCSV
Learn More
Following is the response to urlfetch on '
Your SSL client is Probably Okay.
Check out the sections below for information about the SSL/TLS client you used to render this page.
Yeah, we really mean "TLS", not "SSL".
Version
Good Your client is using TLS 1.2, the most modern version of the encryption protocol. It gives you access to the fastest, most secure encryption possible on the web.
Learn More
Ephemeral Key Support
Good Ephemeral keys are used in some of the cipher suites your client supports. This means your client may be used to provide forward secrecy if the server supports it. This greatly increases your protection against snoopers, including global passive adversaries who scoop up large amounts of encrypted traffic and store them until their attacks (or their computers) improve.
Learn More
Session Ticket Support
Good Session tickets are supported in your client. Services you use will be able to scale out their TLS connections more easily with this feature.
Learn More
TLS Compression
Good Your TLS client does not attempt to compress the settings that encrypt your connection, avoiding information leaks from the CRIME attack.
Learn More
BEAST Vulnerability
Good Your client is not vulnerable to the BEAST attack because it's using a TLS protocol newer than TLS 1.0. The BEAST attack is only possible against clients using TLS 1.0 or earlier using Cipher-Block Chaining cipher suites that do not implement the 1/n-1 record splitting mitigation.
Learn More
Insecure Cipher Suites
Good Your client doesn't use any cipher suites that are known to be insecure.
Learn More
Given Cipher Suites
The cipher suites your client said it supports, in the order it sent them, are:
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
TLS_DH_DSS_WITH_AES_256_GCM_SHA384
TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
TLS_DH_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DH_DSS_WITH_AES_128_GCM_SHA256
TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
TLS_DH_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
TLS_DH_RSA_WITH_AES_256_CBC_SHA256
TLS_DH_DSS_WITH_AES_256_CBC_SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_DH_RSA_WITH_AES_256_CBC_SHA
TLS_DH_DSS_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
TLS_DH_RSA_WITH_AES_128_CBC_SHA256
TLS_DH_DSS_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_DH_RSA_WITH_AES_128_CBC_SHA
TLS_DH_DSS_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA
TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA
TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA
TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA
TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_EMPTY_RENEGOTIATION_INFO_SCSV
Learn More
pa...@google.com
" Your client is using TLS 1.2, the most modern version of the encryption protocol."
^^^ this message should mean that the Stripe API will be happy with your requests. Have you tried to make any requests yet? What error (if any) did you see?
^^^ this message should mean that the Stripe API will be happy with your requests. Have you tried to make any requests yet? What error (if any) did you see?
[Deleted User] <[Deleted User]>
I get the following error, when making requests to stripe in local dev.
"Unexpected error communicating with Stripe. If this problem persists,
let us know at support@stripe.com.
(Network error: Invalid and/or missing SSL certificate for URL:https://api.stripe.com )"
"Unexpected error communicating with Stripe. If this problem persists,
let us know at support@stripe.com.
(Network error: Invalid and/or missing SSL certificate for URL:
pa...@google.com
Does this occur each time?
Could you share the complete code you're using to make the request?
Could you share the complete code you're using to make the request?
pr...@gmail.com
I have the same problem listed in comments 20 and 27. I am on Mac OS 10.11.6. I have Homebrew Python installed with updated openssl.
Outside of app engine, the Stripe API falls back to the requests library since urlfetch isn’t available. Loading the same page using that works.
-DEV SERVER INFO-
All of the below commands were run in dev_appserver.
THE CODE:
I took the instructions fromhttps://support.stripe.com/questions/how-do-i-upgrade-my-stripe-integration-from-tls-1-0-to-tls-1-2 , and found this is the code that triggers this issue:
from google.appengine.api import urlfetch
urlfetch.fetch(
url='https://api-tls12.stripe.com/v1/charges ',
method='get',
headers={'X-Stripe-Client-User-Agent': '{"uname": "Linux ", "publisher": "stripe", "httplib": "urlfetch", "lang_version": "2.7.12", "platform": "!! [Errno 13] file not accessible: \'/usr/local/opt/python/bin/python2.7\'", "bindings_version": "1.27.1", "lang": "python"}', 'User-Agent': 'Stripe/v1 PythonBindings/1.27.1', 'Authorization': 'Bearer sk_test_BQokikJOvBiI2HlWgH4olfQ2'},
validate_certificate=True,
deadline=55,
payload=None
)
SYSTEM INFO:
>>> import google.appengine.api.urlfetch as urlfetch
>>> import ssl
>>> print urlfetch.__file__
/Users/[my-user]/google-cloud-sdk/platform/google_appengine/google/appengine/api/urlfetch.pyc
>>> print ssl.__file__
/usr/local/Cellar/python/2.7.12_2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ssl.pyc
>>> print ssl.OPENSSL_VERSION
OpenSSL 1.0.2j 26 Sep 2016
HOWS MY SSL:
>>> urlfetch.fetch(url='https://howsmyssl.com ')
Your SSL client is Probably Okay.
Version: Good (Your client is using TLS 1.2...)
Ephemeral Key Support: Good
Session Ticket Support: Good
TLS Compression: Good
BEAST Vulnerability: Good
Insecure Cipher Suites: Good
Given Cipher Suites:
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
TLS_DH_DSS_WITH_AES_256_GCM_SHA384
TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
TLS_DH_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DH_DSS_WITH_AES_128_GCM_SHA256
TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
TLS_DH_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
TLS_DH_RSA_WITH_AES_256_CBC_SHA256
TLS_DH_DSS_WITH_AES_256_CBC_SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_DH_RSA_WITH_AES_256_CBC_SHA
TLS_DH_DSS_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
TLS_DH_RSA_WITH_AES_128_CBC_SHA256
TLS_DH_DSS_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_DH_RSA_WITH_AES_128_CBC_SHA
TLS_DH_DSS_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA
TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA
TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA
TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA
TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_EMPTY_RENEGOTIATION_INFO_SCSV
-COMMAND LINE RESULTS-
All of the below commands were run in the command line.
DEV APPSERVER LOCATION:
$ which dev_appserver.py
/Users/[my-user]/google-cloud-sdk/bin/dev_appserver.py
GCLOUD INFO
$ gcloud info
Google Cloud SDK [137.0.0]
Platform: [Mac OS X, x86_64]
Python Version: [2.7.12 (default, Oct 11 2016, 05:24:00) [GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.38)]]
Python Location: [/usr/local/Cellar/python/2.7.12_2/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python]
Site Packages: [Disabled]
Installation Root: [/Users/[my-user]/google-cloud-sdk]
Installed Components:
core: [2016.12.06]
app-engine-python: [1.9.40]
core-nix: [2016.11.07]
gcloud: []
gsutil-nix: [4.18]
app-engine-php: [ ]
gsutil: [4.22]
bq: [2.0.24]
app-engine-php-darwin: [2015.11.16]
alpha: [2016.01.12]
bq-nix: [2.0.24]
System PATH: [/Users/[my-user]/google-cloud-sdk/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/mysql/bin]
Cloud SDK on PATH: [True]
Kubectl on PATH: [False]
Installation Properties: [/Users/[my-user]/google-cloud-sdk/properties]
User Config Directory: [/Users/[my-user]/.config/gcloud]
Active Configuration Name: [default]
Active Configuration Path: [/Users/[my-user]/.config/gcloud/configurations/config_default]
Account: [<my-email>]
Project: [<my-project>]
Current Properties:
[core]
project: [<my-project>]
account: [<my-email>]
disable_usage_reporting: [True]
[app]
stop_previous_version: [true]
[compute]
region: [us-central1]
zone: [us-central1-a]
Logs Directory: [/Users/[my-user]/.config/gcloud/logs]
Last Log File: [/Users/[my-user]/.config/gcloud/logs/2016.12.08/13.26.40.203439.log]
Outside of app engine, the Stripe API falls back to the requests library since urlfetch isn’t available. Loading the same page using that works.
-DEV SERVER INFO-
All of the below commands were run in dev_appserver.
THE CODE:
I took the instructions from
from google.appengine.api import urlfetch
urlfetch.fetch(
url='
method='get',
headers={'X-Stripe-Client-User-Agent': '{"uname": "Linux ", "publisher": "stripe", "httplib": "urlfetch", "lang_version": "2.7.12", "platform": "!! [Errno 13] file not accessible: \'/usr/local/opt/python/bin/python2.7\'", "bindings_version": "1.27.1", "lang": "python"}', 'User-Agent': 'Stripe/v1 PythonBindings/1.27.1', 'Authorization': 'Bearer sk_test_BQokikJOvBiI2HlWgH4olfQ2'},
validate_certificate=True,
deadline=55,
payload=None
)
SYSTEM INFO:
>>> import google.appengine.api.urlfetch as urlfetch
>>> import ssl
>>> print urlfetch.__file__
/Users/[my-user]/google-cloud-sdk/platform/google_appengine/google/appengine/api/urlfetch.pyc
>>> print ssl.__file__
/usr/local/Cellar/python/2.7.12_2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ssl.pyc
>>> print ssl.OPENSSL_VERSION
OpenSSL 1.0.2j 26 Sep 2016
HOWS MY SSL:
>>> urlfetch.fetch(url='
Your SSL client is Probably Okay.
Version: Good (Your client is using TLS 1.2...)
Ephemeral Key Support: Good
Session Ticket Support: Good
TLS Compression: Good
BEAST Vulnerability: Good
Insecure Cipher Suites: Good
Given Cipher Suites:
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
TLS_DH_DSS_WITH_AES_256_GCM_SHA384
TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
TLS_DH_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DH_DSS_WITH_AES_128_GCM_SHA256
TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
TLS_DH_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
TLS_DH_RSA_WITH_AES_256_CBC_SHA256
TLS_DH_DSS_WITH_AES_256_CBC_SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_DH_RSA_WITH_AES_256_CBC_SHA
TLS_DH_DSS_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
TLS_DH_RSA_WITH_AES_128_CBC_SHA256
TLS_DH_DSS_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_DH_RSA_WITH_AES_128_CBC_SHA
TLS_DH_DSS_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA
TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA
TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA
TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA
TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_EMPTY_RENEGOTIATION_INFO_SCSV
-COMMAND LINE RESULTS-
All of the below commands were run in the command line.
DEV APPSERVER LOCATION:
$ which dev_appserver.py
/Users/[my-user]/google-cloud-sdk/bin/dev_appserver.py
GCLOUD INFO
$ gcloud info
Google Cloud SDK [137.0.0]
Platform: [Mac OS X, x86_64]
Python Version: [2.7.12 (default, Oct 11 2016, 05:24:00) [GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.38)]]
Python Location: [/usr/local/Cellar/python/2.7.12_2/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python]
Site Packages: [Disabled]
Installation Root: [/Users/[my-user]/google-cloud-sdk]
Installed Components:
core: [2016.12.06]
app-engine-python: [1.9.40]
core-nix: [2016.11.07]
gcloud: []
gsutil-nix: [4.18]
app-engine-php: [ ]
gsutil: [4.22]
bq: [2.0.24]
app-engine-php-darwin: [2015.11.16]
alpha: [2016.01.12]
bq-nix: [2.0.24]
System PATH: [/Users/[my-user]/google-cloud-sdk/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/mysql/bin]
Cloud SDK on PATH: [True]
Kubectl on PATH: [False]
Installation Properties: [/Users/[my-user]/google-cloud-sdk/properties]
User Config Directory: [/Users/[my-user]/.config/gcloud]
Active Configuration Name: [default]
Active Configuration Path: [/Users/[my-user]/.config/gcloud/configurations/config_default]
Account: [<my-email>]
Project: [<my-project>]
Current Properties:
[core]
project: [<my-project>]
account: [<my-email>]
disable_usage_reporting: [True]
[app]
stop_previous_version: [true]
[compute]
region: [us-central1]
zone: [us-central1-a]
Logs Directory: [/Users/[my-user]/.config/gcloud/logs]
Last Log File: [/Users/[my-user]/.config/gcloud/logs/2016.12.08/13.26.40.203439.log]
pa...@google.com
Do I understand correctly by saying that this issue only appears in the development environment when using url fetch?
pr...@gmail.com
The issue appears in the development environment with both urlfetch and requests. It works properly both when using urlfetch on the live server or when using requests directly in Python.
Here are the full errors for both libraries on the dev server.
REQUESTS:
import requests
requests.request(
'get',
'https://api-tls12.stripe.com/v1/charges ',
headers={'User-Agent': 'Stripe/v1 PythonBindings/1.27.1', 'X-Stripe-Client-User-Agent': '{"lang_version": "2.7.12", "httplib": "requests", "lang": "python", "bindings_version": "1.27.1", "publisher": "stripe", "platform": "!! [Errno 13] file not accessible: \'/usr/local/opt/python/bin/python2.7\'", "uname": "Linux "}', 'Authorization': 'Bearer sk_test_BQokikJOvBiI2HlWgH4olfQ2'},
data=None,
timeout=55
)
ERROR 2016-12-08 20:50:34,183 webapp2.py:1552] ('Connection aborted.', error(13, 'Permission denied'))
Traceback (most recent call last):
File "/Users/[USER]/google-cloud-sdk/platform/google_appengine/lib/webapp2-2.5.2/webapp2.py", line 1535, in __call__
rv = self.handle_exception(request, response, e)
File "/Users/[USER]/google-cloud-sdk/platform/google_appengine/lib/webapp2-2.5.2/webapp2.py", line 1529, in __call__
rv = self.router.dispatch(request, response)
File "/Users/[USER]/google-cloud-sdk/platform/google_appengine/lib/webapp2-2.5.2/webapp2.py", line 1278, in default_dispatcher
return route.handler_adapter(request, response)
File "/Users/[USER]/google-cloud-sdk/platform/google_appengine/lib/webapp2-2.5.2/webapp2.py", line 1102, in __call__
return handler.dispatch()
File "/Users/[USER]/google-cloud-sdk/platform/google_appengine/lib/webapp2-2.5.2/webapp2.py", line 572, in dispatch
return self.handle_exception(e, self.app.debug)
File "/Users/[USER]/google-cloud-sdk/platform/google_appengine/lib/webapp2-2.5.2/webapp2.py", line 570, in dispatch
return method(*args, **kwargs)
File "/Users/[USER]/Development/[PROJECT]/controller/default/main.py", line 848, in get
verify='/Users/[USER]/Development/[PROJECT]/controller/default/lib/stripe/data/ca-certificates.crt'
File "/Users/[USER]/Development/[PROJECT]/controller/default/lib/requests/api.py", line 56, in request
return session.request(method=method, url=url, **kwargs)
File "/Users/[USER]/Development/[PROJECT]/controller/default/lib/requests/sessions.py", line 488, in request
resp = self.send(prep, **send_kwargs)
File "/Users/[USER]/Development/[PROJECT]/controller/default/lib/requests/sessions.py", line 609, in send
r = adapter.send(request, **kwargs)
File "/Users/[USER]/Development/[PROJECT]/controller/default/lib/requests/adapters.py", line 473, in send
raise ConnectionError(err, request=request)
ConnectionError: ('Connection aborted.', error(13, 'Permission denied'))
URLFETCH:
from google.appengine.api import urlfetch
urlfetch.fetch(
url='https://api-tls12.stripe.com/v1/charges ',
method='get',
headers={'X-Stripe-Client-User-Agent': '{"uname": "Linux ", "publisher": "stripe", "httplib": "urlfetch", "lang_version": "2.7.12", "platform": "!! [Errno 13] file not accessible: \'/usr/local/opt/python/bin/python2.7\'", "bindings_version": "1.27.1", "lang": "python"}', 'User-Agent': 'Stripe/v1 PythonBindings/1.27.1', 'Authorization': 'Bearer sk_test_BQokikJOvBiI2HlWgH4olfQ2'},
validate_certificate=True,
deadline=55,
payload=None
)
ERROR 2016-12-08 21:13:23,253 webapp2.py:1552] Invalid and/or missing SSL certificate for URL:https://api-tls12.stripe.com/v1/charges
Traceback (most recent call last):
File "/Users/[USER]/google-cloud-sdk/platform/google_appengine/lib/webapp2-2.5.2/webapp2.py", line 1535, in __call__
rv = self.handle_exception(request, response, e)
File "/Users/[USER]/google-cloud-sdk/platform/google_appengine/lib/webapp2-2.5.2/webapp2.py", line 1529, in __call__
rv = self.router.dispatch(request, response)
File "/Users/[USER]/google-cloud-sdk/platform/google_appengine/lib/webapp2-2.5.2/webapp2.py", line 1278, in default_dispatcher
return route.handler_adapter(request, response)
File "/Users/[USER]/google-cloud-sdk/platform/google_appengine/lib/webapp2-2.5.2/webapp2.py", line 1102, in __call__
return handler.dispatch()
File "/Users/[USER]/google-cloud-sdk/platform/google_appengine/lib/webapp2-2.5.2/webapp2.py", line 572, in dispatch
return self.handle_exception(e, self.app.debug)
File "/Users/[USER]/google-cloud-sdk/platform/google_appengine/lib/webapp2-2.5.2/webapp2.py", line 570, in dispatch
return method(*args, **kwargs)
File "/Users/[USER]/Development/[PROJECT]/controller/default/main.py", line 848, in get
payload=None
File "/Users/[USER]/google-cloud-sdk/platform/google_appengine/google/appengine/api/urlfetch.py", line 271, in fetch
return rpc.get_result()
File "/Users/[USER]/google-cloud-sdk/platform/google_appengine/google/appengine/api/apiproxy_stub_map.py", line 613, in get_result
return self.__get_result_hook(self)
File "/Users/[USER]/google-cloud-sdk/platform/google_appengine/google/appengine/api/urlfetch.py", line 432, in _get_fetch_result
'Invalid and/or missing SSL certificate for URL: ' + url)
SSLCertificateError: Invalid and/or missing SSL certificate for URL:https://api-tls12.stripe.com/v1/charges
INFO 2016-12-08 21:13:23,266 module.py:788] default: "GET /dashboard/test HTTP/1.1" 500 228
Here are the full errors for both libraries on the dev server.
REQUESTS:
import requests
requests.request(
'get',
'
headers={'User-Agent': 'Stripe/v1 PythonBindings/1.27.1', 'X-Stripe-Client-User-Agent': '{"lang_version": "2.7.12", "httplib": "requests", "lang": "python", "bindings_version": "1.27.1", "publisher": "stripe", "platform": "!! [Errno 13] file not accessible: \'/usr/local/opt/python/bin/python2.7\'", "uname": "Linux "}', 'Authorization': 'Bearer sk_test_BQokikJOvBiI2HlWgH4olfQ2'},
data=None,
timeout=55
)
ERROR 2016-12-08 20:50:34,183 webapp2.py:1552] ('Connection aborted.', error(13, 'Permission denied'))
Traceback (most recent call last):
File "/Users/[USER]/google-cloud-sdk/platform/google_appengine/lib/webapp2-2.5.2/webapp2.py", line 1535, in __call__
rv = self.handle_exception(request, response, e)
File "/Users/[USER]/google-cloud-sdk/platform/google_appengine/lib/webapp2-2.5.2/webapp2.py", line 1529, in __call__
rv = self.router.dispatch(request, response)
File "/Users/[USER]/google-cloud-sdk/platform/google_appengine/lib/webapp2-2.5.2/webapp2.py", line 1278, in default_dispatcher
return route.handler_adapter(request, response)
File "/Users/[USER]/google-cloud-sdk/platform/google_appengine/lib/webapp2-2.5.2/webapp2.py", line 1102, in __call__
return handler.dispatch()
File "/Users/[USER]/google-cloud-sdk/platform/google_appengine/lib/webapp2-2.5.2/webapp2.py", line 572, in dispatch
return self.handle_exception(e, self.app.debug)
File "/Users/[USER]/google-cloud-sdk/platform/google_appengine/lib/webapp2-2.5.2/webapp2.py", line 570, in dispatch
return method(*args, **kwargs)
File "/Users/[USER]/Development/[PROJECT]/controller/default/main.py", line 848, in get
verify='/Users/[USER]/Development/[PROJECT]/controller/default/lib/stripe/data/ca-certificates.crt'
File "/Users/[USER]/Development/[PROJECT]/controller/default/lib/requests/api.py", line 56, in request
return session.request(method=method, url=url, **kwargs)
File "/Users/[USER]/Development/[PROJECT]/controller/default/lib/requests/sessions.py", line 488, in request
resp = self.send(prep, **send_kwargs)
File "/Users/[USER]/Development/[PROJECT]/controller/default/lib/requests/sessions.py", line 609, in send
r = adapter.send(request, **kwargs)
File "/Users/[USER]/Development/[PROJECT]/controller/default/lib/requests/adapters.py", line 473, in send
raise ConnectionError(err, request=request)
ConnectionError: ('Connection aborted.', error(13, 'Permission denied'))
URLFETCH:
from google.appengine.api import urlfetch
urlfetch.fetch(
url='
method='get',
headers={'X-Stripe-Client-User-Agent': '{"uname": "Linux ", "publisher": "stripe", "httplib": "urlfetch", "lang_version": "2.7.12", "platform": "!! [Errno 13] file not accessible: \'/usr/local/opt/python/bin/python2.7\'", "bindings_version": "1.27.1", "lang": "python"}', 'User-Agent': 'Stripe/v1 PythonBindings/1.27.1', 'Authorization': 'Bearer sk_test_BQokikJOvBiI2HlWgH4olfQ2'},
validate_certificate=True,
deadline=55,
payload=None
)
ERROR 2016-12-08 21:13:23,253 webapp2.py:1552] Invalid and/or missing SSL certificate for URL:
Traceback (most recent call last):
File "/Users/[USER]/google-cloud-sdk/platform/google_appengine/lib/webapp2-2.5.2/webapp2.py", line 1535, in __call__
rv = self.handle_exception(request, response, e)
File "/Users/[USER]/google-cloud-sdk/platform/google_appengine/lib/webapp2-2.5.2/webapp2.py", line 1529, in __call__
rv = self.router.dispatch(request, response)
File "/Users/[USER]/google-cloud-sdk/platform/google_appengine/lib/webapp2-2.5.2/webapp2.py", line 1278, in default_dispatcher
return route.handler_adapter(request, response)
File "/Users/[USER]/google-cloud-sdk/platform/google_appengine/lib/webapp2-2.5.2/webapp2.py", line 1102, in __call__
return handler.dispatch()
File "/Users/[USER]/google-cloud-sdk/platform/google_appengine/lib/webapp2-2.5.2/webapp2.py", line 572, in dispatch
return self.handle_exception(e, self.app.debug)
File "/Users/[USER]/google-cloud-sdk/platform/google_appengine/lib/webapp2-2.5.2/webapp2.py", line 570, in dispatch
return method(*args, **kwargs)
File "/Users/[USER]/Development/[PROJECT]/controller/default/main.py", line 848, in get
payload=None
File "/Users/[USER]/google-cloud-sdk/platform/google_appengine/google/appengine/api/urlfetch.py", line 271, in fetch
return rpc.get_result()
File "/Users/[USER]/google-cloud-sdk/platform/google_appengine/google/appengine/api/apiproxy_stub_map.py", line 613, in get_result
return self.__get_result_hook(self)
File "/Users/[USER]/google-cloud-sdk/platform/google_appengine/google/appengine/api/urlfetch.py", line 432, in _get_fetch_result
'Invalid and/or missing SSL certificate for URL: ' + url)
SSLCertificateError: Invalid and/or missing SSL certificate for URL:
INFO 2016-12-08 21:13:23,266 module.py:788] default: "GET /dashboard/test HTTP/1.1" 500 228
pa...@google.com
Could you run the following commands and let us know the output? Also does connecting to simply api.stripe.com resolve the issue?
openssl s_client -connectapi.stripe.com:443
openssl s_client -connectapi-tls12.stripe.com:443
openssl s_client -connect
openssl s_client -connect
pa...@google.com
[Comment deleted]
pa...@google.com
Any updates on this? Those requests will determine which certificate is fetched from your machine's location. Let us know the results and we'll be happy to help!
pr...@gmail.com
Sorry I missed this response earlier.
My Python binary was compiled using the openssl in /usr/local/Cellar/openssl/1.0.2j/bin/openssl, so I ran the commands using that:
> /usr/local/Cellar/openssl/1.0.2j/bin/openssl s_client -connectapi.stripe.com:443
CONNECTED(00000003)
depth=2 C = US, O = DigiCert Inc, OU =www.digicert.com , CN = DigiCert High Assurance EV Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, OU =www.digicert.com , CN = DigiCert SHA2 Extended Validation Server CA
verify return:1
depth=0 businessCategory = Private Organization, jurisdictionC = US, jurisdictionST = Delaware, serialNumber = 4675506, street = "3180 18th St., Suite 100", postalCode = 94110, C = US, ST = California, L = San Francisco, O = "Stripe, Inc", CN =api.stripe.com
verify return:1
---
Certificate chain
0 s:/businessCategory=Private Organization/jurisdictionC=US/jurisdictionST=Delaware/serialNumber=4675506/street=3180 18th St., Suite 100/postalCode=94110/C=US/ST=California/L=San Francisco/O=Stripe, Inc/CN=api.stripe.com
i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 Extended Validation Server CA
1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 Extended Validation Server CA
i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIH5TCCBs2gAwIBAgIQCsu/CLRUC4R1bSVCMQGGozANBgkqhkiG9w0BAQsFADB1
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMTQwMgYDVQQDEytEaWdpQ2VydCBTSEEyIEV4dGVuZGVk
IFZhbGlkYXRpb24gU2VydmVyIENBMB4XDTE2MTAxODAwMDAwMFoXDTE3MDIwMTEy
MDAwMFowgf0xHTAbBgNVBA8MFFByaXZhdGUgT3JnYW5pemF0aW9uMRMwEQYLKwYB
BAGCNzwCAQMTAlVTMRkwFwYLKwYBBAGCNzwCAQITCERlbGF3YXJlMRAwDgYDVQQF
Ewc0Njc1NTA2MSEwHwYDVQQJExgzMTgwIDE4dGggU3QuLCBTdWl0ZSAxMDAxDjAM
BgNVBBETBTk0MTEwMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEW
MBQGA1UEBxMNU2FuIEZyYW5jaXNjbzEUMBIGA1UEChMLU3RyaXBlLCBJbmMxFzAV
BgNVBAMTDmFwaS5zdHJpcGUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAu3dfD3fhdFPKph4MC9tngAdqENPjeL0hiVepHjhDXyUTJcpp3fePdP8+
TuCxs9dOAdiRr8W89B+B+UJ04+ayBuYBkuLaaU0l5vft89n0qOiyx2MOp0P9ft4z
16ZleHyQsGF5ZN5iH6sFitkeZRrbksh9aP1ftLm6fAzEIp+ZNpzXcQYL/JmOuZ2a
EctFujhWyceLiJLha1c3fR8L6RfKxFRleTcTXCsGt82OWW0UwDHiJQ+sE36cCHV9
Rt5FlISPVLnI4f6xuaDyeJL6hjSZ7A2RHYppooCvXkxJj1iE1TqWlzEySa8FANuv
LDBIv+5+6iqcTDa6RM+XOGMM9bmVdwIDAQABo4ID5jCCA+IwHwYDVR0jBBgwFoAU
PdNQpdagre7zSmAKZdMh1Pj41g8wHQYDVR0OBBYEFLJtON4LT/9CcVPoXDTkrKAg
l95IMBkGA1UdEQQSMBCCDmFwaS5zdHJpcGUuY29tMA4GA1UdDwEB/wQEAwIFoDAd
BgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwdQYDVR0fBG4wbDA0oDKgMIYu
aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL3NoYTItZXYtc2VydmVyLWcxLmNybDA0
oDKgMIYuaHR0cDovL2NybDQuZGlnaWNlcnQuY29tL3NoYTItZXYtc2VydmVyLWcx
LmNybDBLBgNVHSAERDBCMDcGCWCGSAGG/WwCATAqMCgGCCsGAQUFBwIBFhxodHRw
czovL3d3dy5kaWdpY2VydC5jb20vQ1BTMAcGBWeBDAEBMIGIBggrBgEFBQcBAQR8
MHowJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBSBggrBgEF
BQcwAoZGaHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkV4
dGVuZGVkVmFsaWRhdGlvblNlcnZlckNBLmNydDAMBgNVHRMBAf8EAjAAMIIB9wYK
KwYBBAHWeQIEAgSCAecEggHjAeEAdgCkuQmQtBhYFIe7E6LMZ3AKPDWYBPkb37jj
d80OyA3cEAAAAVfVJDNdAAAEAwBHMEUCIQDKRzFEzmGN3PQy6nxSWTjYNarFPAds
d2Xe2nK9fjTH2gIgIrSDCRzRbnGyfgUG4HYWOmZZJc8tOL/zynW7P8VevPEAdwBo
9pj4H2SCvjqM7rkoHUz8cVFdZ5PURNEKZ6y7T0/7xAAAAVfVJDMkAAAEAwBIMEYC
IQDXK0oAnyH0U2F7cyF9ENE5bHSTXATwvhj0+aOXP7twpgIhAOlb4HpA3EtKx36O
OryUfBt4s6RiWKRX6HMwuGJ6ALVsAHYAVhQGmi/XwuzT9eG9RLI+x0Z2ubyZEVzA
75SYVdaJ0N0AAAFX1SQzhQAABAMARzBFAiAEcE1oaN/iQnYpcA6mQ4zxuC0kww4p
X8fbenq0e3E09gIhAK5RmOd/IoHiERQJMoHkO9StDPJA0CwPhq4b6o8aIZccAHYA
7ku9t3XOYLrhQmkfq+GeZqMPfl+wctiDAMR7iXqo/csAAAFX1SQ10wAABAMARzBF
AiAveGpJBHssOLWWZnnhmk3qrS93Ye9Q5I6Vspu2sfuX6gIhAK+KxpKYbPkKgHVe
8T8qG82Rui61V94lwLA8rk9WbtOeMA0GCSqGSIb3DQEBCwUAA4IBAQCD/RZ0OP1Q
ldbF5ndg5Lsyi4mu0Gp2Y7j5L0ARqgRELjbrIFmv4xg8iCjcpP1eWzIpSl4qTaZz
W6BgqtNxW/u8ZjnWD8jqjF5lujfqLEKaMqxs50/BArfIYfKIbGu6nlpEXWgN+SBN
+cmTCMY5STnL9DgdZip9Zxm12RrLVp9wqav4LHjFRwQXFpYotv8QX/1jXI+6PSD6
fyW1rjgDLDMntFI7+f+RYQqhMv9/pzEALfG/XSfhDegX87ijy88B2BxgciuKnRP7
0arDzV2QerwRaoX6SYiijT02x/EuobEFFJ0xsvla5U9RZrggqU7LJBgdLCcYiYSV
h9VehVGVwYTQ
-----END CERTIFICATE-----
subject=/businessCategory=Private Organization/jurisdictionC=US/jurisdictionST=Delaware/serialNumber=4675506/street=3180 18th St., Suite 100/postalCode=94110/C=US/ST=California/L=San Francisco/O=Stripe, Inc/CN=api.stripe.com
issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 Extended Validation Server CA
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3913 bytes and written 434 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES128-GCM-SHA256
Session-ID: EA798657F4EB6E3A77D99FAEDCF1EB9DB827AB99A987AA61637E64907172A842
Session-ID-ctx:
Master-Key: 29797E1AAFACC262CC7172308B75F278CE48B67D200D977DF7E72E4D63994866CB2674ACF182306A88A2AECD43C2CBA9
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - 1b 48 e5 77 41 ff 94 f2-76 1c 39 b5 9e 03 c3 c6 .H.wA...v.9.....
0010 - 3e 8b 60 95 ef e1 1f 11-f4 fb 48 6a c5 36 3e 5a >.`.......Hj.6>Z
0020 - 10 7a c3 dc 35 be 27 2c-ad 54 d9 29 1f af 84 b8 .z..5.',.T.)....
0030 - 53 ba 65 df ea d4 65 b0-b4 59 13 38 63 95 5e ec S.e...e..Y.8c.^.
0040 - 4c b5 a8 e6 c8 87 9f a3-be 7d 4e 36 f3 0d d6 b6 L........}N6....
0050 - 03 2c 55 54 95 09 6e ad-14 3f 84 aa 0d 4d d0 ea .,UT..n..?...M..
0060 - 3b a5 57 07 04 a8 82 6f-99 f4 8d 78 c0 7a a3 5d ;.W....o...x.z.]
0070 - 12 ef 5e c5 00 7b 0a 6e-19 3e cc a6 36 7e af 77 ..^..{.n.>..6~.w
0080 - 45 39 5c 19 a8 d9 4c 2a-d3 67 70 50 5a 05 42 37 E9\...L*.gpPZ.B7
0090 - 83 f1 f5 9b 4c 4e 3d 94-93 c9 cd 52 12 ed 2e e9 ....LN=....R....
00a0 - c4 7a a8 52 b9 7c a6 2a-31 3e 1b 55 58 8a 5a d0 .z.R.|.*1>.UX.Z.
Start Time: 1481848401
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
read:errno=0
==========================================
> /usr/local/Cellar/openssl/1.0.2j/bin/openssl s_client -connectapi-tls12.stripe.com:443
CONNECTED(00000003)
depth=2 C = US, O = DigiCert Inc, OU =www.digicert.com , CN = DigiCert High Assurance EV Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, OU =www.digicert.com , CN = DigiCert SHA2 Extended Validation Server CA
verify return:1
depth=0 businessCategory = Private Organization, jurisdictionC = US, jurisdictionST = Delaware, serialNumber = 4675506, street = "3180 18th St., Suite 100", postalCode = 94110, C = US, ST = California, L = San Francisco, O = "Stripe, Inc", CN =api-tls12.stripe.com
verify return:1
---
Certificate chain
0 s:/businessCategory=Private Organization/jurisdictionC=US/jurisdictionST=Delaware/serialNumber=4675506/street=3180 18th St., Suite 100/postalCode=94110/C=US/ST=California/L=San Francisco/O=Stripe, Inc/CN=api-tls12.stripe.com
i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 Extended Validation Server CA
1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 Extended Validation Server CA
i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIHdzCCBl+gAwIBAgIQCkZJVSvxH4uYYPHvS7Ly5jANBgkqhkiG9w0BAQsFADB1
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMTQwMgYDVQQDEytEaWdpQ2VydCBTSEEyIEV4dGVuZGVk
IFZhbGlkYXRpb24gU2VydmVyIENBMB4XDTE2MDIyNjAwMDAwMFoXDTE3MDQxMjEy
MDAwMFowggEDMR0wGwYDVQQPDBRQcml2YXRlIE9yZ2FuaXphdGlvbjETMBEGCysG
AQQBgjc8AgEDEwJVUzEZMBcGCysGAQQBgjc8AgECEwhEZWxhd2FyZTEQMA4GA1UE
BRMHNDY3NTUwNjEhMB8GA1UECRMYMzE4MCAxOHRoIFN0LiwgU3VpdGUgMTAwMQ4w
DAYDVQQREwU5NDExMDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWEx
FjAUBgNVBAcTDVNhbiBGcmFuY2lzY28xFDASBgNVBAoTC1N0cmlwZSwgSW5jMR0w
GwYDVQQDExRhcGktdGxzMTIuc3RyaXBlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQAD
ggEPADCCAQoCggEBALfZXJ9CP/bNBbXUDy/toPCwc+wHRy0o6hghYuqoP55bCuAj
viMrykfcIqgKcTu/NQ6miTY+UwFhjRRVec6SPMnjNGTCZF65akUCQcEhAhxbOOGr
AA7wbttDBfeoom8PYPJq83CBO0NVmsgIn9WZKbtEiHurjxp9Cgm3Kf8Q7NpCnF43
IADvBo++3wYKJXZ3U4zDdivBmW8laxfC4M+t1IROCsH5O5E+uMLlBAk6fzb9MCvx
u2jP/Q4fZ7tJE9jh9P6LRB0MDTvRXTkAd1ioBRuqPY3yAuU7rWyU5hFq5BQrr59i
Xi7jcaa6jb5mFnHbZfTyxzqCeU4ubCAvbuZlB0sCAwEAAaOCA3EwggNtMB8GA1Ud
IwQYMBaAFD3TUKXWoK3u80pgCmXTIdT4+NYPMB0GA1UdDgQWBBSgNopaFxWWxDdx
7uYEqwBEHE3qBjAfBgNVHREEGDAWghRhcGktdGxzMTIuc3RyaXBlLmNvbTAOBgNV
HQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMHUGA1Ud
HwRuMGwwNKAyoDCGLmh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9zaGEyLWV2LXNl
cnZlci1nMS5jcmwwNKAyoDCGLmh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9zaGEy
LWV2LXNlcnZlci1nMS5jcmwwSwYDVR0gBEQwQjA3BglghkgBhv1sAgEwKjAoBggr
BgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzAHBgVngQwBATCB
iAYIKwYBBQUHAQEEfDB6MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2Vy
dC5jb20wUgYIKwYBBQUHMAKGRmh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9E
aWdpQ2VydFNIQTJFeHRlbmRlZFZhbGlkYXRpb25TZXJ2ZXJDQS5jcnQwDAYDVR0T
AQH/BAIwADCCAXwGCisGAQQB1nkCBAIEggFsBIIBaAFmAHUApLkJkLQYWBSHuxOi
zGdwCjw1mAT5G9+443fNDsgN3BAAAAFTGy7BXwAABAMARjBEAiBotBE38UhnIZRJ
dflkTux7IfaNV3tzjMgU7evkr1HnBQIgK4B+WjHcN2qLMWIz+Mlnyb63S7c3Ky7u
Hnh2eIYGOB8AdQBo9pj4H2SCvjqM7rkoHUz8cVFdZ5PURNEKZ6y7T0/7xAAAAVMb
LsEtAAAEAwBGMEQCIAWxSulNGsrIz/DP/+OZ+xQY+lVlgr3skLe65rA9ZMuMAiBk
qGwiiwpLmXqI4nbOi6n8oMWu5s4lxppAr6z7e13yvQB2AFYUBpov18Ls0/XhvUSy
PsdGdrm8mRFcwO+UmFXWidDdAAABUxsuwhkAAAQDAEcwRQIgUG+YVHOymEC8FUbo
KPrzcJy4bUZaJmyYMZI8jCItRW4CIQDOfSeVxHBLZNIU7IvOQXbNgEYD/ItMx+vU
qNyR5Ys+qzANBgkqhkiG9w0BAQsFAAOCAQEAxeTeubnXYHz9A1tdcJ/RwoSbdGCp
cmMaLaM0pKctkMvmss3QviyEkVD5J+97kcgrUge71p05DRDys6FGV5iVk31wMjFC
fFaDSvqhkyLojVpJvzi+c1/q6sF1Yx2+OmY0v/HzfmXALTGmVxZrPtRB+8/TQSn7
TkTurErR6sqeQ20H5s2Mf+H04IvnhLwiF9NCTKdhILXMgIhlnThV+cdL1RzBS4wP
8opgs0SV8fbsJFeWY9UdEVut50IChNwTz7OJ/y7lTD8IFv0h9SFjKmBILC2J0Biw
u+2/hFaXJ8uwPV1TE3qAp8rEOII0imMlq0e/mVldvvC1Ld5qRgB0aqJemQ==
-----END CERTIFICATE-----
subject=/businessCategory=Private Organization/jurisdictionC=US/jurisdictionST=Delaware/serialNumber=4675506/street=3180 18th St., Suite 100/postalCode=94110/C=US/ST=California/L=San Francisco/O=Stripe, Inc/CN=api-tls12.stripe.com
issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 Extended Validation Server CA
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3803 bytes and written 434 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES128-GCM-SHA256
Session-ID: 8236D8C0B6DB1D5D5B83AF5F527B6734D93E56DF81E575631755D263E93A4161
Session-ID-ctx:
Master-Key: 63EE1974C8A22E148C831EFAE1154B4DD9B3278D425CBCDFD166BF4F9FE13AC0FD7446D0F4CD6CAE3C9B3E0349115070
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - 7d 03 c0 7f 32 ed bb 8a-be 92 f2 51 64 bb 9a 00 }...2......Qd...
0010 - 5b e4 b0 2b 9c 18 7f 33-67 4d 15 9f 15 c1 fa 76 [..+...3gM.....v
0020 - 03 58 71 e5 70 39 ab f8-6d 4e 6a 67 7a 48 fc b0 .Xq.p9..mNjgzH..
0030 - fe 6d 5c a6 75 10 74 ef-50 cc 1e ce c0 e6 bf f7 .m\.u.t.P.......
0040 - c6 07 50 bb 39 4c 4d 11-d0 1d 69 9b 05 bf e5 38 ..P.9LM...i....8
0050 - f8 54 b9 1e 93 60 b6 3f-bc 98 e6 10 df 4b c6 4b .T...`.?.....K.K
0060 - ae 33 71 08 70 00 69 7f-6a 05 39 86 d1 0a 11 93 .3q.p.i.j.9.....
0070 - df 9e 86 d1 50 49 98 6b-0d a5 43 cf a0 0b 6e 0a ....PI.k..C...n.
0080 - 7e 2e ee d3 be c7 6a 61-09 59 8f 46 19 b9 23 9d ~.....ja.Y.F..#.
0090 - 3f 16 77 59 27 6c 10 45-02 44 84 91 f8 c0 e1 32 ?.wY'l.E.D.....2
00a0 - bc 54 3c d4 90 c0 61 a4-91 f3 68 0e 54 df 52 05 .T<...a...h.T.R.
Start Time: 1481848503
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
read:errno=0
My Python binary was compiled using the openssl in /usr/local/Cellar/openssl/1.0.2j/bin/openssl, so I ran the commands using that:
> /usr/local/Cellar/openssl/1.0.2j/bin/openssl s_client -connect
CONNECTED(00000003)
depth=2 C = US, O = DigiCert Inc, OU =
verify return:1
depth=1 C = US, O = DigiCert Inc, OU =
verify return:1
depth=0 businessCategory = Private Organization, jurisdictionC = US, jurisdictionST = Delaware, serialNumber = 4675506, street = "3180 18th St., Suite 100", postalCode = 94110, C = US, ST = California, L = San Francisco, O = "Stripe, Inc", CN =
verify return:1
---
Certificate chain
0 s:/businessCategory=Private Organization/jurisdictionC=US/jurisdictionST=Delaware/serialNumber=4675506/street=3180 18th St., Suite 100/postalCode=94110/C=US/ST=California/L=San Francisco/O=Stripe, Inc/CN=
i:/C=US/O=DigiCert Inc/OU=
1 s:/C=US/O=DigiCert Inc/OU=
i:/C=US/O=DigiCert Inc/OU=
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIH5TCCBs2gAwIBAgIQCsu/CLRUC4R1bSVCMQGGozANBgkqhkiG9w0BAQsFADB1
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMTQwMgYDVQQDEytEaWdpQ2VydCBTSEEyIEV4dGVuZGVk
IFZhbGlkYXRpb24gU2VydmVyIENBMB4XDTE2MTAxODAwMDAwMFoXDTE3MDIwMTEy
MDAwMFowgf0xHTAbBgNVBA8MFFByaXZhdGUgT3JnYW5pemF0aW9uMRMwEQYLKwYB
BAGCNzwCAQMTAlVTMRkwFwYLKwYBBAGCNzwCAQITCERlbGF3YXJlMRAwDgYDVQQF
Ewc0Njc1NTA2MSEwHwYDVQQJExgzMTgwIDE4dGggU3QuLCBTdWl0ZSAxMDAxDjAM
BgNVBBETBTk0MTEwMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEW
MBQGA1UEBxMNU2FuIEZyYW5jaXNjbzEUMBIGA1UEChMLU3RyaXBlLCBJbmMxFzAV
BgNVBAMTDmFwaS5zdHJpcGUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAu3dfD3fhdFPKph4MC9tngAdqENPjeL0hiVepHjhDXyUTJcpp3fePdP8+
TuCxs9dOAdiRr8W89B+B+UJ04+ayBuYBkuLaaU0l5vft89n0qOiyx2MOp0P9ft4z
16ZleHyQsGF5ZN5iH6sFitkeZRrbksh9aP1ftLm6fAzEIp+ZNpzXcQYL/JmOuZ2a
EctFujhWyceLiJLha1c3fR8L6RfKxFRleTcTXCsGt82OWW0UwDHiJQ+sE36cCHV9
Rt5FlISPVLnI4f6xuaDyeJL6hjSZ7A2RHYppooCvXkxJj1iE1TqWlzEySa8FANuv
LDBIv+5+6iqcTDa6RM+XOGMM9bmVdwIDAQABo4ID5jCCA+IwHwYDVR0jBBgwFoAU
PdNQpdagre7zSmAKZdMh1Pj41g8wHQYDVR0OBBYEFLJtON4LT/9CcVPoXDTkrKAg
l95IMBkGA1UdEQQSMBCCDmFwaS5zdHJpcGUuY29tMA4GA1UdDwEB/wQEAwIFoDAd
BgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwdQYDVR0fBG4wbDA0oDKgMIYu
aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL3NoYTItZXYtc2VydmVyLWcxLmNybDA0
oDKgMIYuaHR0cDovL2NybDQuZGlnaWNlcnQuY29tL3NoYTItZXYtc2VydmVyLWcx
LmNybDBLBgNVHSAERDBCMDcGCWCGSAGG/WwCATAqMCgGCCsGAQUFBwIBFhxodHRw
czovL3d3dy5kaWdpY2VydC5jb20vQ1BTMAcGBWeBDAEBMIGIBggrBgEFBQcBAQR8
MHowJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBSBggrBgEF
BQcwAoZGaHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkV4
dGVuZGVkVmFsaWRhdGlvblNlcnZlckNBLmNydDAMBgNVHRMBAf8EAjAAMIIB9wYK
KwYBBAHWeQIEAgSCAecEggHjAeEAdgCkuQmQtBhYFIe7E6LMZ3AKPDWYBPkb37jj
d80OyA3cEAAAAVfVJDNdAAAEAwBHMEUCIQDKRzFEzmGN3PQy6nxSWTjYNarFPAds
d2Xe2nK9fjTH2gIgIrSDCRzRbnGyfgUG4HYWOmZZJc8tOL/zynW7P8VevPEAdwBo
9pj4H2SCvjqM7rkoHUz8cVFdZ5PURNEKZ6y7T0/7xAAAAVfVJDMkAAAEAwBIMEYC
IQDXK0oAnyH0U2F7cyF9ENE5bHSTXATwvhj0+aOXP7twpgIhAOlb4HpA3EtKx36O
OryUfBt4s6RiWKRX6HMwuGJ6ALVsAHYAVhQGmi/XwuzT9eG9RLI+x0Z2ubyZEVzA
75SYVdaJ0N0AAAFX1SQzhQAABAMARzBFAiAEcE1oaN/iQnYpcA6mQ4zxuC0kww4p
X8fbenq0e3E09gIhAK5RmOd/IoHiERQJMoHkO9StDPJA0CwPhq4b6o8aIZccAHYA
7ku9t3XOYLrhQmkfq+GeZqMPfl+wctiDAMR7iXqo/csAAAFX1SQ10wAABAMARzBF
AiAveGpJBHssOLWWZnnhmk3qrS93Ye9Q5I6Vspu2sfuX6gIhAK+KxpKYbPkKgHVe
8T8qG82Rui61V94lwLA8rk9WbtOeMA0GCSqGSIb3DQEBCwUAA4IBAQCD/RZ0OP1Q
ldbF5ndg5Lsyi4mu0Gp2Y7j5L0ARqgRELjbrIFmv4xg8iCjcpP1eWzIpSl4qTaZz
W6BgqtNxW/u8ZjnWD8jqjF5lujfqLEKaMqxs50/BArfIYfKIbGu6nlpEXWgN+SBN
+cmTCMY5STnL9DgdZip9Zxm12RrLVp9wqav4LHjFRwQXFpYotv8QX/1jXI+6PSD6
fyW1rjgDLDMntFI7+f+RYQqhMv9/pzEALfG/XSfhDegX87ijy88B2BxgciuKnRP7
0arDzV2QerwRaoX6SYiijT02x/EuobEFFJ0xsvla5U9RZrggqU7LJBgdLCcYiYSV
h9VehVGVwYTQ
-----END CERTIFICATE-----
subject=/businessCategory=Private Organization/jurisdictionC=US/jurisdictionST=Delaware/serialNumber=4675506/street=3180 18th St., Suite 100/postalCode=94110/C=US/ST=California/L=San Francisco/O=Stripe, Inc/CN=
issuer=/C=US/O=DigiCert Inc/OU=
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3913 bytes and written 434 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES128-GCM-SHA256
Session-ID: EA798657F4EB6E3A77D99FAEDCF1EB9DB827AB99A987AA61637E64907172A842
Session-ID-ctx:
Master-Key: 29797E1AAFACC262CC7172308B75F278CE48B67D200D977DF7E72E4D63994866CB2674ACF182306A88A2AECD43C2CBA9
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - 1b 48 e5 77 41 ff 94 f2-76 1c 39 b5 9e 03 c3 c6 .H.wA...v.9.....
0010 - 3e 8b 60 95 ef e1 1f 11-f4 fb 48 6a c5 36 3e 5a >.`.......Hj.6>Z
0020 - 10 7a c3 dc 35 be 27 2c-ad 54 d9 29 1f af 84 b8 .z..5.',.T.)....
0030 - 53 ba 65 df ea d4 65 b0-b4 59 13 38 63 95 5e ec S.e...e..Y.8c.^.
0040 - 4c b5 a8 e6 c8 87 9f a3-be 7d 4e 36 f3 0d d6 b6 L........}N6....
0050 - 03 2c 55 54 95 09 6e ad-14 3f 84 aa 0d 4d d0 ea .,UT..n..?...M..
0060 - 3b a5 57 07 04 a8 82 6f-99 f4 8d 78 c0 7a a3 5d ;.W....o...x.z.]
0070 - 12 ef 5e c5 00 7b 0a 6e-19 3e cc a6 36 7e af 77 ..^..{.n.>..6~.w
0080 - 45 39 5c 19 a8 d9 4c 2a-d3 67 70 50 5a 05 42 37 E9\...L*.gpPZ.B7
0090 - 83 f1 f5 9b 4c 4e 3d 94-93 c9 cd 52 12 ed 2e e9 ....LN=....R....
00a0 - c4 7a a8 52 b9 7c a6 2a-31 3e 1b 55 58 8a 5a d0 .z.R.|.*1>.UX.Z.
Start Time: 1481848401
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
read:errno=0
==========================================
> /usr/local/Cellar/openssl/1.0.2j/bin/openssl s_client -connect
CONNECTED(00000003)
depth=2 C = US, O = DigiCert Inc, OU =
verify return:1
depth=1 C = US, O = DigiCert Inc, OU =
verify return:1
depth=0 businessCategory = Private Organization, jurisdictionC = US, jurisdictionST = Delaware, serialNumber = 4675506, street = "3180 18th St., Suite 100", postalCode = 94110, C = US, ST = California, L = San Francisco, O = "Stripe, Inc", CN =
verify return:1
---
Certificate chain
0 s:/businessCategory=Private Organization/jurisdictionC=US/jurisdictionST=Delaware/serialNumber=4675506/street=3180 18th St., Suite 100/postalCode=94110/C=US/ST=California/L=San Francisco/O=Stripe, Inc/CN=
i:/C=US/O=DigiCert Inc/OU=
1 s:/C=US/O=DigiCert Inc/OU=
i:/C=US/O=DigiCert Inc/OU=
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIHdzCCBl+gAwIBAgIQCkZJVSvxH4uYYPHvS7Ly5jANBgkqhkiG9w0BAQsFADB1
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMTQwMgYDVQQDEytEaWdpQ2VydCBTSEEyIEV4dGVuZGVk
IFZhbGlkYXRpb24gU2VydmVyIENBMB4XDTE2MDIyNjAwMDAwMFoXDTE3MDQxMjEy
MDAwMFowggEDMR0wGwYDVQQPDBRQcml2YXRlIE9yZ2FuaXphdGlvbjETMBEGCysG
AQQBgjc8AgEDEwJVUzEZMBcGCysGAQQBgjc8AgECEwhEZWxhd2FyZTEQMA4GA1UE
BRMHNDY3NTUwNjEhMB8GA1UECRMYMzE4MCAxOHRoIFN0LiwgU3VpdGUgMTAwMQ4w
DAYDVQQREwU5NDExMDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWEx
FjAUBgNVBAcTDVNhbiBGcmFuY2lzY28xFDASBgNVBAoTC1N0cmlwZSwgSW5jMR0w
GwYDVQQDExRhcGktdGxzMTIuc3RyaXBlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQAD
ggEPADCCAQoCggEBALfZXJ9CP/bNBbXUDy/toPCwc+wHRy0o6hghYuqoP55bCuAj
viMrykfcIqgKcTu/NQ6miTY+UwFhjRRVec6SPMnjNGTCZF65akUCQcEhAhxbOOGr
AA7wbttDBfeoom8PYPJq83CBO0NVmsgIn9WZKbtEiHurjxp9Cgm3Kf8Q7NpCnF43
IADvBo++3wYKJXZ3U4zDdivBmW8laxfC4M+t1IROCsH5O5E+uMLlBAk6fzb9MCvx
u2jP/Q4fZ7tJE9jh9P6LRB0MDTvRXTkAd1ioBRuqPY3yAuU7rWyU5hFq5BQrr59i
Xi7jcaa6jb5mFnHbZfTyxzqCeU4ubCAvbuZlB0sCAwEAAaOCA3EwggNtMB8GA1Ud
IwQYMBaAFD3TUKXWoK3u80pgCmXTIdT4+NYPMB0GA1UdDgQWBBSgNopaFxWWxDdx
7uYEqwBEHE3qBjAfBgNVHREEGDAWghRhcGktdGxzMTIuc3RyaXBlLmNvbTAOBgNV
HQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMHUGA1Ud
HwRuMGwwNKAyoDCGLmh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9zaGEyLWV2LXNl
cnZlci1nMS5jcmwwNKAyoDCGLmh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9zaGEy
LWV2LXNlcnZlci1nMS5jcmwwSwYDVR0gBEQwQjA3BglghkgBhv1sAgEwKjAoBggr
BgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzAHBgVngQwBATCB
iAYIKwYBBQUHAQEEfDB6MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2Vy
dC5jb20wUgYIKwYBBQUHMAKGRmh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9E
aWdpQ2VydFNIQTJFeHRlbmRlZFZhbGlkYXRpb25TZXJ2ZXJDQS5jcnQwDAYDVR0T
AQH/BAIwADCCAXwGCisGAQQB1nkCBAIEggFsBIIBaAFmAHUApLkJkLQYWBSHuxOi
zGdwCjw1mAT5G9+443fNDsgN3BAAAAFTGy7BXwAABAMARjBEAiBotBE38UhnIZRJ
dflkTux7IfaNV3tzjMgU7evkr1HnBQIgK4B+WjHcN2qLMWIz+Mlnyb63S7c3Ky7u
Hnh2eIYGOB8AdQBo9pj4H2SCvjqM7rkoHUz8cVFdZ5PURNEKZ6y7T0/7xAAAAVMb
LsEtAAAEAwBGMEQCIAWxSulNGsrIz/DP/+OZ+xQY+lVlgr3skLe65rA9ZMuMAiBk
qGwiiwpLmXqI4nbOi6n8oMWu5s4lxppAr6z7e13yvQB2AFYUBpov18Ls0/XhvUSy
PsdGdrm8mRFcwO+UmFXWidDdAAABUxsuwhkAAAQDAEcwRQIgUG+YVHOymEC8FUbo
KPrzcJy4bUZaJmyYMZI8jCItRW4CIQDOfSeVxHBLZNIU7IvOQXbNgEYD/ItMx+vU
qNyR5Ys+qzANBgkqhkiG9w0BAQsFAAOCAQEAxeTeubnXYHz9A1tdcJ/RwoSbdGCp
cmMaLaM0pKctkMvmss3QviyEkVD5J+97kcgrUge71p05DRDys6FGV5iVk31wMjFC
fFaDSvqhkyLojVpJvzi+c1/q6sF1Yx2+OmY0v/HzfmXALTGmVxZrPtRB+8/TQSn7
TkTurErR6sqeQ20H5s2Mf+H04IvnhLwiF9NCTKdhILXMgIhlnThV+cdL1RzBS4wP
8opgs0SV8fbsJFeWY9UdEVut50IChNwTz7OJ/y7lTD8IFv0h9SFjKmBILC2J0Biw
u+2/hFaXJ8uwPV1TE3qAp8rEOII0imMlq0e/mVldvvC1Ld5qRgB0aqJemQ==
-----END CERTIFICATE-----
subject=/businessCategory=Private Organization/jurisdictionC=US/jurisdictionST=Delaware/serialNumber=4675506/street=3180 18th St., Suite 100/postalCode=94110/C=US/ST=California/L=San Francisco/O=Stripe, Inc/CN=
issuer=/C=US/O=DigiCert Inc/OU=
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3803 bytes and written 434 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES128-GCM-SHA256
Session-ID: 8236D8C0B6DB1D5D5B83AF5F527B6734D93E56DF81E575631755D263E93A4161
Session-ID-ctx:
Master-Key: 63EE1974C8A22E148C831EFAE1154B4DD9B3278D425CBCDFD166BF4F9FE13AC0FD7446D0F4CD6CAE3C9B3E0349115070
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - 7d 03 c0 7f 32 ed bb 8a-be 92 f2 51 64 bb 9a 00 }...2......Qd...
0010 - 5b e4 b0 2b 9c 18 7f 33-67 4d 15 9f 15 c1 fa 76 [..+...3gM.....v
0020 - 03 58 71 e5 70 39 ab f8-6d 4e 6a 67 7a 48 fc b0 .Xq.p9..mNjgzH..
0030 - fe 6d 5c a6 75 10 74 ef-50 cc 1e ce c0 e6 bf f7 .m\.u.t.P.......
0040 - c6 07 50 bb 39 4c 4d 11-d0 1d 69 9b 05 bf e5 38 ..P.9LM...i....8
0050 - f8 54 b9 1e 93 60 b6 3f-bc 98 e6 10 df 4b c6 4b .T...`.?.....K.K
0060 - ae 33 71 08 70 00 69 7f-6a 05 39 86 d1 0a 11 93 .3q.p.i.j.9.....
0070 - df 9e 86 d1 50 49 98 6b-0d a5 43 cf a0 0b 6e 0a ....PI.k..C...n.
0080 - 7e 2e ee d3 be c7 6a 61-09 59 8f 46 19 b9 23 9d ~.....ja.Y.F..#.
0090 - 3f 16 77 59 27 6c 10 45-02 44 84 91 f8 c0 e1 32 ?.wY'l.E.D.....2
00a0 - bc 54 3c d4 90 c0 61 a4-91 f3 68 0e 54 df 52 05 .T<...a...h.T.R.
Start Time: 1481848503
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
read:errno=0
ng...@google.com
Thanks for this helping information and your continued patience.
The above results from running `openssl s_client -connect api.stripe.com:443` and `openssl s_client -connect api-tls12.stripe.com:443` suggest that there are no issues with your SSL installation when communicating with Stripe. Thus, we are left with two options. One of Python or dev_appserver.py is not using your OpenSSL installation that succeeded.
1. We can rule out Python by testing a request purely in Python. Consider the following which you've already tested in the dev environment:
#!/usr/bin/env python
import requests
requests.request(
'get',
'https://api-tls12.stripe.com/v1/charges ',
headers={'User-Agent': 'Stripe/v1 PythonBindings/1.27.1', 'X-Stripe-Client-User-Agent': '{"lang_version": "2.7.12", "httplib": "requests", "lang": "python", "bindings_version": "1.27.1", "publisher": "stripe", "platform": "!! [Errno 13] file not accessible: \'/usr/local/opt/python/bin/python2.7\'", "uname": "Linux "}', 'Authorization': 'Bearer sk_test_BQokikJOvBiI2HlWgH4olfQ2'},
data=None,
timeout=55
)
Testing the above in pure Python (not with dev_appserver.py) should in theory succeed if Python is properly using the OpenSSL installation with which you compiled it. Success here is if this properly completes the handshake.
2. If TLS 1.2 with Stripe was successful using the pute Python example above with the 'requests' library, we should now consider that dev_appserver.py and more precisely, the urlfetch stub shipped with it is contributing to this SSL error.
Looking into the urlfetch_stub.py found in the gcloud SDK installation[0] on line 129 in the case of version 139.0.0, we can see that the URLFetch stub uses its own CA cert bundle called urlfetch_cacerts.txt[1]. I believe the urlfetch library uses this trust store to negotiate SSL connections.
I would recommend appending Stripe's python CA certificates[2] to this urlfetch_cacerts.txt file and trying again but using the urlfetch library in dev_appserver.py as you've done already.
from google.appengine.api import urlfetch
urlfetch.fetch(
url='https://api-tls12.stripe.com/v1/charges ',
method='get',
headers={'X-Stripe-Client-User-Agent': '{"uname": "Linux ", "publisher": "stripe", "httplib": "urlfetch", "lang_version": "2.7.12", "platform": "!! [Errno 13] file not accessible: \'/usr/local/opt/python/bin/python2.7\'", "bindings_version": "1.27.1", "lang": "python"}', 'User-Agent': 'Stripe/v1 PythonBindings/1.27.1', 'Authorization': 'Bearer sk_test_BQokikJOvBiI2HlWgH4olfQ2'},
validate_certificate=True,
deadline=55,
payload=None
)
3. I recommend using the 'urlfetch' library instead of 'requests' in dev_appserver.py as they seem to behave differently in development than they do in production. In production, the 'requests' library is using the urlfetch service behind the scenes meaning it should work effectively just like the 'urlfetch' library. In development however, it seems the 'requests' library connects directly to a socket[3] for which I believe dev_appserver.py will return a Permission Denied error since the production environment won't grant you direct socket access. For this reason, I suggest testing with the 'urlfetch' library.
Please test both recommendations 1 and 2. Let us know if including Stripe CA certificates in urlfetch's trust store helps with testing Stripe API calls with TLS 1.2.
[0]: {GCLOUD_SDK_PATH}/platform/google_appengine/google/appengine/api/urlfetch_stub.py
[1]: {GCLOUD_SDK_PATH}/platform/google_appengine/lib/cacerts/urlfetch_cacerts.txt
[2]:https://github.com/stripe/stripe-python/blob/master/stripe/data/ca-certificates.crt
[3]:https://github.com/kennethreitz/requests/blob/master/requests/adapters.py#L473
The above results from running `openssl s_client -connect api.stripe.com:443` and `openssl s_client -connect api-tls12.stripe.com:443` suggest that there are no issues with your SSL installation when communicating with Stripe. Thus, we are left with two options. One of Python or dev_appserver.py is not using your OpenSSL installation that succeeded.
1. We can rule out Python by testing a request purely in Python. Consider the following which you've already tested in the dev environment:
#!/usr/bin/env python
import requests
requests.request(
'get',
'
headers={'User-Agent': 'Stripe/v1 PythonBindings/1.27.1', 'X-Stripe-Client-User-Agent': '{"lang_version": "2.7.12", "httplib": "requests", "lang": "python", "bindings_version": "1.27.1", "publisher": "stripe", "platform": "!! [Errno 13] file not accessible: \'/usr/local/opt/python/bin/python2.7\'", "uname": "Linux "}', 'Authorization': 'Bearer sk_test_BQokikJOvBiI2HlWgH4olfQ2'},
data=None,
timeout=55
)
Testing the above in pure Python (not with dev_appserver.py) should in theory succeed if Python is properly using the OpenSSL installation with which you compiled it. Success here is if this properly completes the handshake.
2. If TLS 1.2 with Stripe was successful using the pute Python example above with the 'requests' library, we should now consider that dev_appserver.py and more precisely, the urlfetch stub shipped with it is contributing to this SSL error.
Looking into the urlfetch_stub.py found in the gcloud SDK installation[0] on line 129 in the case of version 139.0.0, we can see that the URLFetch stub uses its own CA cert bundle called urlfetch_cacerts.txt[1]. I believe the urlfetch library uses this trust store to negotiate SSL connections.
I would recommend appending Stripe's python CA certificates[2] to this urlfetch_cacerts.txt file and trying again but using the urlfetch library in dev_appserver.py as you've done already.
from google.appengine.api import urlfetch
urlfetch.fetch(
url='
method='get',
headers={'X-Stripe-Client-User-Agent': '{"uname": "Linux ", "publisher": "stripe", "httplib": "urlfetch", "lang_version": "2.7.12", "platform": "!! [Errno 13] file not accessible: \'/usr/local/opt/python/bin/python2.7\'", "bindings_version": "1.27.1", "lang": "python"}', 'User-Agent': 'Stripe/v1 PythonBindings/1.27.1', 'Authorization': 'Bearer sk_test_BQokikJOvBiI2HlWgH4olfQ2'},
validate_certificate=True,
deadline=55,
payload=None
)
3. I recommend using the 'urlfetch' library instead of 'requests' in dev_appserver.py as they seem to behave differently in development than they do in production. In production, the 'requests' library is using the urlfetch service behind the scenes meaning it should work effectively just like the 'urlfetch' library. In development however, it seems the 'requests' library connects directly to a socket[3] for which I believe dev_appserver.py will return a Permission Denied error since the production environment won't grant you direct socket access. For this reason, I suggest testing with the 'urlfetch' library.
Please test both recommendations 1 and 2. Let us know if including Stripe CA certificates in urlfetch's trust store helps with testing Stripe API calls with TLS 1.2.
[0]: {GCLOUD_SDK_PATH}/platform/google_appengine/google/appengine/api/urlfetch_stub.py
[1]: {GCLOUD_SDK_PATH}/platform/google_appengine/lib/cacerts/urlfetch_cacerts.txt
[2]:
[3]:
pr...@gmail.com
For me, this issue has resolved itself at some point in the last month. I'm not sure if it was a change on Stripe's end or a gcloud update.
ng...@google.com
Given that I cannot test the solutions above myself (not having a Stripe API account nor the proper development environment to reproduce) and this seems to no longer affect you, I don't think there's enough data to confirm a cause and effect. As such, I'm closing this issue as Resovled instead of Fixed.
Nevertheless, if this is still an issue with some individuals in the community after having try the various solutions proposed here[0][1][2], please file a new defect report linking back to this one for context. Be sure to include the following:
* Your system's OpenSSL version
* The version of OpenSSL used by dev_appserver.py in your installation
* The SSL error you face communicating to both 'api-tls12.stripe.com ' and 'api.stripe.com '
* The solutions from this thread you've tried
We'll be happy to investigate it further at that time.
[0]:https://code.google.com/p/googleappengine/issues/detail?id=13207#c9
[1]:https://code.google.com/p/googleappengine/issues/detail?id=13207#c11
[2]:https://code.google.com/p/googleappengine/issues/detail?id=13207#c36
Nevertheless, if this is still an issue with some individuals in the community after having try the various solutions proposed here[0][1][2], please file a new defect report linking back to this one for context. Be sure to include the following:
* Your system's OpenSSL version
* The version of OpenSSL used by dev_appserver.py in your installation
* The SSL error you face communicating to both '
* The solutions from this thread you've tried
We'll be happy to investigate it further at that time.
[0]:
[1]:
[2]:
Description
Note: Complete Stripe testing isn't possible on the dev server anyway because of web hooks, but it would be nice if we could still do most of our testing without deploying to a live server.