# certifi-linux
[](https://pypi.org/project/certifi-linux)
[](https://pypi.org/project/certifi-linux)
-----
**Table of Contents**
- [About](#about)
- [Installation](#installation)
- [Usage](#usage)
- [Compatibility](#compatibility)
- [Implementation](#implementation)
- [Related Projects](#related-projects)
- [Credits](#credits)
- [License](#license)
## About
**WHAT:** `certifi-linux` wraps [certifi](https://pypi.org/project/certifi/), but instead of distributing a certificate like `certifi` does, it uses the Linux system trust store.
**WHY?** The [requests](https://pypi.org/project/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.
## Installation
`certifi-linux` is purposed for **Linux**! For Windows take a look at [pip-system-certs](https://gitlab.com/alelec/pip-system-certs).
```console
pip install certifi-linux
```
## Usage
`certifi-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.
## Compatibility
I am trying to keep tests up to date with [endoflife](https://endoflife.date/).
Tested distros are:
- alpine:3,
- ubuntu:focal, ubuntu:jammy, ubuntu:mantic,
- debian:buster, debian:bullseye, debian:bookworm,
- fedora:33, fedora:34, fedora:38, fedora:39,
- centos:stream9,
- (manually) rhel:37, rhel:38
Yet untested: Arch, Slackware, OpenWRT, FreeBSD, SUSE, gentoo, ...
## Implementation
`certifi-linux` monkey patches `certif.where` and `certifi.contents` by using [wrapt](https://pypi.org/project/wrapt/). When called, it searches in the defined set of possible certificate bundle paths for a match.
### Cert Path Candidates
Tested: yes✅, no❌
| Cert Bundle Path | Linux Distribution |
| ------------------------------------ | -------------------------------------------------------------------------------- |
| `/etc/ssl/cert.pem` | fedora >= 3.4✅, RHEL✅, alpine✅, centOS Stream✅, Arch❌, OpenWRT❌, FreeBSD❌ |
| `/etc/pki/tls/cert.pem` | fedora <= 3.3✅ |
| `/etc/ssl/certs/ca-certificates.crt` | Debian✅, Ubuntu✅ |
| `/etc/ssl/ca-bundle.pem` | openSUSE❌ |
## Related Projects
The idea behind `certifi-linux` is the same as behind [certifi-system-store](https://github.com/tiran/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](https://gitlab.com/alelec/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](https://pypi.org/project/certifi-debian/) is doing the exact same thing like `certifi-linux` but just for debian. [certifi-system-store-wrapper](https://pypi.org/project/certifi-system-store-wrapper/) also does the same but with the necessity to set an environment variable.
## Credits
Credits go to the developers of `certifi-system-store` and `pip-system-certs` as `certifi-linux` is highly influenced by these two projects.
## License
`certifi-linux` is distributed under the terms of the [MIT](https://spdx.org/licenses/MIT.html) license.
Raw data
{
"_id": null,
"home_page": null,
"name": "certifi-linux",
"maintainer": null,
"docs_url": null,
"requires_python": ">=3.7",
"maintainer_email": null,
"keywords": "certifi,certificates,certs,linux,requests,ssl,tls",
"author": null,
"author_email": "Birkenbach Marius <wesci@web.de>",
"download_url": null,
"platform": null,
"description": "# certifi-linux\n\n[](https://pypi.org/project/certifi-linux)\n[](https://pypi.org/project/certifi-linux)\n\n-----\n\n**Table of Contents**\n\n- [About](#about)\n- [Installation](#installation)\n- [Usage](#usage)\n- [Compatibility](#compatibility)\n- [Implementation](#implementation)\n- [Related Projects](#related-projects)\n- [Credits](#credits)\n- [License](#license)\n\n## About\n\n**WHAT:** `certifi-linux` wraps [certifi](https://pypi.org/project/certifi/), but instead of distributing a certificate like `certifi` does, it uses the Linux system trust store.\n\n**WHY?** The [requests](https://pypi.org/project/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.\n\n## Installation\n\n`certifi-linux` is purposed for **Linux**! For Windows take a look at [pip-system-certs](https://gitlab.com/alelec/pip-system-certs).\n\n```console\npip install certifi-linux\n```\n\n## Usage\n\n`certifi-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.\n\n## Compatibility\n\nI am trying to keep tests up to date with [endoflife](https://endoflife.date/).\n\nTested distros are:\n\n- alpine:3,\n- ubuntu:focal, ubuntu:jammy, ubuntu:mantic,\n- debian:buster, debian:bullseye, debian:bookworm,\n- fedora:33, fedora:34, fedora:38, fedora:39,\n- centos:stream9,\n- (manually) rhel:37, rhel:38\n\nYet untested: Arch, Slackware, OpenWRT, FreeBSD, SUSE, gentoo, ...\n\n## Implementation\n\n`certifi-linux` monkey patches `certif.where` and `certifi.contents` by using [wrapt](https://pypi.org/project/wrapt/). When called, it searches in the defined set of possible certificate bundle paths for a match.\n\n### Cert Path Candidates\n\nTested: yes\u2705, no\u274c\n\n| Cert Bundle Path | Linux Distribution |\n| ------------------------------------ | -------------------------------------------------------------------------------- |\n| `/etc/ssl/cert.pem` | fedora >= 3.4\u2705, RHEL\u2705, alpine\u2705, centOS Stream\u2705, Arch\u274c, OpenWRT\u274c, FreeBSD\u274c |\n| `/etc/pki/tls/cert.pem` | fedora <= 3.3\u2705 |\n| `/etc/ssl/certs/ca-certificates.crt` | Debian\u2705, Ubuntu\u2705 |\n| `/etc/ssl/ca-bundle.pem` | openSUSE\u274c |\n\n## Related Projects\n\nThe idea behind `certifi-linux` is the same as behind [certifi-system-store](https://github.com/tiran/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.\n\n[pip-system-certs](https://gitlab.com/alelec/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.\n\nViewed from the outside, [certifi-debian](https://pypi.org/project/certifi-debian/) is doing the exact same thing like `certifi-linux` but just for debian. [certifi-system-store-wrapper](https://pypi.org/project/certifi-system-store-wrapper/) also does the same but with the necessity to set an environment variable.\n\n## Credits\n\nCredits go to the developers of `certifi-system-store` and `pip-system-certs` as `certifi-linux` is highly influenced by these two projects.\n\n## License\n\n`certifi-linux` is distributed under the terms of the [MIT](https://spdx.org/licenses/MIT.html) license.\n",
"bugtrack_url": null,
"license": null,
"summary": "Certifi patch for using Linux cert trust stores",
"version": "1.0.0",
"project_urls": {
"Documentation": "https://github.com/m-birke/certifi-linux#readme",
"Homepage": "https://github.com/m-birke/certifi-linux",
"Issue": "https://github.com/m-birke/certifi-linux/issues",
"Source": "https://github.com/m-birke/certifi-linux"
},
"split_keywords": [
"certifi",
"certificates",
"certs",
"linux",
"requests",
"ssl",
"tls"
],
"urls": [
{
"comment_text": null,
"digests": {
"blake2b_256": "27634bdad90ec895961a6569f73fa48a964dfaca2eb2bc2b31ebe678d915a6bb",
"md5": "f9dcd1a66e94dec7b3e11264b26eda09",
"sha256": "3360717204a59bbb758afcb020af072508de2a72c733356c122ef042367b1a8c"
},
"downloads": -1,
"filename": "certifi_linux-1.0.0-py3-none-any.whl",
"has_sig": false,
"md5_digest": "f9dcd1a66e94dec7b3e11264b26eda09",
"packagetype": "bdist_wheel",
"python_version": "py3",
"requires_python": ">=3.7",
"size": 5217,
"upload_time": "2024-02-20T12:17:27",
"upload_time_iso_8601": "2024-02-20T12:17:27.860851Z",
"url": "https://files.pythonhosted.org/packages/27/63/4bdad90ec895961a6569f73fa48a964dfaca2eb2bc2b31ebe678d915a6bb/certifi_linux-1.0.0-py3-none-any.whl",
"yanked": false,
"yanked_reason": null
}
],
"upload_time": "2024-02-20 12:17:27",
"github": true,
"gitlab": false,
"bitbucket": false,
"codeberg": false,
"github_user": "m-birke",
"github_project": "certifi-linux#readme",
"travis_ci": false,
"coveralls": false,
"github_actions": true,
"lcname": "certifi-linux"
}
JSON
