On Mon, Jan 30, 2017 at 9:14 PM, Christian Heimes
On 2017-01-30 22:00, David Cournapeau wrote:
On Mon, Jan 30, 2017 at 8:50 PM, Cory Benfield
mailto:cory@lukasa.co.uk> wrote: > On 30 Jan 2017, at 13:53, David Cournapeau
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 ?
That works with CPython because we get all trust anchors from the cert store. However Python is not able to retrieve *additional* certificates. A new installation of Windows starts off with a minimal set of trust anchors. Chrome, IE and Edge use the proper APIs.
Hm. Is this documented anywhere ? We have customers needing "private/custom" certificates, and I am unsure where to look for. David