Thanks for the suggestion but that is not a workable solution for two reasons. One, pip is an optional install with the python.org installer so we cannot depend on it being available.  More importantly, from a packaging point of view, the internal composition of pip is opaque.  There's no guarantee that any future release of pip will still bundle root certificates, that they will be installed in the same location, or which root certificates will be included and how up-to-date they are. Pip uses the certificates primarily to access PyPI, not to provide a general set of root certificates.  The current python.org solution of providing the Install Certificates script as an example is certainly far from ideal and we will improve it.  But adding a dependency on undocumented behavior of pip is not a step in the right direction.