Vault: Transit Secret Backend: x509 support?

[ewdurbin]

Feature Request:

PKI Secret Backend provides similar endpoints to the Transit Secret Backend for signing arbitrary data with the Authority's secret key.

I suppose another option is to add the ability for the Transit Backend to sign/create Self Signed x509 Certificates with the stored Private Key but it seems out of scope for that backend.

It's all kind of fuzzy and I'd love more thoughts on supporting this kind of use case.

References:

A merge addressing #1986 would probably get me way closer... since indeed my use case is to support JWTs.

Here's a gist describing the pickle I'm in. https://gist.github.com/ewdurbin/aa041ca1537cd39162c030bc47049ccf

tl;dr: Clients only eat delicious x509 Certificates, while the Transit backend only supplies bare Public Keys.

[benjumanji]

I was looking at this recently (slightly different use case). This is totally doable. The trick is to realise that you can use transit to sign the CSR.

1. Create a keypair in transit (say p256)
2. Grab the public key
3. Create a CSR embedding that public key
4. Sign that CSR using transit
5. Get the pki backend to create a certificate using the CSR.

Congrats, you now have a crisp X.509 certificate for your signing key in transit.

[ewdurbin]

@benjumanji that's effectively where I'm planning to go but got lost in ASN.1 and the RFCs for how to actually construct the payload for signing and combine it with the completed x509 certificate manually. do you have some example code?

[benjumanji]

what language are you working in? I can offer you some java / bouncy castle?

[ewdurbin]

@benjumanji Python, but I'm pretty apt at code reading :) anything is appreciated.

[benjumanji]

Ok, well the trick to this working is that how it works exactly is hidden by bouncy castle!

I also lied, it's scala. But the main point is that we create the csr as usual with bouncy castle, then supply a content signer that delegates vault.

https://gist.github.com/benjumanji/99addd0f97e2ff3b29a2d026b1c71499

[ewdurbin]

Thanks @benjumanji! Combined with some ASN.1 tips I got from someone else I think I can cobble something together.

I do think somehow supporting the basic use case of being able to sign arbitrary data _and_ present an x509 certificate (signed by whomever) is still valid for Vault.

[jefferai]

I think the thing that's not clear to me is what the inputs/outputs look like. Sure, signing arbitrary data is one thing, but figuring out what should be in a returned X509 cert in all the various fields is another.

[ewdurbin]

@jefferai I agree, that is poorly specified.

I think some tunables on a Transit key might do the trick? Similar to how convergent_encryption, derived, exportable, allow_plaintext_backup are set in the current API.

[ewdurbin]

For the purposes of the Transit backend specifically, it seems like common_name and self_signed tunables for calls to the Create Key endpoint POST /transit/keys/:name would be sufficient and explicit enough.

If those tunables are set, calls to GET /transit/keys/:name could provide a certificate in the response as well containing a valid x509 certificate.

If self_signed is not set, but common_name is, a similar api for pulling CSRs and POST /pki/intermediate/set-signed from the PKI backend could even allow for more interesting setups.

[benjumanji]

Sorry to stick my oar in here: but transit will already sign arbitrary things. Direct X509 support seems a bit anti-composition. Transit is a primitive. It should be possible to compose it with other things, but I think tacking more onto it directly would be a mistake. If you go this route eventually every bell and whistle that goes into x509 could reasonably be suggested as an addition. If anything, I'd suggest an endpoint in pki land that allows you to use a named key from transit as part of the process of generating a certificate.

I get that certs are horrible (lots going on). Having spent a week knees-deep in the java crypto apis I have no wish to return any time soon, but I don't think adding api-surface to transit is a good solution to this problem.

_runs away_

[jefferai]

A couple of thoughts:

• I'm not against X509 being a format returned for a public key from transit, but am concerned about the fields/format
• A _very privileged_ operation could be to allow a transit path to ingest a CSR and use it exactly as is for all fields except the actual key, where it substitutes its own public/private keys, and spit out a self-signed CA cert
• This could then potentially be used with https://www.vaultproject.io/api/secret/pki/index.html#sign-self-issued if needed although that endpoint requires a CA cert

This all wouldn't be too hard, but at the same time I'm amenable to @benjumanji 's argument that doing these things may be layering in some very easy-to-get-wrong stuff for some functionality that is not common. I don't really know how often this would be useful.

[ewdurbin]

Here's a gist that captures my proof of concept work around: https://gist.github.com/ewdurbin/aa041ca1537cd39162c030bc47049ccf

