[Python-Dev] SSL certificates recommendations for downstream python packagers

[Christian Heimes]

On 2017-01-31 10:19, Cory Benfield wrote:
> 
>> On 30 Jan 2017, at 21:00, David Cournapeau <cournape at gmail.com
>> <mailto:cournape at gmail.com>> wrote:
>>
>>
>>
>> On Mon, Jan 30, 2017 at 8:50 PM, Cory Benfield <cory at lukasa.co.uk
>> <mailto:cory at lukasa.co.uk>> wrote:
>>
>>
>>
>>     > On 30 Jan 2017, at 13:53, David Cournapeau <cournape at gmail.com <mailto:cournape at 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.