Hi,

accessing https://amazon.com/ or amazon webservices gives SSLError: [Errno 1] _ssl.c:510: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

Any reason to not trust verisign as CA here? anything wrong with amazon's certs?

Thanks for any insights!

It would be handy if there was a method to add a root certificate to the bundle.

My particular case: Some 3rd party apps I am using rely on the requests package. I cannot modify them directly to trust the internal pki. I had to do the following:

pip install certifi

python
import certifi
certifi.where()
quit()

cat /path/to/trusted.pem >> /path/to/virtualenv/site-packages/certifi/cacert.pem

The problem with this is that updating the certifi package will overwrite the cacert.pem file and the app will break.

It would be much nicer if I could do something like the following at the top of my django settings.py file:

import certifi
certifi.add("/path/to/trusted.pem")

Then certifi would inspect the certificate to add. If it was already included in "/path/to/virtualenv/site-packages/certifi/cacert.pem", nothing would happen. Otherwise it would append the trusted certificate to the bundle.

this certificate expired on "Sep 30 14:01:15 2021 GMT" and keeping it in the trusted store confuses OpenSSL 1.0.2 (like still present on EL7) and results in failed validations, even if there are other valid trust paths. see [1] for more details.

[1] https://www.openssl.org/blog/blog/2021/09/13/LetsEncryptRootCertExpire/

Currently requests cannot be used in things like PyOxidizer due to a reliance on the __file__ attribute. This change allows direct access to the PEM data in the cacert.pem file which can eventually be plumbed into the lower mechanisms of requests and urllib3 in order to allow these to work.

Just a simple "import requests" no longer works in the context of embedded Python with the code in a zip file. It works fine in 2020.4.5.1.

Traceback (most recent call last):
  File "D:\obj\windows-release\37amd64_Release\msi_python\zip_amd64\resources.py", line 283, in open_resource
OSError: [Errno 0] Error: 'certifi\\cacert.pem'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "...", line 8, in <module>
    import requests, zeep
  File "<frozen importlib._bootstrap>", line 983, in _find_and_load
  File "<frozen importlib._bootstrap>", line 967, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 668, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 638, in _load_backward_compatible
  File "....\python37.zip\site-packages\requests\__init__.py", line 112, in <module>
    from . import utils
  File "<frozen importlib._bootstrap>", line 983, in _find_and_load
  File "<frozen importlib._bootstrap>", line 967, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 668, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 638, in _load_backward_compatible
  File "....\python37.zip\site-packages\requests\utils.py", line 40, in <module>
    DEFAULT_CA_BUNDLE_PATH = certs.where()
  File "....\python37.zip\site-packages\certifi\core.py", line 37, in where
    _CACERT_PATH = str(_CACERT_CTX.__enter__())
  File "D:\obj\windows-release\37amd64_Release\msi_python\zip_amd64\contextlib.py", line 112, in __enter__
  File "D:\obj\windows-release\37amd64_Release\msi_python\zip_amd64\resources.py", line 201, in path
  File "D:\obj\windows-release\37amd64_Release\msi_python\zip_amd64\resources.py", line 91, in open_binary
  File "D:\obj\windows-release\37amd64_Release\msi_python\zip_amd64\resources.py", line 285, in open_resource
FileNotFoundError: certifi/cacert.pem

This will make certifi work if packed in a zip, such as when running in an egg, or packaged using Pex or Subpar.

tests/test_zip: Test referencing certifi packaged in an egg. Fixes #66

After freezing my Python application, I got an error while getting a certificate.

File "/usr/lib/python3.5/importlib/_bootstrap.py", line 816, in exec_module
    exec(code, module.__dict__)
File "/usr/local/lib/python3.5/dist-packages/requests/utils.py", line 39, in <module>
    DEFAULT_CA_BUNDLE_PATH = certs.where()
File "/usr/local/lib/python3.5/dist-packages/certifi/core.py", line 22, in where
    f = os.path.split(__file__)[0]
NameError: name '__file__' is not defined

The reason is the "file" variable in cannot be used in frozen program. https://stackoverflow.com/questions/21937695/python-cx-freeze-name-file-is-not-defined

Could it be better to handle the frozen program case:

try:
    approot = os.path.dirname(os.path.abspath(__file__))
except NameError:  
    import sys
    approot = os.path.dirname(os.path.abspath(sys.argv[0]))
    return os.path.join(approot, 'cacert.pem')

1. 1024-bit roots have only gotten more dangerous since we started this deprecation process
2. OpenSSL 1.0.1 has had this patch backported, including to distros like Ubuntu
3. OpenSSL 1.0.1, 1.0.0, and 0.9.8 are now EOL by upstream

The combination of all these factors means that keeping it around is more risk than is necessary.

To do this deprecation I recommend modifying old_where to simply return where() and emitting a warning. It can then be removed after the appropriate period.

Closes #136

These tests are very basic. They just check that the returned string is really a file and contains the PEM certificate header.

The workflow runs with pytest, but you could also use native python -m unittest.

Further work could use openssl or the Python module Cryptography to check for valid CA certificates.

This PR intends to fix the problem that local certificates are not included when using the certifi module.

This problems often arises when we want to use local certificates at the same times as public certificates in modules that use certifi (ie requests). Certifi is convenient as it removes the burden to explicit specify the certificates. This PR would enhance its usage and also extend this convenience to certificates that are local to the machine.

On Windows, the CA and ROOT store will be automatically queried for available certificates. The result will be appended to the cacert.pem file and put in the directory defined in the environment variable APPDATA.

This is done each time the module is loaded.

Only wheels that support both Python 2 and 3 are universal. Support for Python 2 was dropped in commit 5efdd48f719d9c3c7c8f9a812da2256d088eab78 (part of release 2020.04.05.2).

conda create -n test_certifi python
conda activate test_certifi

For any version of certifi after 2022.5.18.1, running pip freeze results in output like the following:

pip install -U certifi
pip freeze

certifi @ file:///private/var/folders/sy/f16zz6x50xz3113nwtb9bvq00000gp/T/abs_0ek9yztvu3/croot/certifi_1665076692562/work/certifi

Running pip freeze on certifi<=2022.5.18.1 has more expected output:

pip install -U certifi==2022.5.18.1
pip freeze

certifi==2022.5.18.1

This project should consider switching to declarative config, which would have the benefit of minimizing the 'setup.py' script, and might even replace the VERSION loading.

Many other projects, including the default for new Github projects, now use 'main' for the default branch name. Would this project consider doing the same?

It seems every second issue raise here is "please add some random or system certificate store to the package".

It might be useful to add a basic issue template to the github project asking users not to post requests like this with a couple of links and/or standard responses.

https://help.github.com/articles/creating-an-issue-template-for-your-repository/