Tell HN: Python 3.6 on OS X requires a post-install step for SSL to work | Hacker News Reader

Tell HN: Python 3.6 on OS X requires a post-install step for SSL to work

2 pointsvosper2 comments

I'm posting this as a PSA, because I just wasted a few hours (should have read the release notes in full) trying to resolve an "SSL: CERTIFICATE_VERIFY_FAILED" exception every time I requested a URL over HTTPS. All my Googling take me to promising-but-irrelevant StackOverflow threads. It turns out that on OSX Python 3.6 no longer uses the systems trusted certificates, so after install it has no certificates at all (except a hardcoded one for pip) and can't validate any SSL connections.

To fix this you need to run a command [0] included in the installer that will download and install the certifi package, which is a collection of trusted certificates. If I understand the release notes correctly you are also now responsible for making sure your certificates are up to date - the release notes recommend subscribing to the mailing list.

Personally, I think this sucks. It makes Python way less friendly to new users, and I don't want to be on the hook for keeping my certificates up-to-date. At the very least, the installer should run the post-install script automatically, so that SSL connections just work.

The ReadMe with more info lives at /Applications/Python\ 3.6/ReadMe.rtf

[0] /Applications/Python\ 3.6/Install\ Certificates.command

Long term one possibility is that Python will defer to your OS (in this case, OS X) to make trust decisions for SSL

https://lwn.net/Articles/711954/

This will involve Python ceasing to use OpenSSL in favour of native SSL APIs (except on the Unix platforms where OpenSSL is the native API).

Right now your Python uses OpenSSL, but nobody at all was responsible for keeping the trust store up-to-date. So, making you responsible was in a sense a step up. Certifi basically bundles the Mozilla NSS trust store, which is also used by the BSDs, Linux distros, Haiku and whatever else isn't Apple or Microsoft. But it won't reflect OS X changes, for better or worse. On the other hand, if that PEP goes ahead and Python trusts the OS X built-in stores, Python code may work on your Mac, but not on some guy's FreeBSD machine, because the different trust stores don't agree about whether to trust a certificate. So, swings and roundabouts.

Thanks for info, that's helpful. It seems especially bad with virtualenv, since you have the possibility that different Python environments on the same computer have different certificate sets, depending on when you created the virtualenv or whether you updated certifi in that environment.

I think the changes should have been a lot more obvious. The OSX installer should have popped up a big box saying "Warning: This version of Python does not have any SSL certificates and will not be able to connect to secure HTTP connections. Without certificates these connections will fail to work. Please click this button to install the 'certifi' package, and read these VERY IMPORTANT notes to understand the implications of this change"

Reply on news.ycombinator.com