SSLError: bad handshake: Error([('SSL routines', 'SSL3_GET_SERVER_CERTIFICATE', 'certificate verify failed')],)

[mnaglee]

Attempting to use django-cumulus, and a fresh install yields:

ERROR:root:Pyrax Connect Error in `django_cumulus.cumulus.authentication.Auth`::
                           self.pyrax.set_credentials(self.username, self.api_key)

Traceback (most recent call last):
  File "/Environments/easy/local/lib/python2.7/site-packages/cumulus/authentication.py", line 51, in __init__
    self.pyrax.set_credentials(self.username, self.api_key)
  File "/Environments/easy/local/lib/python2.7/site-packages/pyrax/__init__.py", line 439, in _wrapped
    return fnc(*args, **kwargs)
  File "/Environments/easy/local/lib/python2.7/site-packages/pyrax/__init__.py", line 502, in set_credentials
    tenant_id=tenant_id, region=region, authenticate=authenticate)
  File "/Environments/easy/local/lib/python2.7/site-packages/pyrax/identity/rax_identity.py", line 68, in set_credentials
    region=region, tenant_id=tenant_id, authenticate=authenticate)
  File "/Environments/easy/local/lib/python2.7/site-packages/pyrax/base_identity.py", line 420, in set_credentials
    self.authenticate()
  File "/Environments/easy/local/lib/python2.7/site-packages/pyrax/identity/rax_identity.py", line 83, in authenticate
    password=password, api_key=api_key, tenant_id=tenant_id)
  File "/Environments/easy/local/lib/python2.7/site-packages/pyrax/base_identity.py", line 599, in authenticate
    headers=headers, std_headers=False)
  File "/Environments/easy/local/lib/python2.7/site-packages/pyrax/base_identity.py", line 531, in method_post
    return self._call("POST", uri, admin, data, headers, std_headers)
  File "/Environments/easy/local/lib/python2.7/site-packages/pyrax/base_identity.py", line 570, in _call
    return pyrax.http.request(mthd, uri, verify=self.verify_ssl, **kwargs)
  File "/Environments/easy/local/lib/python2.7/site-packages/pyrax/http.py", line 63, in request
    resp = req_method(uri, data=data, **kwargs)
  File "/Environments/easy/local/lib/python2.7/site-packages/requests/api.py", line 107, in post
    return request('post', url, data=data, json=json, **kwargs)
  File "/Environments/easy/local/lib/python2.7/site-packages/requests/api.py", line 53, in request
    return session.request(method=method, url=url, **kwargs)
  File "/Environments/easy/local/lib/python2.7/site-packages/requests/sessions.py", line 468, in request
    resp = self.send(prep, **send_kwargs)
  File "/Environments/easy/local/lib/python2.7/site-packages/requests/sessions.py", line 576, in send
    r = adapter.send(request, **kwargs)
  File "/Environments/easy/local/lib/python2.7/site-packages/requests/adapters.py", line 447, in send
    raise SSLError(e, request=request)
SSLError: bad handshake: Error([('SSL routines', 'SSL3_GET_SERVER_CERTIFICATE', 'certificate verify failed')],)

This appears to be a resurrection of #545

[thijstriemstra]

Creating a ~/.pyrax.cfg file with contents below solved this for me:

[default]
verify_ssl = False

[briancurtin]

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.

[thijstriemstra]

Oh fuck, thanks for the suggestion. Time to dig deeper. Blah.

[thijstriemstra]

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?

[thijstriemstra]

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?

[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

[thijstriemstra]

Thanks, even better!

[mnaglee]

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 nosubjectAltName, falling back to check for acommonNamefor 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.

[mnaglee]

I'll leave this issue open in case this assessment of the problem is incorrect. Maintainers can close, otherwise.

[briancurtin]

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.

[EdLeafe]

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.

[briancurtin]

Ah, yeah - sorry about that.

[thijstriemstra]

The subjectAltName issue is tracked at #528

[thijstriemstra]

@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?

[Malcolm]

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

[mlissner]

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.