HashiCorp Vault is a popular product to manage secrets and when using microservices at scale, there are many services and secrets to manage. HashiCorp Vault includes a built-in Certification Authority (CA), however using that standalone CA will create a separate PKI not connected to the corporate PKI. A separate PKI is often not desired in organizations as it will not meet regulatory or other security requirements.

The following describes different ways to incorporate Vault PKI into a controlled corporately managed PKI:

Issuing from an External PKI Instead of Built-in Vault CA

Using a Vault secrets plugin it is possible to fully replace the build-in Vault CA with an external CA. This enables full management and control of the PKI, separated from the management of Vault, while clients use Vault for all secrets management and the front-end to the CA. The complete PKI, Root CAs, and Subordinate CAs are then subject to the PKI Certificate Policy (CP) and Certificate Practice Statement (CPS) and remain in compliance. To achieve all this, you need a Vault secrets plugin that makes using EJBCA as transparent as using the built-in Vault CA. 

There are several plugins available to achieve this:

Issuing a Sub CA to Vault

To fully incorporate Vault into your organization's policies, and ensure compliance and control of all certification authorities, it is possible to issue a Subordinate CA in Vault, from a Root CA in EJBCA. This enables control of the Subordinate CA from the corporate PKI, making it known and possible to stay in compliance. For more information on how to create a subordinate CA in Vault getting it signed by a Root CA in EJBCA, see Subordinate HashiCorp Vault CA to EJBCA Root.