On 2017-01-31 10:19, Cory Benfield wrote:
On 30 Jan 2017, at 21:00, David Cournapeau <cournape@gmail.com <mailto:cournape@gmail.com>> wrote:
On Mon, Jan 30, 2017 at 8:50 PM, Cory Benfield <cory@lukasa.co.uk <mailto:cory@lukasa.co.uk>> wrote:
> On 30 Jan 2017, at 13:53, David Cournapeau <cournape@gmail.com <mailto: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.
One small correction, it is possible to export some of the trust settings to a TRUSTED CERTIFICATE and import them into OpenSSL. It works correctly in 1.0.1 and since 1.0.2e or f. Trust settings are stored in X509_AUX extension after the actual certificate and signature. OpenSSL's default loaders for cert dir and cert file do load auxiliary trust information. (Of course the feature is experimental and was broken in 1.0.2 for a long time until I discovered the issue and fixed it...) https://linux.die.net/man/1/x509 TRUST SETTINGS Please note these options are currently experimental and may well change. A trusted certificate is an ordinary certificate which has several additional pieces of information attached to it such as the permitted and prohibited uses of the certificate and an "alias". Normally when a certificate is being verified at least one certificate must be "trusted". By default a trusted certificate must be stored locally and must be a root CA: any certificate chain ending in this CA is then usable for any purpose. Trust settings currently are only used with a root CA . They allow a finer control over the purposes the root CA can be used for. For example a CA may be trusted for SSL client but not SSL server use.