The SSLContext.load_cert_chain() method should accept a password argument to use if the private key is encrypted.  Currently it always uses OpenSSL's default password callback, which prompts the user interactively for a password.

I've attached a patch that adds an extra password argument, which can be either a string, bytes, bytearray, or a function to call to get the password.

> I've attached a patch that adds an extra password argument, which can be
> either a string, bytes, bytearray, or a function to call to get the password.

It seems a bit strange to me to accept string types or callable in the same argument.  If it just supported strings, people could still write password=somefunction(), right?

> It seems a bit strange to me to accept string types or callable in the 
> same argument.  If it just supported strings, people could still write
> password=somefunction(), right?

The function is only called if the private key is encrypted and a 
password is necessary.  This allows the code to only prompt for a 
password if it is actually needed.

This also parallels the OpenSSL C API, which only accepts a function to
get the password.  I added support for plain strings as a convenience.  
The string argument will be ignored if the file is not encrypted.

Here's a new patch that accepts any callable.  The old patch only accepted
actual function objects.

Thanks for the patch. This is a generally useful functionality and the patch looks mostly good.
I have a couple comments:

- in _pwinfo_set(), you need to decref password_bytes when you're finished
- you check the password size in _password_callback() but not in _pwinfo_set(), is it expected? is the size limit only meaningful with a callback rather than a predefined password?

Good catch.  Here's an updated patch to fix the missing decref in
_pwinfo_set()

The length check in _password_callback() applies to both callback
functions and predefined strings.  The C API always uses a callback,
so _password_callback() is used even when the python caller has passed
in a string.  We can't check the length in _pwinfo_set() since it depends
on the buffer length argument that openssl will pass to
_password_callback().

I have one last concern: what is the character set of an OpenSSL password? I see you are using PyUnicode_AsEncodedString(x, NULL, NULL), which basically returns a utf8-encoded bytestring. Since the OpenSSL doc don't specify anything, we could accept it as a best-effort thing.
Or perhaps we should use PyUnicode_EncodeFSDefault(), which uses the "filesystem encoding", which is usually the same as the current terminal (assuming the password is typed on a terminal).

OpenSSL doesn't appear to do any special handling for i18n, and just
treats the strings as binary data.  It uses fgets() to read the password
from the terminal, so it will receive it however the terminal encodes
it.

It's not clear to me that PyUnicode_EncodeFSDefault() is quite the right
thing to do.  The initfsencoding() routine seems different from how
initstdio() works (which checks the PYTHONIOENCODING environment
variable, and then appears to fall back to os.device_encoding()).

I'm leaning towards just updating the docs to specify that if a string
is supplied it will be encoded using UTF-8.  I'm happy to do either way
you recommend, though.

Here's a patch with updates to the documentation to more fully specify the
behavior of the password field, including specifying that strings will be
encoded using UTF-8.

New changeset cdc6c1b072a5 by Antoine Pitrou in branch 'default':
Issue #12803: SSLContext.load_cert_chain() now accepts a password argument
http://hg.python.org/cpython/rev/cdc6c1b072a5

Your latest patch was committed, thank you!