Currently, SSL module [1] only allows file path as input.
That led to a lot of libraries only accept file path to a local file.
This lead to issues when people who trigger this python code, didn't have any right to access a local file. Here are two examples:

1. In multi-cloud orchestration service design, you (as an operator) like to create resources in another cloud with orchestration service(like Heat in OpenStack), but you like to set up SSL for this connection. You should not allow accessing a local file from the first cloud (where the orchestration service is running). And you can't guarantee the first cloud provider allow you to inject a Cert file in their environment. In this case we need to allow operators to input their own cert information and parse it to ssl option for request.

2. Serverless. In serverless, we give a python code and cloud will provide an environment to run it. We can try to inject cert when we try to create environment for operators, but it will be more secure to directly pass it to python instead of store it around.

The first case is what we're looking for an answer. Didn't look into the design for the second case, but I guess that might face the same issue.


[1] https://github.com/python/cpython/blob/master/Modules/_ssl.c#L3683