117

I've installed a self-signed root ca cert into debian's /usr/share/ca-certificates/local and installed them with sudo dpkg-reconfigure ca-certificates. At this point true | gnutls-cli mysite.local is happy, and true | openssl s_client -connect mysite.local:443 is happy, but python2 and python3 requests module insists it is not happy with the cert.

python2:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/local/lib/python2.7/site-packages/requests/api.py", line 70, in get
    return request('get', url, params=params, **kwargs)
  File "/usr/local/lib/python2.7/site-packages/requests/api.py", line 56, in request
    return session.request(method=method, url=url, **kwargs)
  File "/usr/local/lib/python2.7/site-packages/requests/sessions.py", line 488, in request
    resp = self.send(prep, **send_kwargs)
  File "/usr/local/lib/python2.7/site-packages/requests/sessions.py", line 609, in send
    r = adapter.send(request, **kwargs)
  File "/usr/local/lib/python2.7/site-packages/requests/adapters.py", line 497, in send
    raise SSLError(e, request=request)
requests.exceptions.SSLError: ("bad handshake: Error([('SSL routines', 'ssl3_get_server_certificate', 'certificate verify failed')],)",)

python3

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/local/bin/python3.5/site-packages/requests/api.py", line 70, in get
    return request('get', url, params=params, **kwargs)
  File "/usr/local/bin/python3.5/site-packages/requests/api.py", line 56, in request
    return session.request(method=method, url=url, **kwargs)
  File "/usr/local/bin/python3.5/site-packages/requests/sessions.py", line 488, in request
    resp = self.send(prep, **send_kwargs)
  File "/usr/local/bin/python3.5/site-packages/requests/sessions.py", line 609, in send
    r = adapter.send(request, **kwargs)
  File "/usr/local/bin/python3.5/site-packages/requests/adapters.py", line 497, in send
    raise SSLError(e, request=request)
requests.exceptions.SSLError: ("bad handshake: Error([('SSL routines', 'ssl3_get_server_certificate', 'certificate verify failed')],)",)

Why does python ignore the system ca-certificates bundle, and how do I integrate it?

ThorSummoner
  • 16,657
  • 15
  • 135
  • 147

5 Answers5

225

From https://stackoverflow.com/a/33717517/1695680

To make python requests use the system ca-certificates bundle, it needs to be told to use it over its own embedded bundle

export REQUESTS_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt

Requests embeds its bundles here, for reference:

/usr/local/lib/python2.7/site-packages/requests/cacert.pem
/usr/lib/python3/dist-packages/requests/cacert.pem

Or in newer versions use additional package to obtain certificates from: https://github.com/certifi/python-certifi

To verify from which file certificates are loaded, you can try:

Python 3.8.5 (default, Jul 28 2020, 12:59:40) 
>>> import certifi
>>> certifi.where()
'/etc/ssl/certs/ca-certificates.crt'
Anton Krosnev
  • 3,964
  • 1
  • 21
  • 37
ThorSummoner
  • 16,657
  • 15
  • 135
  • 147
  • 11
    After I delete the default cacert.pem bundled by requests, requests seems to pickup the system ca-certifications bundle without setting the environment variable. – Rajasi Kulkarni Aug 08 '17 at 13:54
  • 7
    Setting environmental variable REQUESTS_CA_BUNDLE works. However, it does not change crt path in certifi module. The answer implies that it does, but my test in python 3.7 and 3.8 shows otherwise. I recommand use os.getenv to check the path instead. – nafooesi Apr 27 '21 at 04:53
  • you can also use the path in the verify keyword argument like so: verify='/etc/ssl/certs/ca-certificates.crt' – Baza86 Jan 11 '23 at 00:43
  • 1
    This environment variable does not work on all systems. On CentOS, for example, I needed to use SSL_CERT_FILE variable as noted in another answer: https://stackoverflow.com/a/75352343/2779147 – jakebeal Feb 21 '23 at 15:19
  • @jakebeal are you sure you're interacting python pypi Requests and not openssl? it is very possible in your case requests is using openssl and will respect this argument, but there is a subtle difference, eg i wouldn't expect SSL_CERT_FILE to impact requests linked to gnutls -- unless gnutls is mocking openssl environs compatibility in the same was requests considered and possibly Incorporated here https://github.com/psf/requests/issues/2899 Thanks for a good note! – ThorSummoner Mar 03 '23 at 06:44
