How to bring PKI and Transit engine together?

Vault
1

I want to generate a private key and certificate in the Vault PKI secrets engine. The private key should stay inside Vault and never leave it. Then I want to use this private key with the Transit secrets engine, for signing data. Is that possible?

1 Like
2

The transit engine has a number of keys that supports signing and signature verification. Is there a specific reason/use case you want to use the PKI engine’s X.509 certs instead?

  • ed25519: Ed25519; supports signing, signature verification, and key derivation
  • ecdsa-p256: ECDSA using curve P-256; supports signing and signature verification
  • ecdsa-p384: ECDSA using curve P-384; supports signing and signature verification
  • ecdsa-p521: ECDSA using curve P-521; supports signing and signature verification
  • rsa-2048: 2048-bit RSA key; supports encryption, decryption, signing, and signature verification
  • rsa-3072: 3072-bit RSA key; supports encryption, decryption, signing, and signature verification
  • rsa-4096: 4096-bit RSA key; supports encryption, decryption, signing, and signature verification
3

Well, verifying a digital signature with an X.509 certificate is an extremely common use-case (maybe the most common one?). It puzzles me that this seems to be not possible with Vault.

My current use-case is code-signing. I have a “manifest” file (a few lines of ascii text, containing among others hashes of the code bundles) and need to sign this file and pack the manifest, the signature and the signer’s certificate into a CMS (PKCS#7) file.

I can think of two workarounds:

A) I use the PKI engine to create the private key and the certificate. Both are exported from Vault. Then I import the private key in the transit engine.

B) I use the transit engine to create the private and public key. Only the public key is exported. Then I manually assemble a CSR and have it signed by the transit engine (requiring heavy ASN.1 fiddling - openssl won’t help me at all!), and finally send the CSR to the PKI engine and have a certificate created there.

Solution A is insecure, because the private key leaves Vault. Solution B is quite complicated to implement. Both solutions seem kind of strange to me, because I cannot keep the key and its certificate together in one place.

4

Ahh that makes sense, I don’t have too much experience in that area, but check out this blog on code signing with HashiCorp Vault and GitHub Actions and the corresponding GitHub repo for a demo.

It uses the PKI engine to issue short lived code signing certificates, but the actual signing takes place in the Github action, rather than Vault.

5

No, this isn’t possible directly. The Vault PKI secrets engine generates private keys, but it doesn’t integrate with the Transit secrets engine for signing. The private key in PKI stays within Vault, but it’s meant for issuing certificates, not cryptographic signing.

If you need signing capabilities, you should generate the key directly in the Transit engine, which is designed for encryption and signing without exposing the private key. You can’t reuse a PKI private key in Transit.