| Version |   |
| Project |     |
| CI |  |
| Code |     |
Certifi patch for using Linux cert trust stores
WHAT: certifi-linux wraps certifi, but instead of distributing a certificate like certifi does, it uses the Linux system trust store.
WHY? The requests module depends on certifi and uses it for TLS. certifi distributes the collection of root certificates provided by Mozilla for Python deployments. In some cases, especially in an enterprise setup it is necessary to use the certificates which are shipped with the OS.
Python 3.10 introduced truststore which can be used in combination with requests or httpx.
import httpx
import truststore
truststore.inject_into_ssl()
httpx.get(...)import requests
import ssl
import truststore
from requests.adapters import HTTPAdapter
class OsCertsAdapter(HTTPAdapter):
def init_poolmanager(self, connections, maxsize, block=False):
ctx = truststore.SSLContext(ssl.PROTOCOL_TLS_CLIENT)
return super().init_poolmanager(connections, maxsize, block, ssl_context=ctx)
session = requests.Session()
session.mount("https://", OsCertsAdapter())
session.get(...)certifi-linux is purposed for Linux! For Windows take a look at pip-system-certs.
pip install certifi-linuxcertifi-linux just needs to be installed. Afterwards certifi.where() or $ python3 -m certifi will return the path to the system store. Hence all dependent projects like requests will do as well.
I am trying to keep tests up to date with endoflife.
Tested distros are:
- alpine:3,
- ubuntu:focal, ubuntu:jammy, ubuntu:noble,
- debian:buster, debian:bullseye, debian:bookworm,
- fedora:33, fedora:>=34
- centos:stream9,
- (manually) rhel:37, rhel:38
Yet untested: Arch, Slackware, OpenWRT, FreeBSD, SUSE, gentoo, ...
certifi-linux monkey patches certif.where and certifi.contents by using wrapt. When called, it searches in the defined set of possible certificate bundle paths for a match.
Tested: yes✅, no❌
| Cert Bundle Path | Linux Distribution |
|---|---|
/etc/ssl/cert.pem |
fedora >= 34✅, RHEL✅, alpine✅, centOS Stream✅, Arch❌, OpenWRT❌, FreeBSD❌ |
/etc/ssl/ca-bundle.pem |
openSUSE❌ |
/etc/ssl/certs/ca-certificates.crt |
Debian✅, Ubuntu✅ |
/etc/pki/tls/cert.pem |
fedora <= 33✅ |
/etc/pki/tls/cacert.pem |
OpenELEC❌ |
/etc/pki/tls/certs/ca-bundle.crt |
Fedora✅, RHEL✅ |
/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem |
CentOS✅, RHEL✅ |
The idea behind certifi-linux is the same as behind certifi-system-store. certifi-system-store replaces the dist-info of certifi with its own dist-info. This approach needs a specific order of installation for a succesful patch. When installed as a dependency among a whole set of dependencies this is hard to ensure and replacing dist-infos can mess up virtual environments.
pip-system-certs solves the same problem with a different approach. It monkey patches the requests.adapters.HTTPAdapter and uses ssl.create_default_context to load the OS certs. This works fine on Windows but has shown limitations on Linux as it does not work in some cases.
Viewed from the outside, certifi-debian is doing the exact same thing like certifi-linux but just for debian. certifi-system-store-wrapper also does the same but with the necessity to set an environment variable.
There are variants for other programming languages: Go, R
Credits go to the developers of certifi-system-store and pip-system-certs as certifi-linux is highly influenced by these two projects.
certifi-linux is distributed under the terms of the MIT license.