33

I struggled with this for a week or so recently. I finally found that the way to verify a self-signed, or privately signed, certificate in Python. You need to create your own certificate bundle file. No need to update obscure certificate bundles every time you update a library, or add anything to the system certificate store.

Start by running the openssl command that you ran before, but add -showcerts. openssl s_client -connect mysite.local:443 -showcerts This will give you a long output, and at the top you'll see the entire certificate chain. Usually, this means three certs, the website's certificate, the intermediate certificate, and the root certificate in that order. We need to put just the root and intermediate certificates into a next file in the opposite order.

Copy the last cert, the root certificate, to a new text file. Grab just the stuff between, and including:

-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----

Copy the middle cert (aka the intermediate certificate) to the new text file under the root cert. Again, grab the Begin and End Certificate lines and everything in between.

Save this text file to the directory where your Python script resides. My recommendation is to call it CertBundle.pem. (If you give it a different name, or put it somewhere else in your folder structure, make sure that the verify line reflects that.) Update your script to reference the new certificate bundle:

response = requests.post("https://www.example.com/", headers=headerContents, json=bodyContents, verify="CertBundle.pem")

And that's it. If you have only the root or only the intermediate certificate, then Python can't validate the entire certificate chain. But, if you include both of the certificates in the certificate bundle that you created, then Python can validate that the intermediate was signed by the root, and then when it accesses the website it can validate that the website's certificate was signed by the intermediate certificate.

edit: Fixed the file extension for the cert bundle. Also, fixed a couple of grammatical mistakes.

fryad
  • 361
  • 4
  • 5
  • 1
    I'm not confident .p7b is the right semantic extension for said bundle. (Albeit I am not really an expert) just used to seeing .pem and .crt used for CA Bundles. I know the debian ca-certificates package is picky about certificates being .crt extensions to be added to the system-provided certificate store. – ThorSummoner Feb 06 '18 at 19:24
  • I almost said something about that in my post. I went with p7b because I think that's the right extention, but for this purpose it doesn't matter. It can be .txt, or no extention at all. The important thing is that your Python script can find the file. – fryad Feb 09 '18 at 03:08
  • 7
    @fryad is correct; this file ought to have the `.pem` extension, and some tools will mishandle it because it has the wrong extension. `.pem` is the [_de facto_ standard extension for this base64-encoded certificate format](https://serverfault.com/a/9717/322144), while the binary version of the same format is `.der`, and `.p7b` is a _different_ base64-encoded format. A handy reference on how to convert among them using `openssl` CLI tools: https://knowledge.digicert.com/solution/SO26449.html – Dan Lenski Jul 17 '18 at 02:58
19

My two cents:

Thanks to this other answer, which had me check on actual requests code, I figured out that you don't have to use the env variable but can just set the "verify" param in your request:

requests.get("https://whatever", verify="/my/path/to/cacert.crt", ...)

It is also documented, although I could only find the documentation after having made the discovery (and the pypi project points to a dead link for doc) :D

Riccardo Manfrin
  • 653
  • 1
  • 7
  • 15
15

requests uses certifi as default root certs package, which builts in a lot of good CAs but unable to modify.

Debian (and Ubuntu) maintainers changed certifi's behavior different from default:

def where():
    return "/etc/ssl/certs/ca-certificates.crt"

So if you use apt-installed requests and certifi there is no problem.

But pip3 installed certifi inside virtual env use builtin CAs. So unable to use update-ca-certificates mechanism. Beside manually specifying root cert in app code (which may not be possible if request is called indirectly through 3rd party interfaces), it can also overriding with enviroument variable REQUESTS_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt to emulate the Debianized behavor.

adoal
  • 151
  • 1
  • 2
  • I'm in a docker container with Debian Buster. Simply setting REQUESTS_CA_BUNDLE to a cert file does not use those certs with aiohttp. Perhaps it works for 'requests'. I'm in Python 3.10 – Lee Meador Oct 03 '22 at 16:33
  • 2
    I found that setting SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt does work with aiohttp. – Lee Meador Oct 03 '22 at 17:08
  • Setting REQUESTS_CA_BUNDLE to my private cert solved my requests issue in a docker container. – user8675309 Aug 10 '23 at 20:19
2

After trying everything, I found this worked for me on Ubuntu

export SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt

I had to do this even though certifi showed the same path.

Bolli
  • 4,974
  • 6
  • 31
  • 47