Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

🐛 [BUG]: CERTIFICATE_VERIFY_FAILED error with canarie-api monitoring #198

Closed
tlvu opened this issue Sep 30, 2021 · 2 comments · Fixed by #254
Closed

🐛 [BUG]: CERTIFICATE_VERIFY_FAILED error with canarie-api monitoring #198

tlvu opened this issue Sep 30, 2021 · 2 comments · Fixed by #254
Assignees
Labels
bug Something isn't working

Comments

@tlvu
Copy link
Collaborator

tlvu commented Sep 30, 2021

Summary

Using LetsEncrypt SSL certificate, the canarie-api monitoring page https://lvupavicsdev.ouranos.ca/canarie/node/service/status fail with a bunch of CERTIFICATE_VERIFY_FAILED but all the services are working properly.

This is most likely due to https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/ meaning the openssl library in the proxy container is too old.

This bug only impact PAVICS deployment using LetsEncrypt certificate and only if the canarie-api monitoring matter. Otherwise all other services are still working fine (Jenkins run all pass http://jenkins.ouranos.ca/job/PAVICS-e2e-workflow-tests/job/master/1253/console).

Ouranos production has been switched to use another SSL certificate provider as a work-around.

@moulab88 FYI

Details

Screenshot 2021-09-30 at 14-55-31 Ouranos - Node Service

How to reproduce

$ docker exec proxy python -c "import requests; requests.request('GET', 'https://lvupavicsmaster.ouranos.ca/geoserver'
> )"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/local/lib/python2.7/dist-packages/requests/api.py", line 50, in request
    response = session.request(method=method, url=url, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/requests/sessions.py", line 468, in request
    resp = self.send(prep, **send_kwargs)
  File "/usr/local/lib/python2.7/dist-packages/requests/sessions.py", line 576, in send
    r = adapter.send(request, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/requests/adapters.py", line 433, in send
    raise SSLError(e, request=request)
requests.exceptions.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:661)
@tlvu tlvu added the bug Something isn't working label Sep 30, 2021
@tlvu tlvu assigned matprov and tlvu Sep 30, 2021
@github-actions
Copy link

Thanks for submitting an issue.
Please make sure to provide enough details for us to be able to replicate your issue or understand your question.

@tlvu
Copy link
Collaborator Author

tlvu commented Aug 14, 2022

Root cause is the request python library bundle their own CA root certificates bundle which is less up-to-date than the one the OS provide ! This is really annoying.

$ docker exec proxy python -c "import requests; print requests.certs.where()"
/usr/local/lib/python2.7/dist-packages/requests/cacert.pem

$ docker exec -it proxy bash
root@37ed3a2a03ae:/opt/local/src/CanarieAPI/canarieapi# REQUESTS_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt python -c "import requests; requests.request('GET', 'https://lvupavicsmaster.ouranos.ca/geoserver')"
root@37ed3a2a03ae:/opt/local/src/CanarieAPI/canarieapi#

# No error "requests.exceptions.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:661)"

tlvu added a commit that referenced this issue Aug 14, 2022
LetsEncrypt older root certificate "DST Root CA X3" expired on September 30,
2021, see https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/

All the major browsers and OS platform has previously added the new root
certificate "ISRG Root X1" ahead of time so the transition to the new
root certificate is seemless for all clients.

Python `requests` package bundle their own copy of known root
certificates and is late to add this new root cert "ISRG Root X1".  Had
it automatically fallback to the OS copy of the root cert bundle, this
would have been seemless.

The fix is to force `requests` to use the OS copy of the root cert bundle.

Fix for this error:
```
$ docker exec proxy python -c "import requests; requests.request('GET', 'https://lvupavicsmaster.ouranos.ca/geoserver'
> )"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/local/lib/python2.7/dist-packages/requests/api.py", line 50, in request
    response = session.request(method=method, url=url, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/requests/sessions.py", line 468, in request
    resp = self.send(prep, **send_kwargs)
  File "/usr/local/lib/python2.7/dist-packages/requests/sessions.py", line 576, in send
    r = adapter.send(request, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/requests/adapters.py", line 433, in send
    raise SSLError(e, request=request)
requests.exceptions.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:661)
```

Default SSL root cert bundle of `requests`:
```
$ docker exec proxy python -c "import requests; print requests.certs.where()"
/usr/local/lib/python2.7/dist-packages/requests/cacert.pem
```

Confirm the fix works:
```
$ docker exec -it proxy bash
root@37ed3a2a03ae:/opt/local/src/CanarieAPI/canarieapi# REQUESTS_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt python -c "import requests; requests.request('GET', 'https://lvupavicsmaster.ouranos.ca/geoserver')"
root@37ed3a2a03ae:/opt/local/src/CanarieAPI/canarieapi#

$ docker exec proxy env |grep REQ
REQUESTS_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt
```

Fixes #198
@tlvu tlvu closed this as completed in #254 Aug 18, 2022
tlvu added a commit that referenced this issue Aug 18, 2022
…-to-verify-LetsEncrypt-ssl-cert

canarie-api: fix unable to verify LetsEncrypt SSL certs

LetsEncrypt older root certificate "DST Root CA X3" expired on September 30,
2021, see https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/

All the major browsers and OS platform has previously added the new root
certificate "ISRG Root X1" ahead of time so the transition to the new
root certificate is seemless for all clients.

Python `requests` package bundle their own copy of known root
certificates and is late to add this new root cert "ISRG Root X1".  Had
it automatically fallback to the OS copy of the root cert bundle, this
would have been seemless.

The fix is to force `requests` to use the OS copy of the root cert bundle.

Fix for this error:
```
$ docker exec proxy python -c "import requests; requests.request('GET', 'https://lvupavicsmaster.ouranos.ca/geoserver'
> )"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/local/lib/python2.7/dist-packages/requests/api.py", line 50, in request
    response = session.request(method=method, url=url, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/requests/sessions.py", line 468, in request
    resp = self.send(prep, **send_kwargs)
  File "/usr/local/lib/python2.7/dist-packages/requests/sessions.py", line 576, in send
    r = adapter.send(request, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/requests/adapters.py", line 433, in send
    raise SSLError(e, request=request)
requests.exceptions.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:661)
```

Default SSL root cert bundle of `requests`:
```
$ docker exec proxy python -c "import requests; print requests.certs.where()"
/usr/local/lib/python2.7/dist-packages/requests/cacert.pem
```

Confirm the fix works:
```
$ docker exec -it proxy bash
root@37ed3a2a03ae:/opt/local/src/CanarieAPI/canarieapi# REQUESTS_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt python -c "import requests; requests.request('GET', 'https://lvupavicsmaster.ouranos.ca/geoserver')"
root@37ed3a2a03ae:/opt/local/src/CanarieAPI/canarieapi#

$ docker exec proxy env |grep REQ
REQUESTS_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt
```

Fixes #198
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants