Urllib3: use client cert from keychain in contrib.securetransport

[jcapayne]

There doesn't appear to be a method of signaling urllib3.contrib.securetransport to use a client certificate and key that's stored in keychain as opposed to passing one in parameters. One of the benefits of using securetransport should be to use the keychain to store secrets including the client cert/key.

[haikuginger]

I'm +0 on this; it would be nice to have, but I'm not sure what an implementation that provides it but retains the overall goal of the current implementation (API compatibility between different SSL backends) would look like.

@jcapayne, I guess one starting point would be to ask how you would expect to indicate to urllib3 that it ought to use a certificate and key found in the keychain, rather than in the filesystem?

[jcapayne]

In order to keep compatibility, maybe signal in the filename being passed for cert and key? Start it with an invalid filename character ('*') and then the CN of the cert desired?

[Lukasa]

@jcapayne I completely agree, this was always intended to be something we would end up supporting.

For now, I think the best thing to do is to use our nascent support for ssl_context. When you call urllib3.contrib.securetransport.inject_into_urllib3 we create a custom SSLContext-alike class that has a number of methods on it. These methods must cover the uses of SSLContext that urllib3 itself needs, but we could absolutely add some extra ones for users to call. Maybe it would be something like this:

urllib3.contrib.securetransport.inject_into_urllib3()

ctx = urllib3.util.ssl_.create_urllib3_context()
ctx.load_keychain_client_certs(label='my keychain label')

http = urllib3.PoolManager(ssl_context=ctx)

What do you think?

[jcapayne]

That sounds perfectly reasonable to me.