certifi / python-certifi Goto Github PK

(Python Distribution) A carefully curated collection of Root Certificates for validating the trustworthiness of SSL certificates while verifying the identity of TLS hosts.

License: Other

Makefile 1.96% Python 98.04%

python-certifi's Introduction

Certifi: Python SSL Certificates

Certifi provides Mozilla's carefully curated collection of Root Certificates for validating the trustworthiness of SSL certificates while verifying the identity of TLS hosts. It has been extracted from the Requests project.

Installation

certifi is available on PyPI. Simply install it with pip:

$ pip install certifi

Usage

To reference the installed certificate authority (CA) bundle, you can use the built-in function:

>>> import certifi

>>> certifi.where()
'/usr/local/lib/python3.7/site-packages/certifi/cacert.pem'

Or from the command line:

$ python -m certifi
/usr/local/lib/python3.7/site-packages/certifi/cacert.pem

Enjoy!

Addition/Removal of Certificates

Certifi does not support any addition/removal or other modification of the CA trust store content. This project is intended to provide a reliable and highly portable root of trust to python deployments. Look to upstream projects for methods to use alternate trust.

python-certifi's People

Contributors

Stargazers

Watchers

Forkers

fetep zed pombredanne alex lukasa glyph arvedui hickford ricardh522 lovefcaaa styleseat jiocloud-tools dandavid3000 rodcloutier balena odedfos vpramo 42reports eunmin khwilson jakirkham sigmavirus24 compuguy joshlabs cloump acealchemycyberblaze huangdehui2013 frankchongli neoshrew sagarun heni braxtone jing-xie yousuowei123 khan leafeng rajkumarpandey ogranier42 evanj ramvling ww9rivers samthecruise sdelafond sjinib westurner dirttech lazercorn 3x-m4ch1na johnwwalker incocura adamchainz stephendonner johnadders asotirov0 andrewdmeier roseruns raymondseger mpavlase mkdao spacetime314 ii0 bingziqi psychokiller1888 alexgchap windbishn arobbins805 huohuoya rkracine220 twistopayments githubink danadebona luojinrong arpit-sc iloan zonp zjx632 wjswag dffxpipeline hzkop nobodyinperson tylerhockenberry alexzorin nkanne chenzhc nikokio celloni elliotsegler bostrick zenotme jeamland anthonyadavisii divbzero adferrand lh183523 hugovk dstufft bruce-carels phaniac letav1n lisajonet

python-certifi's Issues

Installing two packages via conda that require certifi --> IsADirectoryError

Environment:

Docker, Ubuntu 16.04, conda, anaconda

Here's the Dockerfile.

The error:

IsADirectoryError(21, 'Is a directory')

The following causes the error:

RUN conda install -y -c anaconda certifi
RUN conda install -y mkl-service

Here's a workaround (try to install the package again after the error):

RUN conda install -y -c anaconda certifi
RUN conda install -y mkl-service; exit 0
RUN conda install -y mkl-service

Another sequence that causes the error:

RUN conda install -y mkl-service
RUN conda install -y notebook
RUN conda install -y jupyter_contrib_nbextensions -c conda-forge

Certificate error with google secure connection

I am running

python 2.7.6

certifi==2016.2.28
requests==2.9.1

and this simple call does not work anymore:
python -c "import requests; requests.get('https://google.com', verify=True)"

.....
.........
SSLError(e, request=request)
requests.exceptions.SSLError: [Errno 1] _ssl.c:510: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

while it works fine with this certificate:

REQUESTS_CA_BUNDLE='/etc/ssl/certs/ca-certificates.crt' python -c 'import requests; requests.get("https://google.com")'

Which is the best way to sort out the issue since this is also part of my Django application working with social-python which stopped to work due to this issue a couple of days ago.

Thanks,

Walter

Make tasks.update push a new release.

Removal of Thawte?

I see in the last release you removed Thawte from the bundle completely, Any reason for this? This has broken all requests to any service using Thawte including OutbrainAPI and Mandrill.

Remove non-ascii characters from PEM file.

Apparently some JVMs are very strict about non-ascii characters, even in comments. See kennethreitz/requests#3776 for more.

This can be fixed by piping the download through a small Python script:

import sys

for l in sys.stdin.readlines():
    print unicode(l, 'utf8').strip().encode('ascii', errors='backslashreplace')

Ask users not to raise issues to add random/system certs

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/

Include license files in the pypi tarball

