SSL: CERTIFICATE_VERIFY_FAILED when trying to push to pypi on Python 3.6 (3.5 works).

[rec]

Summary: starting on July 8, I've been unable to push new packages to pypi with Python 3.6.

I can push to pypitest with 3.6, and I can push to pypi with Python 3.5 (as I just found out).

See the attached error file named pypi-version-errors.txt. See also.

Summary:

version    pypi   pypitest
  3.4(*)    no     yes
  3.5       yes    (didn't test)
  3.6       no     yes

(* - 3.4 works for pypitest only - if you change your .pypirc to include the legacy URL.)

I'm on MacOS 10.9.5. All of these Pythons are vanilla executables with no new packages installed (I use virtualenv for all installations.)

Here's my .pypirc

[distutils]
index-servers =
  pypi
  pypitest

[pypi]
username=TomSwirly
password=[omitted]

[pypitest]
username=TomSwirly
password=[omitted]

[ncoghlan]

@rec Are other services (e.g. browser, curl, wget) able to reach https://upload.pypi.org/ without a certificate error?

The other key question would be what you get when looking up PyPI's DNS info. I get:

$ dig upload.pypi.org

; <<>> DiG 9.11.1-P2-RedHat-9.11.1-2.P2.fc26 <<>> upload.pypi.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2149
;; flags: qr rd ra; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;upload.pypi.org.               IN      A

;; ANSWER SECTION:
upload.pypi.org.        86358   IN      CNAME   upload.pypi.org.herokudns.com.
upload.pypi.org.herokudns.com. 18 IN    A       50.17.240.35
upload.pypi.org.herokudns.com. 18 IN    A       54.225.221.60
upload.pypi.org.herokudns.com. 18 IN    A       50.17.187.125
upload.pypi.org.herokudns.com. 18 IN    A       23.23.159.159
upload.pypi.org.herokudns.com. 18 IN    A       50.16.192.69
upload.pypi.org.herokudns.com. 18 IN    A       23.23.228.46
upload.pypi.org.herokudns.com. 18 IN    A       23.23.160.170
upload.pypi.org.herokudns.com. 18 IN    A       50.16.231.196

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Jul 11 22:31:03 AEST 2017
;; MSG SIZE  rcvd: 215

[rec]

Just want to reassure you that I am no longer blocked by this issue - since Python 3.5 worked fine for me. But the 3.6 weirdness was such that I figured it was sufficiently specific that you'd want to know about this issue!

curl https://upload.pypi.org/ works fine and gives me the endpoint page, as does the browser.

But I get a rather different response from dig.

; <<>> DiG 9.8.3-P1 <<>> upload.pypi.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3003
;; flags: qr rd ra; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;upload.pypi.org.       IN  A

;; ANSWER SECTION:
upload.pypi.org.    79523   IN  CNAME   upload.pypi.org.herokudns.com.
upload.pypi.org.herokudns.com. 60 IN    A   54.243.219.148
upload.pypi.org.herokudns.com. 60 IN    A   54.243.246.56
upload.pypi.org.herokudns.com. 60 IN    A   54.243.197.181
upload.pypi.org.herokudns.com. 60 IN    A   54.225.144.182
upload.pypi.org.herokudns.com. 60 IN    A   54.235.100.132
upload.pypi.org.herokudns.com. 60 IN    A   54.243.213.168
upload.pypi.org.herokudns.com. 60 IN    A   54.243.225.13
upload.pypi.org.herokudns.com. 60 IN    A   54.227.244.176

;; Query time: 20 msec
;; SERVER: 192.168.178.1#53(192.168.178.1)
;; WHEN: Tue Jul 11 15:28:23 2017
;; MSG SIZE  rcvd: 204

I get much the same results using dig @8.8.8.8 upload.pypi.org (which should be using Google's DNS servers).

[ncoghlan]

@dstufft @ewdurbin Any ideas what might be happening in this case?

[ewdurbin]

certificate verification issues such as this could originate from many sources, particularly given that it is reproducible to such an extent.

top contender though would be if the certificate authority that issued the certificate for upload.pypi.org (LetsEncrypt specifically) is not in the Certificate Authority bundle that is being used.

second would be a lack of SNI support, but it doesn't appear to be that on the surface.

it would be very helpful to have some additional information about your environment.

Specific python versions and method of install, for example "Python 3.6.1 installed via Installer from python.org" or "Python 3.5.1 installed via pyenv"

Additionally any packages installed, pip freeze.

That's still no gaurauntee, but is very helpful in these situations.

[dstufft]

It could also be clock skew.

[geduldig]

I have the same issue ("certificate verify failed") when running: python3.6 setup.py sdist upload

I had been running without issue prior: python3.3 setup sdist register upload

Also, I noticed that now the upload is attempting to go to a legacy folder: Submitting dist/TwitterAPI-2.4.6.tar.gz to https://upload.pypi.org/legacy/ <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:749)>

How does one migrate away from the legacy folder to whatever is the current folder?

[rec]

Does 3.5 work for you?

On Sun, Jul 16, 2017 at 6:27 PM, geduldig notifications@github.com wrote:

I have the same issue ("certificate verify failed") when running: python3.6 setup.py sdist upload

I had been running without issue prior: python3.3 setup sdist register upload

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/pypa/packaging-problems/issues/93#issuecomment-315620255, or mute the thread https://github.com/notifications/unsubscribe-auth/AAPdstudZ8a0ZyEG0eZBvDfDjXiTSSWfks5sOjnvgaJpZM4OUHeI .

-- /t

https://tom.ritchford.com https://tom.ritchford.com https://tom.swirly.com https://tom.swirly.com

[geduldig]

Yes, 3.5 worked. It still says submitting to https://upload.pypi.org/legacy/.

[erickpeirson]

https://github.com/pypa/twine

[martinfthomsen]

Had a similar issue. I tried again in a new terminal, and that worked.

[bcb]

My problem was the CURL_CA_BUNDLE env var was set.

unset CURL_CA_BUNDLE

[michjnich]

It could also be clock skew.

A really old issue, but thanks for making that comment, because WSL still has the clock sync issue, and if you're PC has been to sleep while your WSL session is open, the clock will be out of sync, and your pypi upload will fail!

Just thought I'd explicitly comment on this in case anybody else was having the same issue as me and scratching their head about it, entirely forgetting about the WSL clock thing ...