Public API to retrieve cert key and cert chain files written to the fs separately

[webknjaz]

Usually at high-level web servers expose separate configuration options for a certificate file, a private key file, and a certificate chain file.

Currently trustme forces users to use one file for both certificate file and its key file (as it aio-libs/aiohttp@c180800#diff-3ba621217225120eff2c061666b8043cR284) and use CA cert for chain option.

From the API perspective, it looks confusing to any humble human being who isn't proficient in TLS.

When one looks at such tests they're puzzled: why options named explicitly as key and cert receive the same var? maybe it's a bug? what's going on here?
Same for cert chain: why does it look like instead of some mysterious chain file there's a certificate or the CA?

Proofs:

• https://github.com/cherrypy/cheroot/blob/d31adfe/cheroot/ssl/__init__.py#L24
• https://github.com/cherrypy/cheroot/blob/d31adfe/cheroot/ssl/builtin.py#L91
• https://github.com/cherrypy/cheroot/blob/d31adfe/cheroot/ssl/pyopenssl.py#L241
• https://github.com/cherrypy/cherrypy/blob/e10b984/cherrypy/_cpserver.py#L104-L112
• https://github.com/aio-libs/aiohttp/blob/master/aiohttp/worker.py#L188-L191
• https://github.com/pallets/flask/blob/master/flask/cli.py#L733-L738

I think this use case deserves corresponding public APIs in place. What do you think?

[njsmith]

Same for cert chain: why does it look like instead of some mysterious chain file there's a certificate or the CA?

I don't think this is right. When presenting a chain, you normally don't include the root (CA) cert, only the intermediate + leaf certs. And including the leaf and intermediate certs together in the same file is very standard, isn't it? It's easier operationally to deal with one file instead of several, and if you have multiple certs then it's better to specify each leaf+intermediates together, instead of specifying two leafs here and two chains there and then somehow having to figure out which leaf goes with which chain. I notice that the Apache mod_ssl docs describe the SSLCertificateChainFile directive as "obsolete"...

...also, looking at the aiohttp patch you linked, I don't see any cert chain configuration? There's a ca_certs config option that you're passing the CA cert to, but surely that's to configure which CAs to trust for client cert validation, nothing to do with the server cert chain?

There is a reasonable justification for keeping the private key separate from the cert, since they have different levels of sensitivity and the private key file might be password-protected. None of that really applies for trustme's use cases of course. You're right that passing the same file to two different options is a bit confusing, though I feel like the problem here is the server software for making this pointlessly confusing, given that they're all perfectly capable of reading everything out of a single file :-).

Oh well, I guess that's life.

I think the actual proposal here boils down to: adding a LeafCert.cert_chain_pem attribute, to go with the existing private_key_pem and private_key_and_cert_chain_pem attributes? Sure, why not, that seems harmless enough.

[webknjaz]

Apparently, it looks like we probably misuse cafile in Cheroot: https://github.com/cherrypy/cheroot/blob/d31adfe/cheroot/ssl/builtin.py#L104

While aiohttp uses it correctly: https://github.com/aio-libs/aiohttp/blob/master/aiohttp/worker.py#L191

wrt APIs in frameworks, I agree that it needs improvements and I think I'll work on it in Cheroot/CherryPy and aiohttp, but right now I wanted a less confusing way of integrating trustme with them :) TLS is hard sometimes and its current state in Python libs proves this.

So yes, I guess for now cert_chain_pem would probably work.