Python Requests throwing SSLError

Question

I\'m working on a simple script that involves CAS, jspring security check, redirection, etc. I would like to use Kenneth Reitz\'s python requests because it\'s a great piec

Answer 1

I face the same problem using gspread and these commands works for me:

sudo pip uninstall -y certifi
sudo pip install certifi==2015.04.28

Answer 2

Might not be helpful, but if nothing works, try this.

You put "www.example.com", requests shouts at you. You put "https://www.example.com", and get this error. Change "https" to "http" and rejoice.

Answer 3

This is similar to @rafael-almeida 's answer, but I want to point out that as of requests 2.11+, there are not 3 values that verify can take, there are actually 4:

• True: validates against requests's internal trusted CAs.
• False: bypasses certificate validation completely. (Not recommended)
• Path to a CA_BUNDLE file. requests will use this to validate the server's certificates.
• Path to a directory containing public certificate files. requests will use this to validate the server's certificates.

The rest of my answer is about #4, how to use a directory containing certificates to validate:

Obtain the public certificates needed and place them in a directory.

Strictly speaking, you probably "should" use an out-of-band method of obtaining the certificates, but you could also just download them using any browser.

If the server uses a certificate chain, be sure to obtain every single certificate in the chain.

According to the requests documentation, the directory containing the certificates must first be processed with the "rehash" utility (openssl rehash).

(This requires openssl 1.1.1+, and not all Windows openssl implementations support rehash. If openssl rehash won't work for you, you could try running the rehash ruby script at https://github.com/ruby/openssl/blob/master/sample/c_rehash.rb , though I haven't tried this. )

I had some trouble with getting requests to recognize my certificates, but after I used the openssl x509 -outform PEM command to convert the certs to Base64 .pem format, everything worked perfectly.

You can also just do lazy rehashing:

try:
    # As long as the certificates in the certs directory are in the OS's certificate store, `verify=True` is fine.
    return requests.get(url, auth=auth, verify=True)
except requests.exceptions.SSLError:
    subprocess.run(f"openssl rehash -compat -v my_certs_dir", shell=True, check=True)
    return requests.get(url, auth=auth, verify="my_certs_dir")

Answer 4

As pointed out by others, this problem "is caused by an untrusted SSL certificate". My answer is based on the top-rated answer and this answer.

You can test the certificate using curl:

curl -vvI https://example.com

If an error returns, you have 3 options:

1. For a quick fix, you could just not verify the certificate:

requests.get('https://example.com', verify=False)

2. Pass the path to the CA_BUNDLE file or directory with certificates of trusted CAs:

requests.get('https://example.com', verify='/path/to/certfile')

3. If you have access to, fix the web server certificate.

My problem was because I was using only my site's certificate, not the intermediate (a.k.a. chain) certificate.

If you are using Let's Encrypt, you should use the fullchain.pem file, not cert.pem.

Answer 5

From requests documentation on SSL verification:

Requests can verify SSL certificates for HTTPS requests, just like a web browser. To check a host’s SSL certificate, you can use the verify argument:

>>> requests.get('https://kennethreitz.com', verify=True)

If you don't want to verify your SSL certificate, make verify=False

Answer 6

I ran into the same issue. Turns out I hadn't installed the intermediate certificate on my server (just append it to the bottom of your certificate as seen below).

https://www.digicert.com/ssl-support/pem-ssl-creation.htm

Make sure you have the ca-certificates package installed:

sudo apt-get install ca-certificates

Updating the time may also resolve this:

sudo apt-get install ntpdate
sudo ntpdate -u ntp.ubuntu.com

If you're using a self-signed certificate, you'll probably have to add it to your system manually.