On 30 Jan 2017, at 21:00, David Cournapeau <cournape@gmail.com> wrote:



On Mon, Jan 30, 2017 at 8:50 PM, Cory Benfield <cory@lukasa.co.uk> wrote:


> On 30 Jan 2017, at 13:53, David Cournapeau <cournape@gmail.com> wrote:
>
> Are there any official recommendations for downstream packagers beyond PEP 476 ? Is it "acceptable" for downstream packagers to patch python's default cert locations ?

There *are* no default cert locations on Windows or macOS that can be accessed by OpenSSL.

I cannot stress this strongly enough: you cannot provide a platform-native certificate validation logic for Python *and* use OpenSSL for certificate validation on Windows or macOS. (macOS can technically do this when you link against the system OpenSSL, at the cost of using a catastrophically insecure version of OpenSSL.)

Ah, thanks, that's already useful information.

Just making sure I understand: this means there is no way to use python's SSL library to use the system store on windows, in particular private certifications that are often deployed by internal ITs in large orgs ?

If only it were that simple!

No, you absolutely *can* do that. You can extract the trust roots from the system trust store, convert them into PEM/DER-encoded files, and load them into OpenSSL. That will work.

The problem is that both SecureTransport and SChannel have got a number of differences from OpenSSL. In no particular order:

1. Their chain building logic is different. This means that, given a collection of certificates presented by a server and a bundle of already-trusted certs, each implementation may build a different trust chain. This may cause one implementation to refuse to validate where the others do, or vice versa. This is very common with older OpenSSLs.
2. SecureTransport and SChannel both use the system trust DB, which on both Windows and mac allows the setting of custom policies. OpenSSL won’t respect these policies, which means you can fail-open (that is, export and use a root certificate that the OS believes should not be trusted for a given use case). There is no way to export these trust policies into OpenSSL.
3. SecureTransport, SChannel, and OpenSSL all support different X.509 extensions and understand them differently. This means that some certs may be untrusted for certain uses by Windows but trusted for those uses by OpenSSL, for example.

In general, it is unwise to mix trust stores. If you want to use your OS’s trust store, the best approach is to use the OS’s TLS stack as well. At least that way when a user says “It works in my browser”, you know it should work for you too.

Cory