Use case: External CA, signed certificate

[strarsis]

Some thoughts are LE and possible use of vault in that process,
Pardon the partial confusion in the text.

The setup is a reverse HTTP proxy/LB with HTTP2/HTTPS support + SSL/TLS termination,
hence requiring signed certificate to work properly.
I try to figure out how vault can be used/fit in to improve security and maintainability.

With the existing vault PKI secret backend it seems that vault not only stores but also generates/transforms secrets, like signing certificates with the stored CA private key.

Now with certificates signed by external CAs:
The private key is generated on demand on the server and should ideally never leave the system.
Only its CSR leaves the system for signing the private key by an external CA (e.g. Let's Encrypt).
*Though for auditing it may be acceptable/useful re-using the same private key for new certificates.

Also the CSR can be stored for easier revocation/auditing.

One reason where it could make sense storing the signed ready to be used certificate in vault
would be the rate limit (Let's Encrypt) or cost (non-free CA solutions) of signing new private keys where they hadn't actually expired yet.
However, when the private key or signed certificate leaves the server anyway (to vault),
one could argue that vault could also handle the CSR to a third party CA, and revoking stored certs?
Would this unnecessarily expose vault to more public networks?

Additionally, those signed certificates will have a limited life period, vault could watch + act about it, like automatically renewing or sending a warning to audit that TLS/SSL cannot work anymore (and its associated services) because the certificate is now invalid.

There are non-ACME supporting CAs that require UI login/interaction and CAs like Let's Encrypt that require proof by currently serving a validation file by HTTP from the domain(s) the certificate should be used for.

Possible uses for vault:

1. Generating the private key itself (enforcing key strength, key information by vault?)
2. Storing an existing private key for reusal (some may want this, e.g. for revocation/auditing).
3. Handling the CSR for external CA (like ACME or using some adapter/plugin for CA GUI/auth against CA GUI)
4. Storing the signed certificate for later retrieval
5. Warning on certificate life timeout (to audit) / automatic renewal?
6. Retrieving the signed certificate (e.g. for use by a TLS/SSL/QUIC (HTTPS/HTTP2/SPDY) server)
7. Optionally revoking stored signed certificates (also by contacting the external CA, either ACME or its GUI again (adapter)).

What shouldn't be actually the responsibility of vault?

[jefferai]

Hi @strarsis ,

With the existing vault PKI secret backend it seems that vault not only stores but also generates/transforms secrets, like signing certificates with the stored CA private key.

The PKI backend is a secret backend designed for generation -- e.g. acting as a CA. It does not store certificates other than those that it has generated, and that is partially convenience and partially so it can build CRLs. Vault generally is designed for inter-organizational use with a common authn/authz paradigm. It is well suited for organizations that need TLS internally and either have no issue with or specifically want to control their own root certificate, and that want automated ways to issue tens or thousands or hundreds of thousands of certificates for their own purposes.

Let's Encrypt is also a CA, but it's designed for very different use-cases (the public Internet) with very different authn/authz paradigms.

As to your use-cases:

1. Generating the private key itself (enforcing key strength, key information by vault?)

Vault doesn't offer this kind of key generation right now, although it may in the future. The transit backend supports keys for AES operations and may eventually for asymmetric operations but it specifically does not allow the key to be exported -- that's a large part of the usefulness of it.

1. Storing an existing private key for reusal (some may want this, e.g. for revocation/auditing).

This could be stored in the generic backend right now.

1. Handling the CSR for external CA (like ACME or using some adapter/plugin for CA GUI/auth against CA GUI)

I don't think Vault will ever support this. Vault is designed to manage secrets; CSRs are not secrets, and accepting CSRs to then send to external CAs imposes a number of possible outcomes and error conditions that would need to be handled.

1. Storing the signed certificate for later retrieval

This can already be handled in the generic backend.

1. Warning on certificate life timeout (to audit) / automatic renewal?

For an externally-generated certificate stored in Vault, this is not possible. For a certificate generated within Vault, the expiration is returned along with the certificate, and can be used in alerting.

1. Retrieving the signed certificate (e.g. for use by a TLS/SSL/QUIC (HTTPS/HTTP2/SPDY) server)

A server with appropriate permissions could retrieve any stored value in Vault, including a stored certificate.

1. Optionally revoking stored signed certificates (also by contacting the external CA, either ACME or its GUI again (adapter)).

This will not be supported, for the same reason that sending CSRs to external CAs will not be supported.

[juliangamble]

Additional discussion here: https://groups.google.com/forum/#!forum/vault-tool