Creating an intermediate CA with a cross-signed and self-signed certificates.

[sde...@box.com]

We have a use case where we need to create an intermediate CA (representing a service) with a pair of keys, and have it receive a cross-signed cert from its parent, and a self-signed cert from itself. The cross-signed cert and key are used to sign identity certificates for 'servers' of that service. The self-signed cert is used by OpenSSL based 'clients' to establish trust with the aforementioned 'servers', i.e. allow only servers which represent that service. We cannot have OpenSSL based clients trust instead the intermediate CA's cross-signed cert and chain (down to root) since that means the clients would trust any server presenting a chain to that root.

We have a legacy CA that does the above, however, we've now moving to Vault and doing the following to accomplish that:

1. Mount a pki backend A that logically represents a service.
2. Generate Root in A to create a self-signed cert and making sure the private key is returned.
   
3. Mount a pki backend B representing the same service.
4. Create a CSR from the private key and cross-sign from the parent.
5. Submit the cross-signed cert and private key as CA config on B.
6. Securely destroy the private key from local store so that the only copy remains in Vault.
   
7. Servers receive their identity certs from B.
8. Clients build their trust stores from A.

The problem with the approach above is that it exposes the private key that has to be securely destroyed in step #6. A better approach would have been the following:

1. Mount a pki backend A representing the service.
2. Generate Root in A to create a self-signed cert and making sure the private key remains internal.
3. Mount a pki backend B representing the service.
4. Either generate a CSR or use the bare certificate from A and have it cross-signed by the parent.
   
5. Set the signed certificate on B (no private key).
6. Servers receive their identity certs from B.
7. Clients build their trust stores from A.

However, AFAIK there are two issues with the steps above:

1. Vault doesn't have an API to do step #4. There no way for a backend to return a CSR for an *existing* pair of keys. If we were to use the bare certificate, there is no API to cross-sign by a parent. The Sign Self-Issued API comes close, however, it doesn't replace the issuer while signing.
   
2. Vault doesn't support persisting *just* a certificate (without a private key) as in step #5.

Any ideas or recommendations on how we can improve the private key handling and yet be able to persist a cross-signed cert and a self-signed cert as two separate pki backends in Vault?

Thanks,

Shrenik

p.s. If OpenSSL would be able to handle trust chains like Java, we wouldn't have had to create self-signed intermediate certs.

[Jeff Mitchell]

Hi there,

My guess is you are using a version of Vault prior to 0.8.3; step #4
should work with sign-self-issued in 0.8.3. See this thread
(https://groups.google.com/d/msg/vault-tool/giP69-n2o20/FfhRpW1vAQAJ)
for way more info about it than you probably want.

Best,
Jeff

> --
> This mailing list is governed under the HashiCorp Community Guidelines -
> https://www.hashicorp.com/community-guidelines.html. Behavior in violation
> of those guidelines may result in your removal from this mailing list.
>
> GitHub Issues: https://github.com/hashicorp/vault/issues
> IRC: #vault-tool on Freenode
> ---
> You received this message because you are subscribed to the Google Groups
> "Vault" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to vault-tool+...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/vault-tool/819be3fb-6a55-44da-ad62-4a7eebfb03eb%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[sde...@box.com]

Thanks. Any recommendations for holding just a certificate in a Vault backend?