Ultimately I agree that this feels like pressing too hard on the Transit Backend. It also seems to maybe be pressing too hard on the PKI backend to ask of it to do arbitrary signing, as the current API seems strictly concerned with CSR signing and Certificate Issuance.

I do want to avidly throw my support behind some built in solution that allows for this without either hackish bit banging (as showcased in the above gist) or grabbing an ASN.1 library (the right solution for this work around).

Mentioning very easy-to-get-wrong stuff, I'd argue that implementing such things in Vault itself is obviously better if there are more folks than I asking for it 😉.

[jefferai]

Well. There are _two_ people asking for it. :-D

[benjumanji]

I do think there is a case for this kind of thing that might crop up more if people knew you could use vault to make it happen. You want certificates for asserting identity and you want private keys for producing holder-of-key proofs that attach assertions to identities. Keeping all secret key material in vault for managing this is _incredibly_ valuable. You get to avoid letting non-experts write crypto, you get strong audit and you get strong policy.

Think of all the certificates currently hanging around in the LDAP stores sad and unused because _really_ using them is often such a pain in the tail.

I don't know what this would look like in vault, but I do think there is a potentially untapped vein for corporate usage.

The only reason I have been able to convince the last few companies I have worked at to really _do_ certificates for internal tls is because of how smooth vault makes it.

[diepes]

Hi i stumbled on this thread, looking for Vault transit + csr.

would a plugin for openssl engine supporting vault solve a lot of the questions/suggestions ?
https://www.openssl.org/blog/blog/2015/10/08/engine-building-lesson-1-a-minimum-useless-engine/

The use case I have is creating a CSR, and powering a ssl web server, with a private key never leaving Vault to satisfy audit/security requirements.

Also: https://svn.python.org/projects/external/openssl-1.0.1c/README.ENGINE

[jefferai]

@diepes If the private key never leaves Vault, how do you propose to have the web server serve requests?

Usually it's the other way around, where the private key never leaves the web server, and the CSR is signed by Vault.

[diepes]

@jefferai, a web request arrives at the web server, it uses OpenSSL, that in turn uses a "-engine vault" for any encryption/decryption that is offloaded through the Vault transit secrets engine.

The reason this might be feasible/scalable is that it will only involve vault for the initial PKI handshake the rest of the web session is symmetric and can be handled by the web server without any access to the private key.

Another benefit would be that OpenSSL can then handle the creation of CSR, and Signing, only using the Vault transit as needed for the actual crypto involving the private key.

I also found an example where AWS does precisely this. https://docs.aws.amazon.com/cloudhsm/latest/userguide/ssl-offload-overview.html

For a company using Vault this will enable them to use there SSL/TLS certificate on multiple web server, but still keep the private key safely stored in Vault, and not have a copy on each web server.

[jefferai]

@diepes Such an engine would be awesome, but it's not the ask in this thread.

[diepes]

@jefferai , well it would solve the x509 support for Transit, as x509 would be done with OpenSSL, and that is the question?
"Transit Secret Backend: x509 support?"

[trishankatdatadog]

What a small world! Do you have working code for this BTW @ewdurbin? 🙂

[ewdurbin]

@trishankatdatadog here are the utilities used to construct/sign/squash-together the x509 cert from transit backend: https://github.com/cabotage/cabotage-app/blob/358b07f55cd6befed9865394e17049afcd914cb6/cabotage/utils/cert_hacks.py

here are the methods on the class that interacts with vault/transit to burp out a signing_certificate: https://github.com/cabotage/cabotage-app/blob/67996f3e5534b0eddcde840fce131f972d157078/cabotage/server/ext/vault.py#L67-L92

here is how that is used in the application (to do docker registry auth junk): https://github.com/cabotage/cabotage-app/blob/master/cabotage/utils/docker_auth.py

[trishankatdatadog]

@trishankatdatadog here are the utilities used to construct/sign/squash-together the x509 cert from transit backend: https://github.com/cabotage/cabotage-app/blob/358b07f55cd6befed9865394e17049afcd914cb6/cabotage/utils/cert_hacks.py

here are the methods on the class that interacts with vault/transit to burp out a signing_certificate: https://github.com/cabotage/cabotage-app/blob/67996f3e5534b0eddcde840fce131f972d157078/cabotage/server/ext/vault.py#L67-L92

here is how that is used in the application (to do docker registry auth junk): https://github.com/cabotage/cabotage-app/blob/master/cabotage/utils/docker_auth.py

Thanks very much, @ewdurbin! Cc @mithaler, you might find this useful...