Using own CA's w/Python (update_tables.py, etc.)

Started by NOYB, December 20, 2017, 11:48:02 PM

Previous topic - Next topic
December 25, 2017, 01:55:01 PM #15 Last Edit: December 25, 2017, 11:08:27 PM by NOYB
It's an ugly duckling hack, but it's functional with the hash dir.  See attached patch.

If first connection attempt fails it then tries again with verify set to the hash dir.  A tacky hack.

To get hash filename for certs with PHP:
$crt_inf = openssl_x509_parse(base64_decode($crt));
$cert_hash_filename = $crt_inf['hash'] . ".0";


What can be done to get the requests module to try additional certificate store(s) instead of exclusively the Certifi store?

It seems like the best solution would be for Certifi to try additional certificate store(s) when a match is not found in its own bundle.  But don't see an obvious way to do that to the Certifi code.

There must be a better way than another connection attempt with a different certificate store specified.  Functional but unseemly.  At least the second connection attempt is only done to my "own" servers.

Quote from: NOYB on December 30, 2017, 12:16:08 AM
What can be done to get the requests module to try additional certificate store(s) instead of exclusively the Certifi store?

It seems like the best solution would be for Certifi to try additional certificate store(s) when a match is not found in its own bundle.  But don't see an obvious way to do that to the Certifi code.

Certifi seems to be only some code returning the path to its bundled cacert.pem.

Quote from: NOYB on December 30, 2017, 12:16:08 AM
There must be a better way than another connection attempt with a different certificate store specified.  Functional but unseemly.  At least the second connection attempt is only done to my "own" servers.
In theory the certificates could be added from config.xml

Quote from: fabian on December 30, 2017, 09:02:45 AM
In theory the certificates could be added from config.xml

Adding custom system certs to the distributed Certifi bundle has it own baggage issues.  Amongst them not being a system wide solution.  Objective is for system config CA certs to be trusted by not only Python requests, but everything that supports secure connections (notifications, custom DynDNS, URL table updates, etc.).

With exception of URL table updates (Python requests) they all have native support for using a hash dir (capath) fallback when a cert match is not found in the bundle.

Been using this for quite awhile to trust own CA's from the system config.  But Python requests exclusively using Certifi bundle is a barrier.