Skip to main content
banner image
venafi logo

Patterns for a Vault Integration with Venafi [Part 1]

Patterns for a Vault Integration with Venafi [Part 1]

silver vault against a sky blue background
January 8, 2020 | Jeremy Gerson of HashiCorp, Ben Rogers and Ryan Treat of Venafi

Overview: HashiCorp Vault is a security platform that addresses the complexity of managing secrets across distributed infrastructure. The current state at many organizations is referred to as “secret sprawl,” where secret material is stored in a combination of point solutions, confluence, files, post-it notes, etc. Vault is a solution for eliminating the sprawl, while providing a common API and flexible authentication methods for cloud-native and legacy workflows. Some common use cases for Vault are storage of existing database credentials, app credentials, SSH keys, cloud access keys, etc. Vault also supports dynamic creation of secrets on demand for the cloud, databases, and can act as a Certificate Authority providing dynamic short-lived PKI certificates.

In the same way that Vault has become a standard in the world of secrets management, Venafi has become a standard platform for providing centralized policy control, and visibility and automation for the lifecycle of machine identities including public and private SSL/TLS certificates.

Together Venafi and HashiCorp make it easy for DevOps teams to go fast and Security teams to get the visibility, intelligence and policy enforcement they require to protect the business.

This blog will explore the integration methods currently available between Vault and Venafi.

As businesses operate in multicloud or hybrid models, they require a set of standard, common services to achieve consistency, agility and speed. Venafi and HashiCorp together, aim to provide a consistent platform that enables teams to move fast and safely, while providing freedom of choice and agility over where applications run.

The Solution

The integration options for Vault and Venafi appear in the form of Vault plugins: Venafi Secrets Engine (vault-pki-backend-venafi) and Venafi Monitor Engine (vault-pki-monitor-venafi).

The pki-backend is a plugin for Vault which allows certificate requests to be fulfilled directly by Venafi on behalf of 40+ CA’s. In this model, Vault provides the common API for DevOps teams to perform certificate requests, while the Venafi platform fulfills the requests. Since each request for a certificate is fulfilled by Venafi, latency between the platforms should be considered.


The pki-monitor is another plugin for Vault which allows Vault issued certificates to be governed by Venafi policy and is the focus of this guide. The plugin can monitor Vault issued certificates when Vault operates as an intermediate or root CA. For this discussion, Vault will function as an intermediate CA from an internal root Microsoft CA. (Note that Microsoft CA is being used as an example only and could be replaced with another certificate authority.) If you are familiar with the native pki engine in Vault, the workflow to setup and operate the pki-monitor plugin is similar. The added benefit with this approach is that PKI policy is centrally defined in Venafi, downloaded to Vault during plugin setup, and enforced during the certificate generation request to Vault without the added latency of Venafi fulfilling the request. PKI security policies are rules defined in Venafi which dictate the allowed values of each field on the certificate, like common_name, organization, etc. Auditability and visibility are maintained via Venafi on any certificate generated by Vault.


Additional details about the workflows between Vault and Venafi can be found in this whitepaper

Let’s get started!

Working with the vault-pki-monitor-venafi plugin:


  • Venafi Trust Protection Platform
  • HashiCorp Vault

This guide will offer a script for running Vault locally for testing. When deploying to production it is recommended to follow HashiCorp’s deployment guide Optionally, an existing Vault development environment may be used.

Venafi Configuration

Step 1:

Access the Microsoft PKI and create a sub authority template. This template allows Venafi to ask for a sub authority to be created and issued through the Microsoft PKI. (Note that Microsoft is being used as an example only).





Step 2:

Access Venafi and create the template which allows Venafi to issue a subordinate CA through the Microsoft PKI. In the example below, the template is called “Vault SubCA Template.” Template definition parameters such as validity period and renewal period may be adjusted as required.



Step 3

Create folders in Venafi to house the Vault related use cases.

Create the HashiCorp Vault folder

Create the folder Policy\Certificates\HashiCorp Vault.

This folder contains all relevant policy controls for Vault and all certificates issued by or through Vault. A hashicorp_svc user is created for Vault which should be granted View and Read Permissions for this folder.


Create the Vault Issued folder

Create the folder \Policy\Certificates\HashiCorp Vault\Vault Issued. All certificates that the Vault SubCA creates will live in this folder. The hashicorp_svc user should be granted View, Read, Write, and Create permissions here.


Set and lock the policy to Monitoring.

Ensure that CSR generation is Unlocked.

Specify Subject DN information and lock any values set.

Apply Allowed Domains and configure whether to allow Wildcard certificates in this policy. Note that today Venafi cannot enforce the “Allow Duplicate Common and Subject Alternative Name” within Vault so this value has no effect.

Set the key parameters as required. In this example, we are requiring RSA 2048-bit keys.

Disable SSL/TLS Validation and lock the value to Yes.


Create the VaultSubCA Folder

Create the folder \Policy\Certificates\HashiCorp Vault\VaultSubCA.

Optionally, this folder can be configured with a Stage 500 issuance approval or an adaptable workflow in order to limit the ability to create a SubCA. In this example we will not have a workflow applied to this folder.