Hi I am packaging python-certifi in Fedora and I want to ask about include the license file in the pypi tarball please

Regards

Entrust Certificate Authority - L1K not in cacert.pem

Hi,

I can open a site in Firefox browser: https://www.cdta.org/ but cannot download a file from it using python 2.7, because a certificate authority is not found in cacert.pem (certifi==2017.4.17)

Tested with:
`
openssl s_client -connect www.cdta.org:443 -debug -tls1_2 -cipher ECDHE-RSA-AES128-GCM-SHA256

...
depth=0 C = US, ST = New York, L = Albany, O = Capital District Transportation Authority, CN = www.cdta.org
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = US, ST = New York, L = Albany, O = Capital District Transportation Authority, CN = www.cdta.org
verify error:num=21:unable to verify the first certificate
verify return:1

...

Verify return code: 21 (unable to verify the first certificate)
`

The same certificate details can be found in Firefox 54.0 (32-bit):

A certificate authority can be found on that page under "Entrust Root Certificate Authority—G2" section:
https://www.entrust.com/get-support/ssl-certificate-support/root-certificate-downloads/
Link to file:
https://www.entrust.com/root-certificates/entrust_l1k.cer
`
openssl s_client -connect www.cdta.org:443 -debug -tls1_2 -cipher ECDHE-RSA-AES128-GCM-SHA256
-CAfile entrust_l1k.cer

...

Verify return code: 0 (ok)
`

Can you please make an update?

Failure to verify a cert on latest version

EDIT: Sorry, I should have read the other issues first. This looks like the same issue as #26.

After a recent upgrade to the latest version of certifi, I could not verify a cert from quickbooks.api.intuit.com. Downgrading to version 14.5.14 worked, and I was also able to get requests to verify without certifi installed as well.

Also worth noting: ssllabs.com analysis shows that quickbooks.api.intuit.com has 2 cert paths, only one of them is in the store. So that may be an issue. (Little doubt that quickbooks isn't using best practices with certs.)

Using distutils

Seems this uses setuptools. However, it doesn't look like the nice features of setuptools are being used (unless I missing something). Is there any reason not to just use distutils?

Trove classifiers are missing from PyPI page

https://github.com/certifi/python-certifi/blob/master/setup.py#L58-L60 Certifi supports Python 3 but these "trove classifiers" are missing from Certifi PyPI record. This has caused Certifi to go from green to red on the Python 3 Wall of Superpowers.

http://certifi.io/en/latest is not accessible

Is the site down?

wheel distribution

Google Maps API Certificate Error...

Receiving certificate error when trying to use Google Maps API. Fixed the issue by rolling back certifi but wanted to make you aware...

See: THIS THREAD

version missmatch

Any reason why on PyPi we have 2018.1.18 but the package version says 2018.01.18? This makes it hard to write tests that after install what we installed is actually what we have.

Missing CA

Hello,

The following intermediate CA is unknown in Certifi :

C=US, O=Symantec Corporation, OU=Symantec Trust Network, CN=Symantec Class 3 Secure Server CA - G4

It can be seen here : https://www.erlang.org/downloads

Thanks

ImportError: No module named certifi

Hi, I tried to run my program and connect to SAP Hana Trial but before the program even starts it gives me that error:

I installed certifi using pip

Traceback (most recent call last):
  File "/home/pi/projectnb/myfirstcode.py", line 5, in <module>
    import certifi
ImportError: No module named certifi

I installed all requirements as well.

alabaster==0.7.10
automationhat==0.0.4
Babel==2.5.1
blinker==1.3
blinkt==0.1.0
Cap1xxx==0.1.3
certifi==2017.11.5
chardet==3.0.4
click==6.6
colorama==0.3.7
cryptography==1.7.1
docutils==0.14
drumhat==0.0.5
enum34==1.1.6
envirophat==0.0.6
ExplorerHAT==0.4.2
Flask==0.12.1
fourletterphat==0.0.2
gpiozero==1.4.0
idna==2.6
imagesize==0.7.1
ipaddress==1.0.17
itsdangerous==0.24
Jinja2==2.10
keyring==10.1
keyrings.alt==1.3
lxkeymap==0.1
MarkupSafe==1.0
mcpi==0.1.1
microdotphat==0.1.3
mote==0.0.3
motephat==0.0.2
numpy==1.12.1
oauthlib==2.0.1
phatbeat==0.0.2
pianohat==0.0.5
picamera==1.13
picraft==1.0
piglow==1.2.4
pigpio==1.38
Pillow==4.0.0
pyasn1==0.1.9
pycrypto==2.6.1
pygame==1.9.3
Pygments==2.2.0
pygobject==3.22.0
pyinotify==0.9.6
PyJWT==1.4.2
pyOpenSSL==16.2.0
pyserial==3.2.1
pytz==2017.3
pyxdg==0.25
rainbowhat==0.0.2
requests==2.18.4
requests-oauthlib==0.7.0
RPi.GPIO==0.6.3
RTIMULib==7.2.1
scrollphat==0.0.7
scrollphathd==1.0.1
SecretStorage==2.3.1
sense-emu==1.0
sense-hat==2.2.0
simplejson==3.10.0
six==1.11.0
skywriter==0.0.7
sn3218==1.2.7
snowballstemmer==1.2.1
Sphinx==1.6.5
sphinxcontrib-websupport==1.0.1
spidev==3.0
touchphat==0.0.1
twython==3.4.0
typing==3.6.2
urllib3==1.22
Werkzeug==0.11.15

Any help is appreciated - thanks :-)

