This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ned.deily
Recipients christian.heimes, jaraco, ned.deily
Date 2016-09-15.05:34:20
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1473917661.46.0.705112842759.issue28150@psf.upfronthosting.co.za>
In-reply-to
Content
Sorry, the information about this feature is currently only documented in the OS X installer ReadMe.  As you noted, it's displayed to the user during installation when using the OS X installer app.  A copy of the ReadMe is also installed for later reference in the directory /Applications/Python 3.6/.

Here's what it says about this feature:

========
Certificate verification and OpenSSL
------------------------------------

**NEW** This variant of Python 3.6 now includes its own private copy of OpenSSL 1.0.2.  Unlike previous releases, the deprecated Apple-supplied OpenSSL libraries are no longer used.  This also means that the trust certificates in system and user keychains managed by the Keychain Access application and the security command line utility are no longer used as defaults by the Python ssl module.  For 3.6.0b1, a sample command script is included in /Applications/Python 3.6 to install a curated bundle of default root certificates from the third-party certifi package (https://pypi.python.org/pypi/certifi).  If you choose to use certifi, you should consider subscribing to the project's email update service to be notified when the certificate bundle is updated.

The bundled pip included with the Python 3.6 installer has its own default certificate store for verifying download connections.
========

So the feature does *not* require 'certifi' to be installed.  As currently implemented, the supplied private copy of the OpenSSL libs is configured with its own private openssl directory for root certificates, as root certificates in macOS / OS X are stored in system and user keychains, not in an OpenSSL-compatible file or directory.  The path to the Python-installed directory is accessible via the attributes of ssl.get_default_verify_paths().  As installed, the Python-installed directory is empty.  So, to supply default root certificates, you need to either copy a certificate bundle or directory to the directory or provide a symlink to a certificate bundle or directory installed elsewhere.  In 360b1 as noted in the ReadMe, there is a simple double-clickable or command-line-runnable script ("/Applications/Python 3.6/Install Certificates.command") that does two things: 1. uses pip to install certifi and 2. creates a symlink in the OpenSSL directory to certifi's installed bundle location. Without the second step, installing certifi manually won't work, as you discovered.  Running the script as described in the ReadMe will solve your problem.  Of course, anyone can supply their own certificates as with any version of OpenSSL.

Granted, the 360b1 ReadMe could be more detailed.  For 360b2, I intend to expand the script to cover some other options and expand the documentation as part of Issue17128.  What's in 360b1 is not all that pretty but it seemed to me to be the least bad of the various practical options, including continuing to use the old, deprecated system OpenSSL libraries.
History
Date User Action Args
2016-09-15 05:34:21ned.deilysetrecipients: + ned.deily, jaraco, christian.heimes
2016-09-15 05:34:21ned.deilysetmessageid: <1473917661.46.0.705112842759.issue28150@psf.upfronthosting.co.za>
2016-09-15 05:34:21ned.deilylinkissue28150 messages
2016-09-15 05:34:20ned.deilycreate