EJBCA Plugin Integration with Hashicorp Vault
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. To incorporate Vault PKI into a controlled corporately managed PKI, you could:
- Plug into your own issuing CA using a Vault secrets plugin.
- Use the Vault provisions to root to an external CA rather than self-sign its own CA certificate.
The EJBCA Vault secrets plugin is a drop in replacement of Vault's built-in PKI, that allows you to plug Vault into your issuing CA. The plugin enables you to use Vault to issue certificates, just as you would with the Vault built-in CA, but the issuance comes from EJBCA.
The EJBCA secrets engine plug-in is not supported and maintained as part of the EJBCA product. It should not be considered production ready. The secrets plugin for Keyfactor Command (see Other Options) is a production ready and maintained plugin.
There is also a secrets plugin for Keyfactor Command, which in turn integrates natively with EJBCA. Available for download on Keyfactor GitHub.
The EJBCA Vault plugin uses the EJBCA REST API to communicate with EJBCA, allowing the EJBCA instance to be anywhere reachable with HTTPS connections. The EJBCA REST API uses mutually authenticated TLS connections (HTTPS/mTLS).
To EJBCA, Vault acts as a PKI Registration Authority (RA) and EJBCA's role based access control allows you to control Vault's capabilities in the EJBCA instance in detail. Vault will not be able to issue certificates from other managed CAs other than those allowed in the EJBCA instance.
To issue certificates from EJBCA through Vault, EJBCA has the same requirements as issuing through any RA.
- A CA in EJBCA that can issue the desired type of certificates, using the desired algorithm.
- A Certificate Profile, configured to issue the desired type of certificates from the CA.
- An End Entity Profile, configured to issue certificates with the desired Subject fields from the CA, using the Certificate Profile.
- A Role with Access Rules, describing what Vault is allowed to issue.
- A Role Member (for Vault) belonging to the corresponding Role.
- A client certificate and private key, used to authenticate the Role Member over mutually authenticated TLS.
The EJBCA Vault plugin is easy to configure and allows you to:
- Configure multiple instances in Vault, to issue different types of certificates, i.e. from different CAs and profiles.
- Issue certificates from a CSR generated by the client.
- List certificates issued and available in Vault.
- Revoke certificates, also removing them from the Vault list.
Installation and Usage
The following provides example commands. For more information on installing and using the EJBCA Vault plugin, refer to Keyfactor GitHub where the plugin also is available for download.
Example command to configure one instance of the plugin in Vault:
vault write ejbca/config/TLSServer firstname.lastname@example.org url=https://ejbca.example.com:8443/ejbca/ejbca-rest-api/v1 cacerts=@admin-TLS-chain.pem caname=TLSAssuredCA certprofile=TLSServer eeprofile=InternalTLSServer
write operation will connect to EJBCA for a connecting test and set the configuration properties for issuing.
The read operation will display the following configuration properties (as written to JSON in Vault).
vault read ejbca/config/TLSServer
Example command to issue a certificate through Vault:
vault write ejbca/enrollCSR/TLSServer email@example.com username=user
Issued certificates are stored to the
issued path in Vault. The list operation will return the serial numbers of all the certificates in the secrets engine for the specific CA profile.
vault list ejbca/issued/TLSServer
Example command to revoke a certificate through Vault:
vault write ejbca/revokeCert/TLSServer serial=2F79E1875F2F6D276BB619EB5FE9B499D71F645E reason=AFFILIATION_CHANGED
After revocation, the certificate is removed from Vault storage.
For more information and detailed command examples, refer to Keyfactor GitHub.