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.

Security

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.

EJBCA Requirements

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.

Features

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 Commands

Instance Configuration

Example command to configure one instance of the plugin in Vault:

vault write ejbca/config/TLSServer pem_bundle=@admin-bundle.pem url=https://ejbca.example.com:8443/ejbca/ejbca-rest-api/v1 cacerts=@admin-TLS-chain.pem caname=TLSAssuredCA certprofile=TLSServer eeprofile=InternalTLSServer

The above 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

Usage

Example command to issue a certificate through Vault:

vault write ejbca/enrollCSR/TLSServer csr=@csr.pem 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 .