old_root.pem and weak.pem

How are generated these files? They may be useful for erlang users as well. Any hint on how to generate them would be helpful :)

Google certificate is not accepted

With latest requests and certifi try to open https://www.google.com with requests
It says CERTIFICATE_VERIFY_FAILED

I am using recaptcha2 and it is broken because of that

local corp certs

Hi is there a way to add my locally installed corporate certificates to certifi somehow?

and why doesn't it by default check for certain locations like Go seems to do it?

Basically what happens without really having a default solution is people just ignoring security altogether.

Lets Encrypt Root CA missing

Please add Lets Encrypt root CA:

https://letsencrypt.org/certs/lets-encrypt-x3-cross-signed.pem.txt

Thanks

Trove classifiers not displayed.

The most recent release on PyPI does not include trove classifiers, which breaks tools like caniusepython3. Is this easy to fix, or will this have to wait until the next release?

Upload a wheel of certifi

Tag missing for 2016.08.31

Thanks!

ability to trust private pki

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.

Documentation unavailable

Just a heads up: the documentation URL, https://certifi.io , linked to in the GitHub description and README, is currently unreachable.

extract system trust roots on OS X

Homebrew has a recipe for doing this; it involves running the security tool on the command line.

GeoTrust Global CA cert broken

The GeoTrust Global CA cert seems to be having issues with any intermediary certificates:

openssl s_client -connect google.com:443 -CAfile bad_pem ... Verify return code: 20 (unable to get local issuer certificate)

If the GeoTrust Global CA is removed, everything works fine.

Offending CA is on lines 699-725.

Google Internet Authority G2 and Equifax Secure Certificate Authority not included?

First of all I'd like you thank you for your efforts in working on a safer web. I do have a question on that safety though...

I'm using django-allauth and certifi since it's installed via dependencies. Django-allauth comes with a bunch of oauth "clients" and one them is Google. I learned that I'm not able to work with the Google OAuth flow when I'm using plain certifi as both Google Internet Authority G2 and Equifax Secure Certificate Authority are not included in the bundle shipped with certifi.

