Comment by general_failure

Here's the current process:

Generate key, Generate CSR, Send CSR, Receive Certs from CA, Verify ownership, Install certs

Presumably their command line client creates the key, the CSR, sends the CSR, then gets back the certs (at least I'd hope so). I'd be happy to use a vetted command line utility which did that, or even just parts of that process, if I were sure the private key were not transmitted. It's just automating stuff which with current CAs needs to be done manually.

The tool will gather the domains, use the CA API to validate ownership, obtain the certs (which cannot be unilaterally created since they are based on a public/private key pair) and manage their expiry.

That's a bit more then "giving us a cert"

That wouldn't be safe, because then they would have access to your private key and impersonate you. Having you (indirectly via their script) generate the key and submit the public key for signing means your private key never leaves the premises.

It's primarily because of the interactive challenge to prove that you control the domains you're requesting the cert for.

If you want, the client can just give you the cert at the end instead of installing it. In the common case for a user who's not currently comfortable with the process, the client is automating several things -- generating a private key and CSR, proving control of the domain, and installing the key and cert in the server.