Closed mnaglee closed 8 years ago
Creating a ~/.pyrax.cfg
file with contents below solved this for me:
[default]
verify_ssl = False
That is not a solution to the problem -- that sends your credentials and all other data in clear text without any sort of encryption. You probably do not want to do thatl.
I'm not sure what django-cumulus is doing, but pyrax.set_credentials(self.username, self.api_key)
does not generally encounter this error.
Oh fuck, thanks for the suggestion. Time to dig deeper. Blah.
Looking at the traceback it's all pyrax and requests code that triggers this condition.
After some reading it's suggested to upgrade Python to 2.7.9 or newer, I'm using:
$ python -c 'import ssl; print(ssl.OPENSSL_VERSION)'
OpenSSL 1.0.1f 6 Jan 2014
$ python --version
Python 2.7.6
upgraded to 2.7.10 just now but same error :-/
@mnaglee what versions are you using?
Looks like certifi is the issue. I'm on Ubuntu 14.04 LTS as well and can't upgrade openssl easily. This comment describes the same issue and suggests uninstalling the certifi package. And bang, no more issues. Does this work for you @mnaglee?
@thijstriemstra: Ahh, good find. Rather than remove certifi completely, I've pinned it at the previous version as suggested in some of the comments in that thread. This did it for me:
pip uninstall -y certifi && sudo pip install certifi==2015.04.28
Thanks, even better!
Worth noting: making this change adds the following warning to django startup:
.../site-packages/requests/packages/urllib3/connection.py:266: SubjectAltNameWarning: Certificate for identity.api.rackspacecloud.com has no
subjectAltName, falling back to check for a
commonNamefor now. This feature is being removed by major browsers and deprecated by RFC 2818. (See https://github.com/shazow/urllib3/issues/497 for details.) SubjectAltNameWarning
So.... I guess Rackspace needs to update their certs while we wait for distros to package OpenSSL 1.0.2. If I understand all this correctly, we'll have problems until both problems are remedied.
I'll leave this issue open in case this assessment of the problem is incorrect. Maintainers can close, otherwise.
We know about the subjectAltName issue on the cert and are rectifying it. It is truly just a warning and everything is actually functioning fine.
I know that this is closed, but just wanted to correct a misconception: turning off SSL certificate verification does not result in your credentials, etc., being sent in clear text across the wire. It simply means that when negotiating cryptographic keys for your session, that you will trust the certificate as valid. This is useful when the other party is using a self-signed certificate that you trust, or, as in this case, where the provider has not updated their certificates properly.
Ah, yeah - sorry about that.
The subjectAltName issue is tracked at #528
@mnaglee Just saw an update for 14.04 related to openssl, ca-certificates et al.
Processing triggers for man-db (2.6.7.1-1ubuntu1) ...
Setting up libgnutls26:amd64 (2.12.23-12ubuntu2.5) ...
Setting up libgnutls-openssl27:amd64 (2.12.23-12ubuntu2.5) ...
Setting up libssl-doc (1.0.1f-1ubuntu2.17) ...
Setting up libssl1.0.0:amd64 (1.0.1f-1ubuntu2.17) ...
Setting up libssl-dev:amd64 (1.0.1f-1ubuntu2.17) ...
Setting up cpio (2.11+dfsg-1ubuntu1.2) ...
Setting up openssl (1.0.1f-1ubuntu2.17) ...
Setting up ca-certificates (20160104ubuntu0.14.04.1) ...
Setting up linux-libc-dev:amd64 (3.13.0-79.123) ...
Processing triggers for libc-bin (2.19-0ubuntu6.7) ...
Processing triggers for ca-certificates (20160104ubuntu0.14.04.1) ...
Updating certificates in /etc/ssl/certs... 19 added, 19 removed; done.
Running hooks in /etc/ca-certificates/update.d....done.
Is this going to help, or, when are we able to upgrade to the latest certifi, or is that not going to happen during the lifetime of this Ubuntu LTS?
I was able to resolve the SSL issue by adding some removed Thawte certificates to /usr/local/share/ca-certificates:
sudo wget https://www.thawte.com/roots/thawte_Server_CA.pem -O /usr/local/share/ca-certificates/thawte_Server_CA.crt
sudo wget https://www.thawte.com/roots/thawte_Premium_Server_CA.pem -O /usr/local/share/ca-certificates/thawte_Premium_Server_CA.crt
sudo update-ca-certificates
They were removed in a mid-Dec update and are part of the existing Rackspace API cert chain: http://metadata.ftp-master.debian.org/changelogs/main/c/ca-certificates/ca-certificates_20141019+deb8u1_changelog
Just going to throw it out there that as a brand new user with a brand new virtualenv, I ran into this error. Fix was to install the OLD version of certifi. This is literally the first thing I did with pyrax and it makes it feel pretty wonky.
Attempting to use django-cumulus, and a fresh install yields:
This appears to be a resurrection of https://github.com/rackspace/pyrax/issues/545