On 2017-03-01 15:59, David Cournapeau wrote:
Hi there,
This is hopefully the right mailing for this question. We are shipping our own python interpreter in our product, and following some discussions on https://mail.python.org/pipermail/python-dev/2017-January/147282.html, we understand shipping the certificate from certifi in our python is the best approach on Linux/OS X.
Yeah, it's the easiest option for you. I don't necessarily agree it's the best option.
Unfortunately, ssl hardcodes at compilation time the default location of certificate. I could workaround this at the python level by patching ssl.SSLContext.load_default_certs to look as follows:
Small correction: The location of the certs is hard-coded in OpenSSL. The ssl module simply uses OpenSSL's defaults on non-Windows platforms.
def load_default_certs(...): ....
if sys.platform == "win32": ... else: prefix = os.path.normpath(sys.prefix) default_cert = os.path.join(prefix, "ssl", "cert.pem") if os.path.isfile(default_cert): self.load_verify_locations(default_cert) else: self.set_default_verify_paths()
While this seems to work, my lack of knowledge in all things related to security and ssl in particular makes me worry to patch anything in there. Is this a sane approach ? If not, is there a better way ?
You can override the default verify paths already. There is no need to monkey patch load_default_certs(). You have two options: 1) Create your own custom SSLContext with a custom trust anchor, e.g. ctx = ssl.create_default_context(cafile='...') and pass the context along. 2) Set SSL_CERT_FILE env var to override OpenSSL's default setting, see https://docs.python.org/3/library/ssl.html#ssl.get_default_verify_paths The second option may work for you. You can set the env var at any time before you create a new SSLContext object. Christian