I know (http://www.tenberge-ict.nl/solving-sslerror-at-accountsgooglelogincallback-on-django-allauth/) what I did to get the software running, but I'm repeating this after each certifi update, which got me wondering. It looks like those CA's are not in the trust list. Why?

Remove CNNIC?

CNNIC issued an intermediate certificate to an organization that used it to issue valid certificates for many sites all over the Internet. In response, Mozilla and Chrome have both suspended accepting new CNNIC certificates: https://blog.mozilla.org/security/2015/04/02/distrusting-new-cnnic-certificates/

They are both accepting any certificates issued before April 1, 2015, but not any issued since then, until CNNIC applies and is re-admitted as a SSL vendor.

I was wondering if certifi had the ability to distinguish certificates issued by an authority and if so, if certifi should un-certify new CNNIC certificates.

Drop support for `old_where`

1024-bit roots have only gotten more dangerous since we started this deprecation process
OpenSSL 1.0.1 has had this patch backported, including to distros like Ubuntu
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.

certifi-2015.9.6.1 and 2015.9.6.2 fail verification

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!

"file" variable cannot be used when running with frozen program

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')

Missing Equifax Secure CA 1024-bit weak root.

Reported in IRC.

Apparently, New Relic is serving its API (https://api.newrelic.com) from a cert chain that is cross-signed against Equifax Secure Certificate Authority, which is a 1024-bit root certificate we are apparently missing from our weak bundle. I have no idea how I missed it, but this is the downside of a manual approach.

The certificate is below: I propose that we add it back in to old_root.pem and then ship an updated certifi with weak.pem including the cert.

@certifi/erlang-team This is likely to be relevant to you too, watch this issue.

The certificate that's missing is below (retrieved from an Ubuntu 14.04 system):

OpenSSL says:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 903804111 (0x35def4cf)
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, O=Equifax, OU=Equifax Secure Certificate Authority
        Validity
            Not Before: Aug 22 16:41:51 1998 GMT
            Not After : Aug 22 16:41:51 2018 GMT
        Subject: C=US, O=Equifax, OU=Equifax Secure Certificate Authority
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (1024 bit)
                Modulus:
                    00:c1:5d:b1:58:67:08:62:ee:a0:9a:2d:1f:08:6d:
                    91:14:68:98:0a:1e:fe:da:04:6f:13:84:62:21:c3:
                    d1:7c:ce:9f:05:e0:b8:01:f0:4e:34:ec:e2:8a:95:
                    04:64:ac:f1:6b:53:5f:05:b3:cb:67:80:bf:42:02:
                    8e:fe:dd:01:09:ec:e1:00:14:4f:fc:fb:f0:0c:dd:
                    43:ba:5b:2b:e1:1f:80:70:99:15:57:93:16:f1:0f:
                    97:6a:b7:c2:68:23:1c:cc:4d:59:30:ac:51:1e:3b:
                    af:2b:d6:ee:63:45:7b:c5:d9:5f:50:d2:e3:50:0f:
                    3a:88:e7:bf:14:fd:e0:c7:b9
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 CRL Distribution Points: 

                Full Name:
                  DirName: C = US, O = Equifax, OU = Equifax Secure Certificate Authority, CN = CRL1

            X509v3 Private Key Usage Period: 
                Not After: Aug 22 16:41:51 2018 GMT
            X509v3 Key Usage: 
                Certificate Sign, CRL Sign
            X509v3 Authority Key Identifier: 
                keyid:48:E6:68:F9:2B:D2:B2:95:D7:47:D8:23:20:10:4F:33:98:90:9F:D4

            X509v3 Subject Key Identifier: 
                48:E6:68:F9:2B:D2:B2:95:D7:47:D8:23:20:10:4F:33:98:90:9F:D4
            X509v3 Basic Constraints: 
                CA:TRUE
            1.2.840.113533.7.65.0: 
                0...V3.0c....
    Signature Algorithm: sha1WithRSAEncryption
         58:ce:29:ea:fc:f7:de:b5:ce:02:b9:17:b5:85:d1:b9:e3:e0:
         95:cc:25:31:0d:00:a6:92:6e:7f:b6:92:63:9e:50:95:d1:9a:
         6f:e4:11:de:63:85:6e:98:ee:a8:ff:5a:c8:d3:55:b2:66:71:
         57:de:c0:21:eb:3d:2a:a7:23:49:01:04:86:42:7b:fc:ee:7f:
         a2:16:52:b5:67:67:d3:40:db:3b:26:58:b2:28:77:3d:ae:14:
         77:61:d6:fa:2a:66:27:a0:0d:fa:a7:73:5c:ea:70:f1:94:21:
         65:44:5f:fa:fc:ef:29:68:a9:a2:87:79:ef:79:ef:4f:ac:07:
         77:38

Failure to access google storage apis when using the requests module - SSL3_GET_SERVER_CERTIFICATE

When the certifi package is installed together with the requests module the following domain certificate fails validation: https://storage.googleapis.com/

Traceback (most recent call last):
  File "run.py", line 4, in <module>
    requests.get('https://storage.googleapis.com/')
  File "/usr/local/lib/python2.7/dist-packages/requests/api.py", line 69, in get
    return request('get', url, params=params, **kwargs)
  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 471, in request
    resp = self.send(prep, **send_kwargs)
  File "/usr/local/lib/python2.7/dist-packages/requests/sessions.py", line 579, in send
    r = adapter.send(request, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/requests/adapters.py", line 430, in send
    raise SSLError(e, request=request)
requests.exceptions.SSLError: bad handshake: Error([('SSL routines', 'SSL3_GET_SERVER_CERTIFICATE', 'certificate verify failed')],)

The way certifi is updated seems hard to maintain in production and is possibly a security risk

This is possibly a misunderstanding of mine, so please correct me if I'm wrong.

The CA bundle is updated in certifi simply by pushing a new version of certifi to github and pypi. This has a simple security consequence: Any Python code that uses certifi does not use the latest CA bundle until certifi is explicitly updated. Unlike traditional package updates, all (or almost all) certifi updates are by design security updates (and rarely feature updates), and these are pretty frequent: Once or twice a month. For other packages, security updates are pretty infrequent. Thus, security-conscious developers would want to update certifi with every new release.

Sometimes, this is not so simple. For instance, consider a Python web server that uses requests to make outside REST API calls and certifi to secure them. Such servers can be up for months or longer. Updating the certifi package would require the server (at least the Python part of it) to restart, which can be undesirable.

Another complication is caused by pip's requirements.txt format. Many Python hosts (for example, Heroku, or Amazon Elastic Beanstalk, or Google App Engine...) take a pip requirements.txt file along with your code and set up an environment using this file. The "recommended" way to create this file is to run pip freeze. Unfortunately, this command pins down the version of packages, so you could get something like certifi==2016.8.8, which is somewhat of a security risk - you would never get an up-to-date CA bundle.

Furthermore, even if you do change the requirements.txt line to something like certifi or certifi>=2016.8.8, if your environment is set up using pip install -r requirements.txt and it already had an old version of certifi installed, it would not get upgraded. It only gets upgraded if pip install explicitly gets the -U switch; there is no way to "force an upgrade" through the requirements.txt file alone.

I am not sure what the best way to remedy this would be, but I suggest decoupling the certifi version from the bundle version and having certifi try to auto-update the bundle every, say, 24 hours, from a reliable source like mkcert.org (using certificate pinning to enhance security and to avoid having a chicken and egg problem).

Thanks for a great package!

Support for python 2.5

Setup (and pypi metadata) insists that certifi package supports python 2.5:

python-certifi/setup.py

Line 45 in 3850279

'Programming Language :: Python :: 2.5',

But in same file it uses construction that is incompatible:

python-certifi/setup.py

Line 10 in 3850279

with open('certifi/__init__.py', 'r') as f:

Result is:

C:\>py -2.5 -m pip install --insecure requests==0.10.0
Downloading/unpacking requests==0.10.0
  Downloading requests-0.10.0.tar.gz (62kB): 62kB downloaded
  Running setup.py egg_info for package requests
Downloading/unpacking certifi>=0.0.4 (from requests==0.10.0)
  Downloading certifi-2016.2.28.tar.gz (364kB): 364kB downloaded
  Running setup.py egg_info for package certifi
    c:\users\XXXX\appdata\local\temp\pip-build-XXXX\certifi\setup.py:10: Warning: 'with' will become a reserved keyword in Python 2.6
    Traceback (most recent call last):
      File "<string>", line 16, in <module>
      File "c:\users\XXXX\appdata\local\temp\pip-build-XXXX\certifi\setup.py", line 10
        with open('certifi/__init__.py', 'r') as f:
                ^
    SyntaxError: invalid syntax
    Complete output from command python setup.py egg_info:
    c:\users\XXXX\appdata\local\temp\pip-build-XXXX\certifi\setup.py:10: Warning: 'with' will become a reserved keyword in Python 2.6

Traceback (most recent call last):

  File "<string>", line 16, in <module>

  File "c:\users\XXXX\appdata\local\temp\pip-build-XXXX\certifi\setup.py", line 10

    with open('certifi/__init__.py', 'r') as f:

            ^

SyntaxError: invalid syntax

----------------------------------------
Command python setup.py egg_info failed with error code 1 in c:\users\XXXX\appdata\local\temp\pip-build-XXXX\certifi
Storing complete log in c:\users\XXXX\appdata\local\temp\tmpdt40ir

Trusted certs pulled over insecure channel

Currently certifi is pulling the ca-bundle over a non-TLS protected channel (http), which means that anyone between the host and ci.kennethreitz.org can inject or completely modify the ca certificates bundle to inject their own trusted ca, allowing them to man-in-the-middle tls traffic between python clients and any site they connect to.

To address this, the ca bundle should be hosted on a site protected by TLS, and https://github.com/certifi/python-certifi/blob/master/tasks.py#L5 should be updated to reflect the new endpoint.

Python 3 Support

Hi guys,

are there any plans on adding python 3 support?

How does this compare to the debian package 'ca-certificates'?

For the CAs installed there: https://packages.debian.org/jessie/all/ca-certificates/filelist

Why should I use certifi?!

Omission of 2 VeriSign CA certs?

If this is not the right forum for this question please suggest the correct one.

Certifi owners,

After upgrading python requests module from v2.3.0 to v2.4.0 SSL cert verification against one of our API webservers began to fail. We see that v2.4 requires certifi to provide the cacert.pem. We confirmed that our request.get() call is using this new certifi cacert.pem. The error we're seeing is:

requests.exceptions.SSLError: [Errno 1] _ssl.c:490: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

After some digging we found that you have removed the VeriSign CA certs that our target cert requires for verification. The CA certs in question exist both in the requests module's cacert.pem (now unused) and redhat OS' default ca-bundle.crt. Locations for your reference:

certifi: /usr/lib/python2.6/site-packages/certifi/cacert.pem
requests: /usr/lib/python2.6/site-packages/requests/cacert.pem
redhat: /etc/pki/tls/certs/ca-bundle.crt

Versions in use:

certifi==2015.9.6.2
requests==2.4.0
Python 2.6.6
Red Hat Enterprise Linux Server release 6.4 (Santiago)
OpenSSL 0.9.8zc-fips 15 Oct 2014

Question 1: was the omission of these two certs (provided below) an oversight or was there a good reason they were removed?

Question 2: If an oversight when can we expect them to be added back in?

CA bundle existence: requests module yes, redhat yes, certifi no.
C:US, O:VeriSign, Inc., OU: Class 3 Public Primary Certification Authority
serial_num: 149843929435818692848040365716851702463

CA bundle existence: requests module yes, redhat no, certifi no.
C:US, O:VeriSign, Inc., OU:Class 3 Public Primary Certification Authority
serial_num: 80507572722862485515306429940691309246

Thank you for your time. Let me know if I can help.

This is a re-post of certifi/certifi.io#10 as suggested by sigmavirus24

Sorry for my ignorance but...

Question #3: I believe the above root certs are 1024-bit. Is that the issue?

Question #4: how does openSSL determine which root cert to use for verification?

domain certifi.io seems to have expired

Links to the Certifi website seem to be broken in various places (requests website, pypi) because certifi.io no longer resolves anything.

Equifax 2048 CA is not supported...

Hi,

I noticed Equifax is not included in the current pem https://github.com/certifi/python-certifi/blob/master/certifi/cacert.pem

Thus following 2048bit CA failed. I know 1024bit CA is not supported...

Do you have any plan to include Equifax or there is any reason blocking you so?

Thanks!

[root@diskprovision ~]# openssl s_client -connect s3-api.us-geo.objectstorage.softlayer.net:443
CONNECTED(00000003)
depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority
verify return:1
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify return:1
depth=1 C = US, O = GeoTrust Inc., CN = GeoTrust SSL CA - G3
verify return:1
depth=0 C = US, ST = Texas, L = Dallas, O = "SoftLayer Technologies, Inc", OU = "SoftLayer Technologies, Inc.", CN = s3-api.us-geo.objectstorage.softlayer.net
verify return:1
---
Certificate chain
 0 s:/C=US/ST=Texas/L=Dallas/O=SoftLayer Technologies, Inc/OU=SoftLayer Technologies, Inc./CN=s3-api.us-geo.objectstorage.softlayer.net
   i:/C=US/O=GeoTrust Inc./CN=GeoTrust SSL CA - G3
 1 s:/C=US/O=GeoTrust Inc./CN=GeoTrust SSL CA - G3
   i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
   i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
 3 s:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
   i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIHYjCCBkqgAwIBAgIQDauM974LirtPs29AIXCkwzANBgkqhkiG9w0BAQsFADBE
MQswCQYDVQQGEwJVUzEWMBQGA1UEChMNR2VvVHJ1c3QgSW5jLjEdMBsGA1UEAxMU
R2VvVHJ1c3QgU1NMIENBIC0gRzMwHhcNMTYwNzI5MDAwMDAwWhcNMTkwNzI5MjM1
OTU5WjCBrzELMAkGA1UEBhMCVVMxDjAMBgNVBAgMBVRleGFzMQ8wDQYDVQQHDAZE
YWxsYXMxJDAiBgNVBAoMG1NvZnRMYXllciBUZWNobm9sb2dpZXMsIEluYzElMCMG
A1UECwwcU29mdExheWVyIFRlY2hub2xvZ2llcywgSW5jLjEyMDAGA1UEAwwpczMt
YXBpLnVzLWdlby5vYmplY3RzdG9yYWdlLnNvZnRsYXllci5uZXQwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDn0Rtwhnd337O9+DKekw5gyEL1S4r+kheu
me9DptUQWsBnlUO/S6gYYx/pL+Y7dFuxdjU4J7279ipE8HaCcxkV/QWCkck744P2
940/tOx/ag3Qtidyqjs1Yu1yTyi3GdWLwPjyV9Fxr6wrpMjHMhdQ6QMek+6vIYwz
jfepR0wtiLRD1e8zzbG/zTQ0MwZLC1uHG5xyhJkVIS0gBlomQ6xmFX4ZONgFSCQs
//Ko4EFFbF7kymVqkceUp06IVwCknPLqJdI1Casb+80jXinIe4A1oKhXINKggCIe
49HHj1xDFNDS0QPoFHBthx2vprJGP5lhuXLJdUC/Oh9j9cOItPTRAgMBAAGjggPi
MIID3jBhBgNVHREEWjBYgisqLnMzLWFwaS51cy1nZW8ub2JqZWN0c3RvcmFnZS5z
b2Z0bGF5ZXIubmV0gilzMy1hcGkudXMtZ2VvLm9iamVjdHN0b3JhZ2Uuc29mdGxh
eWVyLm5ldDAJBgNVHRMEAjAAMA4GA1UdDwEB/wQEAwIFoDArBgNVHR8EJDAiMCCg
HqAchhpodHRwOi8vZ24uc3ltY2IuY29tL2duLmNybDCBnQYDVR0gBIGVMIGSMIGP
BgZngQwBAgIwgYQwPwYIKwYBBQUHAgEWM2h0dHBzOi8vd3d3Lmdlb3RydXN0LmNv
bS9yZXNvdXJjZXMvcmVwb3NpdG9yeS9sZWdhbDBBBggrBgEFBQcCAjA1DDNodHRw
czovL3d3dy5nZW90cnVzdC5jb20vcmVzb3VyY2VzL3JlcG9zaXRvcnkvbGVnYWww
HQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMB8GA1UdIwQYMBaAFNJv95b0
hT9yPDB9I9qFeJujfFp8MFcGCCsGAQUFBwEBBEswSTAfBggrBgEFBQcwAYYTaHR0
cDovL2duLnN5bWNkLmNvbTAmBggrBgEFBQcwAoYaaHR0cDovL2duLnN5bWNiLmNv
bS9nbi5jcnQwggH2BgorBgEEAdZ5AgQCBIIB5gSCAeIB4AB3AN3rHSt6DU+mIIuB
rYFocH4ujp0B1VyIjT0RxM227L7MAAABVjjZoaMAAAQDAEgwRgIhAJMgKTgrfy3m
Zmnefzs53NWx1Af79ezBHkq60lohKaQ6AiEAr58BTZoj0/mkIJdJQJwldHHQLsON
o5twW2cqY1RQ4GoAdgCkuQmQtBhYFIe7E6LMZ3AKPDWYBPkb37jjd80OyA3cEAAA
AVY42aOoAAAEAwBHMEUCIQDad2Vlna5yQEn7fWXR9k9YkHQmBC+2CiaHZ0qrdlvI
WgIgAZdaaCLItL01+SFuxy0d6/dlYdwvzHS/KNJfsDI99j8AdgBo9pj4H2SCvjqM
7rkoHUz8cVFdZ5PURNEKZ6y7T0/7xAAAAVY42aJDAAAEAwBHMEUCIQD8UEE5MLDo
ddFSq0ciREDDYrromvIaWtyqG/LkjijI9QIgC1V9EPEHHMNFzK4NcLRdLAYSz0/8
abLNMhl0xYPRKPUAdQDuS723dc5guuFCaR+r4Z5mow9+X7By2IMAxHuJeqj9ywAA
AVY42aLVAAAEAwBGMEQCIE8G4Y9FEbRVLvO9yYcHjZXdjPl1NQh1YuzMs9qReHWy
AiA81FclVWPpLU2Nshthw23Q09elBPYMg63Q0ZM4UBLyfTANBgkqhkiG9w0BAQsF
AAOCAQEAa//p6Ll606KRgYUXUA6N5uSiDPr8SSHCCxLbW4YHC7mOLNAK/p1/za5L
luiRN3Yr0qKiibGaeEssfMBtDKHu9CZBxSobaers7RS92Ni7fkVCiaayRJrOL6o8
Xf8wFOcRPO0/owGFArfUFsnoqcoQE2hPrnRmaDTsePNUCc4LUZhdnvtPgJkEC7kl
Oa0yi8XzmEDHLgkprIf1rOJHBbh26Kf+zxT5obcHNZlib88KM1VDwk3vYZrXsw6d
TAjED21lMDayhpZsGDemxHzm86G1K4IZqzAf0+v68XkQmzPAASgDFsQzqokbL1JE
HHV6hTRZkKJ6La7Jco0JaM9ddCZxcQ==
-----END CERTIFICATE-----
subject=/C=US/ST=Texas/L=Dallas/O=SoftLayer Technologies, Inc/OU=SoftLayer Technologies, Inc./CN=s3-api.us-geo.objectstorage.softlayer.net
issuer=/C=US/O=GeoTrust Inc./CN=GeoTrust SSL CA - G3
---
No client certificate CA names sent
---
SSL handshake has read 4886 bytes and written 589 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : AES256-SHA
    Session-ID: 521B3BFC1C2820B07E058156D098ADC9BE9E8F72ABFBF88AEB097131A8F3D88D
    Session-ID-ctx: 
    Master-Key: 03190F1C7D46DAADC507A5183AB06DE2BAC5495CD44051321A3CF6A42C4716D62085B1DDF9D1E7B7BBA5D784AB557830
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    Start Time: 1496393416
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---

SSL error

With certifi installed:

import requests
requests.get('https://maps.googleapis.com/maps/api/geocode/json?address=%s' % '58 Rue de la Verrerie, 75004 Paris, Francia')
SSLError: [Errno 1] _ssl.c:510: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

Without certifi installed:

import requests
requests.get('https://maps.googleapis.com/maps/api/geocode/json?address=%s' % '58 Rue de la Verrerie, 75004 Paris, Francia')
<Response [200]>

In [1]: import requests

In [2]: r = requests.get('https://google.com')

In [3]: r
Out[3]: <Response [200]>

With certifi installed

In [1]: import certifi

In [2]: import requests

In [3]: r = requests.get('https://google.com')
---------------------------------------------------------------------------
SSLError                                  Traceback (most recent call last)
<ipython-input-3-b153ef5a6d9b> in <module>()
----> 1 r = requests.get('https://google.com')

/home/ovapi/app/env/local/lib/python2.7/site-packages/requests/api.pyc in get(url, params, **kwargs)
     68
     69     kwargs.setdefault('allow_redirects', True)
---> 70     return request('get', url, params=params, **kwargs)
     71
     72

/home/ovapi/app/env/local/lib/python2.7/site-packages/requests/api.pyc in request(method, url, **kwargs)
     54     # cases, and look like a memory leak in others.
     55     with sessions.Session() as session:
---> 56         return session.request(method=method, url=url, **kwargs)
     57
     58

/home/ovapi/app/env/local/lib/python2.7/site-packages/requests/sessions.pyc in request(self, method, url, params, data, headers, cookies, files, auth, timeout, allow_redirects, proxies, hooks, stream, verify, cert, json)
    486         }
    487         send_kwargs.update(settings)
--> 488         resp = self.send(prep, **send_kwargs)
    489
    490         return resp

/home/ovapi/app/env/local/lib/python2.7/site-packages/raven/breadcrumbs.pyc in send(self, request, *args, **kwargs)
    295             })
    296         try:
--> 297             resp = real_send(self, request, *args, **kwargs)
    298         except Exception:
    299             _record_request(None)

/home/ovapi/app/env/local/lib/python2.7/site-packages/requests/sessions.pyc in send(self, request, **kwargs)
    607
    608         # Send the request
--> 609         r = adapter.send(request, **kwargs)
    610
    611         # Total elapsed time of the request (approximately)

/home/ovapi/app/env/local/lib/python2.7/site-packages/requests/adapters.pyc in send(self, request, stream, timeout, verify, cert, proxies)
    495         except (_SSLError, _HTTPError) as e:
    496             if isinstance(e, _SSLError):
--> 497                 raise SSLError(e, request=request)
    498             elif isinstance(e, ReadTimeoutError):
    499                 raise ReadTimeout(e, request=request)

SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:590)

Python 2.7.12
certifi==2017.1.23
requests==2.13.0
Ubuntu 14.04

python -m certifi

Consider:

https://twitter.com/kantrn/status/461700611415617536