SSL: CERTIFICATE_VERIFY_FAILED with Lets encrypt

I am using python 3.4 with urllib3 library.
I have no difficulty using self signed certificates with this code, but when I try to use my lets encrypt certs then I run into CERTIFICATE VERIFY failed problems.

I also tried to get a handshake using

openssl s_client -connect dashboard.zibawa.com:443 -CAfile /path/to/letsencypt/fullchain.pem

This produces a successful tls handshake.

I tried with the lets encrypt intermediate or root certificates, and I could not even get ssl to work, so my question is, what CA cert should I be using and how can I get this to work with urllib3 ā€œverify certsā€?

Thanks in advance for any help.

My python code is as follows:

from requests import Request, Session ca_certs='/path/to/letsencypt/fullchain.pem' url= 'https://dashboard.zibawa.com/api/org'

username= settings.DASHBOARD[ā€˜userā€™]
password= settings.DASHBOARD[ā€˜passwordā€™]

headers = {ā€˜Acceptā€™: ā€˜application/jsonā€™,
ā€˜Content-Typeā€™ : ā€˜application/jsonā€™,}

s = Session()
req = Request(ā€˜GETā€™, url, data=data, headers=headers, auth=(username,password))

prepped = s.prepare_request(req)

resp = s.send(prepped,
verify=ca_certs,

)

print(resp.status_code)
return resp

Hi @mattfield,

I didnā€™t understand what kind of server you are using and how youā€™ve configured it. Thatā€™s the most important question here in order to understand what could be wrong.

fullchain.pem normally only needs to be used on the server side, not the client side. The server will normally serve the full chain needed by clients to verify the server, and the clients normally already know about the IdenTrust root (DST Root CA X3) and so can verify the chain without any additional information.

Thanks to your comments I have been able to solve the issue. I had not understood which root certificate I required.

To clearup what I was trying to do:
I had setup NGINX to serve my web app using fullchain.pem.

This worked fine in the browser (because as you say, the browser ā€œknowsā€ about the letsencrypt root.

However I was having difficulty connecting to apis which were being proxied behind my NGINX server. In my case I was using python libraries (urllib3) which asks for a ā€œca_certā€ path to point to my trusted root certificate.

I had not understood which root certificate to use and had been using the intermediate certs instead. (Maybe it would be useful to make the links to the DST Root more obvious(?).

SOLUTION:

Following your remarks above I copied the DST Root CA X3 from https://www.identrust.com/certificates/trustid/root-download-x3.html. I also had to add the lines ā€œ-----BEGIN CERTIFICATE-----ā€ and ā€œ-----END CERTIFICATE-----ā€ to my file.(Why do they make it so difficult?) Then saving this file I was able to set ā€œca_certsā€ to point to this file when calling the https apps from python using urllib and ā€œverify_certsā€ now works. Thanks for your help.

1 Like

Iā€™m glad this worked for you!

On most systems there are already root CAs (perhaps in /etc/ssl/certs) which Iā€™ve seen used automatically by Python. On my system, for example, Iā€™m able to do

>>> import urllib3
>>> http = urllib3.PoolManager()
>>> http.request("GET", "https://community.letsencrypt.org/")
<urllib3.response.HTTPResponse object at 0x7f51b7be5490>

without doing anything fancy. This site is itself secured with a Letā€™s Encrypt certificate and urllib3 knew how to validate it because of my systemwide root certificate. So Iā€™m not sure why this is possibly not the case in your environment.

I was not aware of that and it is very useful to know. But in any case I
needed to work out where to get the root from because some of my
applications are IoT and so i want to be able to guarantee they can find
the right CA. Thanks once again for all your help!

https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
Libre
de virus. www.avast.com
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.