Enable writing PKI certificate and private key data to a user specified Vault path(s)

[allisonis]

Is your feature request related to a problem? Please describe.
When generating CA (if exported type) or leaf certificates in issued by Vault a user must manually manage private key and certificate data. Operators must go through multiple steps to safely store the private key, initial CSR, and all certificate data, etc.

There are cases where a user must load CA certificates generated by Vault into external systems.. When generating a intermediate with Vault using the exported type the CSR and private key are returned to the caller. This information must be stored in some way on the machine where the request originates from. Once the CSR is generated the caller must save the CSR to a file and send it to Vault in order to have the "root" sign the intermediate CSR. This creates a complicated dance of modifying and managing CA certificate key material, certificate data, and attempting to safely store it.

To support automation or to generally save the certificate and key material, users may write the data returned to the caller in a static vault path to pull from.

Describe the solution you'd like
When generating an intermediate or issuing a certificate a user should be able to paas a flag that would re direct the response from the request, i.e csr and private_key, certificate data to a user specified Vault path(s).

Many users or automated tooling will pull the sensitive key material from a secret path at run time. This feature would enable operators to not have to manually handle key material and certificates and but directly interact with Vault and improve the workflow overall. As well as reduce the risk associated with managing CA Certificates, or private keys manually.

This feature request would improve the workflow for any type of certificate generation supported in the PKI backend.

Example 1:
Generate CSR and private key and write output to a user specified Vault path using a new param output-vault-path.

vault write pki_int/intermediate/generate/internal common_name="myvault.com Intermediate Authority" ttl=43800h *output_vault_path=secret/pki/:name*

The response containing the csr,and private_key would be written to specific vault paths under the user specified output-vault-path

Example 2:
Sign intermediate and write output to a user specified Vault path using a new param output-vault-path.
In this example you could also allow a user to specify the previously defined path where the CSR was saved in example 1 as a new csr_path parameter instead of a reference to a locally stored file.

$ vault write pki/root/sign-intermediate csr=@pki_int.csr OR *csr_path=secret/pki/:name/csr* use_csr_values="true" *output-vault-path*="secret/pki/:name" 

The response containing the certificate, expiration, ca_chain, issuing_ca, serial_number would be written to specific vault paths under the user specified output-vault-path

Example 3:
Issue certificate with new param output-vault-path

$ vault write pki_int/issue/example-dot-com \
    common_name=blah.example.com  \
    output-vault-path="secret/pki/:name" 

The response containing the certificate, private_key, private_key_type, expiration, ca_chain issuing_ca, serial_number would be written to specific vault paths under the user specified output-vault-path

Explain any additional use-cases
Any PKI method that generates certificates or key material.

• Generate Certificate: pki/issue/:name
• Generating Intermediates:/pki/intermediate/generate/:type
• Sign Intermediate: pki/root/sign

[drawks]

This would be a cool feature. I will point out that you can use response wrapping to effectively do a very similar work flow to what you've detailed.

[allisonis]

I have had to create tooling to handle this limitation but I think it could improve the security and usability of the PKI backend significantly!

[allisonis]

bump

[captain-kark]

Regarding my ☝️ issue comment reference, in my case, a duplicate transit/ endpoint containing the certificate authority's private key would be ideal. Being able to rely on continued enforcement of vault's "no export of private key matter" policy present in the pki and transit features of vault is a much better fit for me, as opposed to using a secrets mount. I would like to set a pki mount's root certificate as "internal", as well as any intermediaries, but still be allowed the option of encrypting and decrypting arbitrary secret payloads with a single set of certificate pairs.

Should I create another issue that directly asks for the pki plugin to include support for encrypting and decrypting using the root certificate?

[HridoyRoy]

Thanks @captain-kark and @allisonis for filing this issue. I'll take a look at the newly filed issue linked above, as well as this one, and see if we can roll a joint solution out.

[anoncam]

I see this issue is open, is there a way currently in Vault managed with terraform to write that key data to a kv store path?

The use case is PKI with Notary

[sgmiller]

I'm curious in everyone's use cases why the consumer who ultimately wants that private key is not the one calling the PKI secrets engine to generate it? In the setups I've seen the receiving end (who the private key owner is talking to) is configured to accept any key whose public certificate is signed by a particular CA (Vault). At which point there is no need for key distribution which seems like what this is trying to enable?

[bdhayco]

Just found this today and this capability is just what I require.
My organization has x.509 certs for user based entities and for our machine to machine back end comms we currently use Aethylred/keymaster in puppet to generate, store, manage and distribute keypairs to our servers. We are currently rewriting the puppet code from 3.x to 6.x and will loose this capability due to a rewrite of the Puppet CA.

I am working on a solution where Puppet will call Vault and request a Keypair be generated. But we will need to store the keypair as a KV value, should the need arise to redistribute the pair to a server.
We don't use a HSM to store keys.
My code would have had to rely on generating the key pair, and then writing the keypair back to Vault as a KV value and retrieve them as required.
Our PKI requirements cover pretty much everything, encryption of data, code signing, digital signatures, validation.