This folder houses the Vault SubCA certificate. Vault will be connecting to Venafi Trust Protection Platform (TPP) and downloading the Venafi Policy values and applying them to a Vault Role for issuing certificates in subsequent steps. The hashicorp_svc user should have View, Read, Write, Create, Rename, and Revoke permissions on this folder.

Choose Contacts, Approvers, and Set the Management Type to Enrollment. Lock each of these values.

Set and lock the CSR Generation to User Provided CSR.

Set and lock Subject DN information according to your organization policies.

Set and lock key size requirements for the Issuing CA.

Set and lock the CA Template to the Vault SubCA Template.

Turn off Network Validation by setting Disable SSL/TLS Validation to Yes. Lock this value.

The Venafi configuration is now complete.


Vault Configuration

Step 1: Download, unzip and install the Vault plugin for the desired operating system from along with its checksum for the binary. There are two versions of binaries, optional and strict. The “optional” version allows certificates to be issued by the Vault CA when there is no Venafi policy applied whereas the “strict” will return an error when there is no Venafi policy applied, “policy data is nil.”

Step 2: Prepare and start Vault on a suitable system. This step can be skipped if Vault is already running.

Step 3: Initialize, Unseal and login to Vault. This example uses Shamir’s Secret Sharing for unsealing. In production it is common to use one of the autounseal methods as discussed here This step can be skipped if Vault is already running.

Step 4: Install vault-pki-monitor plugin


Step 5: Initialize SubCA, generate CSR towards Venafi and define roles in Vault. During the SubCA initialization process, policy is downloaded from Venafi which specifies the allows values for the SubCA.

Set the following environment variables with Venafi credentials prior to running the script.

export TPP_ADDR=

export TPP_USER=serviceaccountuser

export TPP_PASS=serviceaccountpassword

Set the following environment variable with an address of the Vault server which can be reached by Venafi in order to publish a CRL.



Be sure to change the hostname in the example below to the Vault instance URL. Venafi will use this information to check revocation during the nightly revocation check process.

The following policy which is downloaded from Venafi and applied to the SubCa role enforces the fields values which may be requested on each certificate.


Step 6: Test SubCA

Configuration is complete, and certificates may be requested from Vault. In the example below alpha.venafi.example, beta.venafi.example, and delta.venafi.example are allowed by policy.

The request for a certificate with delta.venafis.example is rejected due to policy (venafis spelled incorrectly).

A list of certificates generated by Vault can be viewed, and certificates can be revoked as needed. Venafi checks Vault’s CRL endpoint once every 24 hours.

The Venafi Platform is aware of any certificate generated by Vault, “alpha.venafi.example”, “beta.venafi.example”, “delta.venafi.example”, as well as the history of any certificate generated multiple times, such as “delta.venafi.example” in the second screenshot below. Any certificate which was not allowed due to Venafi policy which was previously downloaded is blocked at Vault, and Venafi will not be aware of it.





Venafi is the platform for enforcing policy and providing a common auditing platform for all types of certificates. This guide leveraged Venafi to impose policy on Vault and monitor the certificates generated by Vault as a SubCA.


Trial our HashiCorp Vault integration today. Try Venafi as a Service for free.


Related posts

Like this blog? We think you will love this.
cloud cyber security, cloud security, zero trust security
Featured Blog

Why Zero Trust in the Cloud Requires On-demand Machine Identity Management

Assigning security parameters As machines are spun up in the cloud, we need to assign s

Read More
Subscribe to our Weekly Blog Updates!

Join thousands of other security professionals

Get top blogs delivered to your inbox every week

Subscribe Now

See Popular Tags

You might also like

TLS Machine Identity Management for Dummies

TLS Machine Identity Management for Dummies

Certificate-Related Outages Continue to Plague Organizations
White Paper

CIO Study: Certificate-Related Outages Continue to Plague Organizations

About the author

Jeremy Gerson of HashiCorp, Ben Rogers and Ryan Treat of Venafi
Jeremy Gerson of HashiCorp, Ben Rogers and Ryan Treat of Venafi

Jeremy Gerson is Staff Solutions Engineer at HashiCorp, and previously worked at Quali and RAD Data. Ben Rogers is a Senior Solutions Architect at Venafi, where he has been for nearly 10 years. Ryan Treat is a Product Manager at Venafi with over 22 years of experience in enterprise technology. 

Read Posts by Author
get-started-overlay close-overlay cross icon
get-started-overlay close-overlay cross icon
Venafi Risk assessment Form Image

Sign up for Venafi Cloud

Venafi Cloud manages and protects certificates

* Please fill in this field Please enter valid email address
* Please fill in this field Password must be
At least 8 characters long
At least one digit
At last one lowercase letter
At least one uppercase letter
At least one special character
* Please fill in this field
* Please fill in this field
* Please fill in this field

End User License Agreement needs to be viewed and accepted

Already have an account? Login Here

get-started-overlay close-overlay cross icon

How can we help you?

Thank you!

Venafi will reach out to you within 24 hours. If you need an immediate answer please use our chat to get a live person.

In the meantime, please explore more of our solutions

Explore Solutions

learn more

Email Us a Question

learn more

Chat With Us

learn more