vault-pki-backend-venafi | Venafi PKI Secrets Engine plugin for HashiCorp Vault | TLS library

Before certificates can be issued, you must complete these steps to configure the Venafi secrets engine:.
Create the directory where your Vault server will look for plugins (e.g. /etc/vault/vault_plugins). The directory must not be a symbolic link. On macOS, for example, /etc is a link to /private/etc. To avoid errors, choose an alternative directory such as /private/etc/vault/vault_plugins.
Download the latest vault-pki-backend-venafi release package for your operating system. Unzip the binary to the plugin directory. Note that the URL for the zip file, referenced below, changes as new versions of the plugin are released. $ wget https://github.com/Venafi/vault-pki-backend-venafi/releases/download/v0.0.1/venafi-pki-backend_v0.0.1+1_linux.zip $ unzip venafi-pki-backend_v0.0.1+1_linux.zip $ mv venafi-pki-backend /etc/vault/vault_plugins :pushpin: NOTE: Release binaries are built and tested using the latest generally available version of Vault at the time. Backward compatibility with older versions of Vault is typical but not confirmed by testing.
Update the Vault server configuration to specify the plugin directory: plugin_directory = "/etc/vault/vault_plugins" :pushpin: NOTE: If plugin directory is a symbolic link, Vault responds with an error:bookmark:. If you're configuring on a MacBook, /etc is default symlinked to /private/etc. To prevent the error from occurring, change the plugin_directory to a non-symlinked directory. For example "/private/etc/vault/vault_plugins". If you make this change, keep it in mind as you go through the remaining steps.
Start your Vault using the server command.
Get the SHA-256 checksum of the venafi-pki-backend plugin binary: $ SHA256=$(sha256sum /etc/vault/vault_plugins/venafi-pki-backend| cut -d' ' -f1)
Register the venafi-pki-backend plugin in the Vault system catalog: $ vault write sys/plugins/catalog/secret/venafi-pki-backend \ sha_256="${SHA256}" command="venafi-pki-backend" Success! Data written to: sys/plugins/catalog/secret/venafi-pki-backend :pushpin: NOTE: If you get an error that says "can not execute files outside of configured plugin directory", it's probably because you didn't set the plugin directory correctly with a non-symlinked directory as mentioned earlier. Also, make sure this change is reflected when calling for the SHA-256 checksum.
Enable the Venafi secrets engine: $ vault secrets enable -path=venafi-pki -plugin-name=venafi-pki-backend plugin Success! Enabled the pki-backend-venafi secrets engine at: venafi-pki/
Configure a Venafi secret that maps a name in Vault to connection and authentication settings for enrolling certificate using Venafi. The zone is a policy folder for Trust Protection Platform or an Application name and Issuing Template API Alias (e.g. "Business App\Enterprise CIT") for Venafi as a Service. Obtain the access_token and refresh_token for Trust Protection Platform using the VCert CLI (getcred action with --client-id "hashicorp-vault-by-venafi" and --scope "certificate:manage") or the Platform's Authorize REST API method. To see other available options for the Venafi secret after it is created, use vault path-help venafi-pki/venafi/:name. Trust Protection Platform: $ vault write venafi-pki/venafi/tpp \ url="https://tpp.venafi.example" \ access_token="tn1PwE1QTZorXmvnTowSyA==" \ refresh_token="MGxV7DzNnclQi9CkJMCXCg==" \ zone="DevOps\\HashiCorp Vault" \ trust_bundle_file="/opt/venafi/bundle.pem" Success! Data written to: venafi-pki/venafi/tpp :warning: CAUTION: Do not create more than one Venafi secret for the same pair of tokens. Supplying a refresh_token allows the secrets engine to automatically obtain new tokens and operate without interruption whenever the access_token expires. This behavior is important to understand because it may require you to provide a new access_token and refresh_token if you need to modify the Venafi secret in the future (i.e. depending upon whether the original set of tokens has been refreshed by the secrets engine plugin). Having more than one Venafi secret for the same set of tokens would result in all but one Venafi secret being rendered inoperable when the token is refreshed. Venafi as a Service: $ vault write venafi-pki/venafi/vaas \ apikey="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" \ zone="Business App\\Enterprise CIT" Success! Data written to: venafi-pki/roles/vaas
Lastly, configure a role that maps a name in Vault to a Venafi secret for enrollment. To see other available options for the role after it is created, use vault path-help venafi-pki/roles/:name. Trust Protection Platform: $ vault write venafi-pki/roles/tpp \ venafi_secret=tpp \ generate_lease=true store_by=serial store_pkey=true \ allowed_domains=example.com \ allow_subdomains=true Success! Data written to: venafi-pki/roles/tpp Venafi as a Service: $ vault write venafi-pki/roles/vaas \ venafi_secret=vaas \ generate_lease=true store_by=serial store_pkey=true \ allowed_domains=example.com \ allow_subdomains=true Success! Data written to: venafi-pki/roles/vaas :pushpin: NOTE: The ttl and max_ttl role parameters can be used specify the default and maximum allowed validity for certificate requests if the Venafi CA template supports flexible validity periods. If the CA is DigiCert, Entrust, or Microsoft with Trust Protection Platform, the issuer_hint parameter is also required for ttl functionality (e.g. issuer_hint="m" for Microsoft). When issue or sign operations include the ttl parameter it overrides the role default ttl and will be constrained by the role max_ttl. :pushpin: NOTE: The zone role parameter allows multiple zones to be used with a single Venafi secret. If zone is not specified by the role, the zone specified by the Venafi secret applies.