homepage

For the certificate store:
Can we eventually agree to bind a default CA-store to a Mozilla verified one?
Mozilla in handling Firefox does a great job in keeping CA-store up-to-date.
Integrating default mozilla CA-store with Python builds could be a nice way, it's just a matter of integrating into the build-system the download/fetching of default Mozilla store.
At least the language base it's default on a trusted entity to manage, cross-platform, the CA-store for TLS/SSL.
The mainteinance of the CA-store would be delegated to Mozilla that has been demonstrated to be independent and very security conscious, removing dirty CA-store (like Diginotar after Iranian compromise).
That way 90% of case of of SSL/TLS certificate validation will be managed and by default it would be possible to enable secure SSL/TLS client checking like described in http://bugs.python.org/issue13647 .

Mozilla CA are available on:
https://www.mozilla.org/projects/security/certs/
The warranty and security process of Mozilla handling of SSL CA root certs is described on:
https://wiki.mozilla.org/CA
I think that Python language could reasonably base it's default root CA on the Mozilla ones that are the most recognized for security and transparency in the world.

I'm not sure Python should be in the business of distributing CA certificates. I think it's better left to the application or Linux distribution.

I propose to change the scope of this request to: ssl module should provide a way to access the OS CA bundle.

Copy of a message by Christian Heimes on a duplicate report:
 
For effective SSL server cert validation a bundle of trustworthy CA certs is required. Most system ship such a bundle but it's not always possible to access the bundle from Python / OpenSSL. Windows and Mac OS X come into my mind. wget and curl ship a copy of Mozilla's CA cert bundle.
The site http://curl.haxx.se/docs/caextract.html explains how to extract the CA certs in PEM format. I suggest that we ship the CA bundle with Python and use a lookup chain:
- user defined path to a cacert directory or cacert.pem file
- cacert directory or PEM file in the user's home directory: 
 cacertdir = os.path.join(site.USER_SITE, os.pardir, "cacert")
 cacertfile = os.path.join(site.USER_SITE, os.pardir, "cacert.pem")
- system's ca cert directory (/etc/ssl/certs on Linux)
- CA cert bundle shipped with the Python installation.

Éric's suggestion is also implemented in python-requests if I remember correctly. It allows for user-specified PEM files and tries to find the operating system bundle. This would be a wonderful inclusion in the standard library.

> Éric's suggestion is also implemented in python-requests if I remember 
> correctly. It allows for user-specified PEM files and tries to find the 
> operating system bundle. This would be a wonderful inclusion in the
> standard library.
Aren't load_verify_locations() and set_default_verify_paths() sufficient?
http://docs.python.org/dev/library/ssl.html#ssl.SSLContext.load_verify_locations 

I think we can improve the situation with shipping our own CA certs. Almost every operating system or distribution comes with a set of CA certs.
I lots of Linux distributions and most BSD systems. All except FreeBSD install CA certs by default. A fresh FreeBSD systems doesn't have certs but ``pkg_add -r ca-root-nss`` fixes that. At least some versions of SuSE don't have a cafile but rather a capath directory. On Windows #17134 and #16487 are going to allow us to use Windows' cert store through crypt32.dll.
Here is a full list:
cert_paths = [
 # Debian, Ubuntu, Arch, SuSE
 # NetBSD (security/mozilla-rootcerts)
 "/etc/ssl/certs/",
 # Debian, Ubuntu, Arch: maintained by update-ca-certificates
 "/etc/ssl/certs/ca-certificates.crt",
 # Red Hat 5+, Fedora, Centos
 "/etc/pki/tls/certs/ca-bundle.crt",
 # Red Hat 4
 "/usr/share/ssl/certs/ca-bundle.crt",
 # FreeBSD (security/ca-root-nss package)
 "/usr/local/share/certs/ca-root-nss.crt",
 # FreeBSD (deprecated security/ca-root package, removed 2008)
 "/usr/local/share/certs/ca-root.crt",
 # FreeBSD (optional symlink)
 # OpenBSD
 "/etc/ssl/cert.pem",
 # Mac OS X
 "/System/Library/OpenSSL/certs/cert.pem",
 ]
I'd like to add the list to our ssl.py and add an API to check and load certs from that files, directories and other places (Windows).

> I think we can improve the situation with shipping our own CA certs.
> Almost every operating system or distribution comes with a set of CA
> certs.
Why would we ship our own CA certs if every OS comes with CA certs?
> I lots of Linux distributions and most BSD systems. All except
> FreeBSD install CA certs by default. A fresh FreeBSD systems doesn't
> have certs but ``pkg_add -r ca-root-nss`` fixes that.
Kudos to FreeBSD.
Anyway, isn't SSLContext.set_default_verify_paths() enough already?
> Here is a full list: [snip full list]
I don't think it's a good idea to maintain a list of hard-coded
paths in Python: it's not manageable, and it will always become
outdated. If there was a widely-respected standard (e.g. in FHS or
LSB), things would be a lot better.

On Jul 08, 2013, at 11:56 AM, Antoine Pitrou wrote:
>I don't think it's a good idea to maintain a list of hard-coded
>paths in Python: it's not manageable, and it will always become
>outdated. If there was a widely-respected standard (e.g. in FHS or
>LSB), things would be a lot better.
I agree. I don't think we should be shipping certs, but if we do, then it
must be possible and easy for e.g. Linux distros to override. Linux distros
are already managing certs through their normal and security updates, so it's
a burden to also have to do so for Python. I think this analogous to shipping
other types of external databases, e.g. timezones, etc.

re: cert_paths = [...]
This approach is rather problematic, there's no guarantee that a path trusted on one system is trusted on another.
I saw this in setuptools branch, where it does:
for path in cert_path:
 if os.path.exists(path)
 return path
Let's say you're user1 on osx and your native true path is "/System/Library/OpenSSL/certs/cert.pem", can you guarantee that someone else, user2, cannot sneak their hacked files into "/etc/pki/" (presumably missing altogether) or "/usr/local/share/"?
Because if user2 can do that, suddenly user1 verifies all traffic against hacked ca list.

All these paths are on directories that are supposed to be read-only for untrusted users. You can't protect yourself against a malicious admin anyway. For Python 3.4 the ssl module uses the cert path that are configured with OpenSSL. The paths and configuration are outside our control.

I don't think we're planning to distribute our own store of certs.