tls: certificate management flow could avoid accepting private key

The current management flow for TLS certificates for the external API is that people upload a private key and certificate chain, both in PEM format. As @kc8apf pointed out in chat, this is problematic. Modern security best practice is that private keys never leave the device they're generated on because doing so risks leaking the keys in transit. It's unclear how big this risk is for us. But by accepting the private key unencrypted, that means the customer must store the private key unencrypted (at least briefly) in order to send it to us, which also isn't great.

I'm not sure if fixing this is an MVP-blocker. However, this is an area of the API that customers are likely to want to automate so they can automate certificate renewal. So changing this after shipping might be particularly annoying for customers.

See also #2367 -- it may be worth doing this at the same time as that.

Start by reviewing the external API's TLS certificate management flow and the related discussion in issue #2367. The issue does not name implementation files or tests; first clarify the certificate-renewal design and define what secure key handling should replace the current PEM private-key upload before implementation.