search

braintree / braintree_python

Braintree Python library
https://developer.paypal.com/braintree/docs/start/overview
MIT License
241 stars 155 forks source link

Respect the requests_ca_bundle environment variable #129

Closed jords1987 closed 3 years ago

jords1987 commented 3 years ago

General information

Issue description

The braintree SDK looks like it does not respect the requests_ca_bundle environment variable this allows for custom CA certs to be used in SSL Verification, particularly helpful when developing behind a corporate or intermediate proxy that uses ssl inspection and re-signing

I'm not 100% but I think because this is set to a string for sandbox env: https://github.com/braintree/braintree_python/blob/eb7d6e60b5357bbf8d2f7ff284fffe08d510ca76/braintree/util/http.py#L114

then only the CA's in the package at \ssl\api_braintreegateway_com.ca.crt are being used and therefore when another service is signing the traffic this is failing. I believe by setting it to "true" it will allow the requests_ca_bundle to be respected.

Another way would be to somehow allow override of the cert path in the configuration object possibly?

I can work around this issue by adding my proxy's CA into the file mentioned above and also have the option to turn off SSL inspection, however since this is not a problem on the c# braintree SDK I guess it could be tackled here.

Thanks

hollabaq86 commented 3 years ago

👋 @jords1987, thanks for reaching out. We're not comfortable allowing configurations to our ssl certificates, so we're going to pass on updating the SDK to allow a different path. Since you've identified a workaround for this particular issue, our recommendation is to go forward with that option.

jords1987 commented 3 years ago

@hollabaq86 Thanks, I can continue with the workaround

I suppose what makes me think this is a problem with this SDK is that other language versions of the braintree SDK are not suffering with this issue (.Net SDK for example) as they respect the environments SSL verification setup.

Should we be forcing people that develop behind a proxy to implement undocumented workarounds just because of their choice in language? the alternative to my workaround is just not to use the python SDK and roll your own http requests or use .net... Which isn't great for anybody IMO