pipenv: CERTIFICATE_VERIFY_FAILED error when installing dependencies
Hi,
I have installed pipenv
for the first time on my system by following the fancy installation method (because I have excellent taste!) and the world was a happy place to live in.
Then I went on running the following given the project I started to work on did not know about the wonders of pipenv
:
pipenv install -r a_folder/requirements.txt
But then, suddenly the world was a sad place to live in. I got the following:
Requirements file provided! Importing into Pipfile…
Pipfile.lock not found, creating…
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
Traceback (most recent call last):
File "/Users/my_user/.local/bin/pipenv", line 11, in <module>
sys.exit(cli())
File "/Users/my_user/.local/venvs/pipenv/lib/python2.7/site-packages/pipenv/vendor/click/core.py", line 722, in __call__
return self.main(*args, **kwargs)
File "/Users/my_user/.local/venvs/pipenv/lib/python2.7/site-packages/pipenv/vendor/click/core.py", line 697, in main
rv = self.invoke(ctx)
File "/Users/my_user/.local/venvs/pipenv/lib/python2.7/site-packages/pipenv/vendor/click/core.py", line 1066, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
File "/Users/my_user/.local/venvs/pipenv/lib/python2.7/site-packages/pipenv/vendor/click/core.py", line 895, in invoke
return ctx.invoke(self.callback, **ctx.params)
File "/Users/my_user/.local/venvs/pipenv/lib/python2.7/site-packages/pipenv/vendor/click/core.py", line 535, in invoke
return callback(*args, **kwargs)
File "/Users/my_user/.local/venvs/pipenv/lib/python2.7/site-packages/pipenv/cli.py", line 1785, in install
do_init(dev=dev, allow_global=system, ignore_pipfile=ignore_pipfile, system=system, skip_lock=skip_lock, verbose=verbose, concurrent=concurrent, deploy=deploy)
File "/Users/my_user/.local/venvs/pipenv/lib/python2.7/site-packages/pipenv/cli.py", line 1293, in do_init
do_lock(system=system)
File "/Users/my_user/.local/venvs/pipenv/lib/python2.7/site-packages/pipenv/cli.py", line 1083, in do_lock
pre=pre
File "/Users/my_user/.local/venvs/pipenv/lib/python2.7/site-packages/pipenv/utils.py", line 450, in resolve_deps
r = requests.get('https://pypi.org/pypi/{0}/json'.format(name))
File "/Users/my_user/.local/venvs/pipenv/lib/python2.7/site-packages/requests/sessions.py", line 521, in get
return self.request('GET', url, **kwargs)
File "/Users/my_user/.local/venvs/pipenv/lib/python2.7/site-packages/requests/sessions.py", line 508, in request
resp = self.send(prep, **send_kwargs)
File "/Users/my_user/.local/venvs/pipenv/lib/python2.7/site-packages/requests/sessions.py", line 618, in send
r = adapter.send(request, **kwargs)
File "/Users/my_user/.local/venvs/pipenv/lib/python2.7/site-packages/requests/adapters.py", line 506, in send
raise SSLError(e, request=request)
requests.exceptions.SSLError: HTTPSConnectionPool(host='pypi.org', port=443): Max retries exceeded with url: /pypi/idna/json (Caused by SSLError(SSLError(1, u'[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:661)'),))
Is this expected?
Here’s some more info which I hope it will be useful:
$ pipenv --venv
/Users/my_user/.local/share/virtualenvs/the_project_folder-kENjJPUz
$ pipenv --version
pipenv, version 8.2.6
$ pipenv run python --version
Python 2.7.14
$ python --version
2.7.10
# My requirements.txt file
boto==2.48.0
fabric==1.14.0
# My automatically-generated Pipenv file
[[source]]
url = "https://pypi.python.org/simple"
verify_ssl = true
name = "pypi"
[dev-packages]
[packages]
boto = "==2.48.0"
fabric = "==1.14.0"
OS is macOS Sierra 10.12.4.
Anything you need to help troubleshoot this just let me know.
Thanks!
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Comments: 15 (7 by maintainers)
@walterdolce No problem! @nateprewitt saves the day! Also thank you so much for using that gif.
@nateprewitt Hmmmm good catch! I am indeed currently behind the company network which has various layers of security a request has to go through.
I just tried this while connected to the mobile hotspot and…
I shall raise this internally to fix. Thanks both @erinxocon @nateprewitt for the speedy responses and help provided!