HashiCorp Vault PKI Secrets Engine

By Khimananda Oli | Last reviewed: August 2026

Managing TLS certificates manually is a primary cause of preventable outages and security audit failures across both cloud-native and hybrid infrastructure. The HashiCorp Vault PKI Secrets Engine solves this by acting as an internal Certificate Authority that dynamically issues short-lived X.509 certificates via API or CLI. Instead of distributing static PEM files that expire unexpectedly, you integrate Vault directly into your deployment pipelines and service meshes. This guide covers the exact configuration steps, role definitions, and operational safeguards needed to run a production-grade internal PKI.

How do you enable and configure the HashiCorp Vault PKI Secrets Engine?

Before issuing any certificates, you must establish a proper trust hierarchy. A common mistake in non-production setups is using the root CA directly for signing; in practice, always use an intermediate CA to limit blast radius if the signing key is compromised. For teams managing broader secrets workflows, understanding this hierarchy is as critical as mastering general secrets management with HashiCorp Vault.

Step 1: Enable the PKI secrets engine

Mount the PKI engine at a dedicated path. Using separate mounts for different environments or domains prevents policy collisions.

vault secrets enable -path=pki pki
vault secrets tune -max-lease-ttl=87600h pki

Step 2: Generate the Root CA (ideally offline)

In production, generate the root CA outside of Vault, then import it. For lab or development environments where convenience outweighs strict compliance:

vault write -field=certificate pki/root/generate/internal \
    common_name="Example Corp Internal Root CA" \
    ttl=87600h > root_ca.crt

Step 3: Configure the Intermediate CA

Create a separate mount for the intermediate CA that will handle daily signing operations.

vault secrets enable -path=pki_int pki
vault secrets tune -max-lease-ttl=43800h pki_int

vault write pki_int/intermediate/generate/internal \
    common_name="Example Corp Intermediate CA" \
    ttl=43800h > intermediate.csr

# Sign the intermediate CSR with the root CA
vault write pki/root/sign-intermediate [email protected] \
    format=pem_bundle ttl=43800h > signed_intermediate.pem

# Import the signed certificate back into the intermediate mount
vault write pki_int/intermediate/set-signed certificate=@signed_intermediate.pem

Step 4: Configure URLs for CRL and OCSP

Clients need to verify revocation status. Set these before issuing any leaf certificates.

vault write pki_int/config/urls \
    issuing_certificates="https://vault.example.com/v1/pki_int/ca" \
    crl_distribution_points="https://vault.example.com/v1/pki_int/crl"

What are the best practices for defining PKI roles and policies?

Roles in the HashiCorp Vault PKI Secrets Engine act as templates that constrain what certificates can be issued. Never allow unrestricted issuance; every parameter should be explicitly bounded. This is especially important when integrating with Kubernetes, where pod identity and certificate lifecycle are tightly coupled — see Kubernetes secrets management done right for complementary patterns.

• Restrict TTLs aggressively: Set max_ttl to the shortest practical duration. 24–72 hours is standard for microservices; 30 days maximum for legacy systems.
• Lock down allowed domains: Use allowed_domains and allow_subdomains=true rather than wildcards. Avoid allow_any_name outside of testing.
• Enforce key parameters: Specify key_type (RSA or EC), key_bits, and key_usage to prevent weak certificate requests.
• Separate roles per workload type: Web servers, databases, and service mesh sidecars should have distinct roles with appropriate constraints.

vault write pki_int/roles/web-server \
    allowed_domains="svc.example.com,internal.example.com" \
    allow_subdomains=true \
    max_ttl="72h" \
    key_type="ec" \
    key_bits="256" \
    key_usage="DigitalSignature,KeyEncipherment" \
    ext_key_usage="ServerAuth" \
    require_cn=false \
    allowed_uri_sans="" \
    enforce_hostnames=true

Pair each role with a Vault policy that grants only create and update capabilities on that specific role path. Never grant list or read on the entire PKI mount to application workloads.

How does Vault PKI compare to cert-manager and traditional CAs?

Choosing between the HashiCorp Vault PKI Secrets Engine, cert-manager, and commercial/public CAs depends on your trust boundary, automation maturity, and compliance requirements. Each serves a distinct purpose, and many organizations use multiple solutions simultaneously.

In practice, use Vault PKI for all internal service-to-service communication and database encryption. Reserve cert-manager with Let's Encrypt for public ingress controllers. Traditional enterprise CAs remain relevant only when hardware-backed HSMs or specific regulatory frameworks mandate them. For teams running observability stacks that rely on mutual TLS, combining Vault PKI with Prometheus and Grafana monitoring ensures certificate expiry metrics feed directly into your alerting pipeline.

How do you automate certificate rotation with Vault PKI in production?

The value of short-lived certificates disappears if rotation isn't fully automated. Manual renewal reintroduces the same human error and outage risk you're trying to eliminate.

1. Use native integrations first: Consul Connect, Istio, and Linkerd have built-in Vault PKI support. Configure the control plane to fetch certificates directly — no sidecar scripts needed.
2. For standalone applications: Use envconsul or vault-agent as a supervisor process. These handle authentication, renewal, and file writing atomically without application code changes.
3. In CI/CD pipelines: Issue build-time certificates for artifact signing or test environments using AppRole auth. Never embed long-lived tokens; use wrapped tokens with single-use enforcement.
4. Monitor expiry proactively: Export certificate metrics from Vault and set alerts at 50% and 75% of TTL. Don't wait for renewal failures to discover broken automation.
5. Test revocation regularly: Automate CRL/OCSP endpoint checks in your staging environment. A revoked certificate that clients can't validate against is functionally identical to an expired one.

# Example: vault-agent template for automatic cert rotation
template {
  source      = "/etc/vault-agent/cert.tpl"
  destination = "/etc/app/tls/cert.pem"
  perms       = "0600"
  command     = "systemctl reload app.service"
}

template {
  source      = "/etc/vault-agent/key.tpl"
  destination = "/etc/app/tls/key.pem"
  perms       = "0600"
}

Implementing Vault PKI for Audit-Ready Infrastructure

Deploying the HashiCorp Vault PKI Secrets Engine correctly transforms certificate management from an operational liability into a compliance asset. Every issuance is logged, every role enforces least-privilege constraints, and every certificate expires before it becomes a forgotten risk. Start with a properly segmented root/intermediate hierarchy, define restrictive roles from day one, and wire automation before your first production certificate is issued. If your team needs help designing a PKI strategy that satisfies SOC 2 or ISO 27001 auditors while keeping developer velocity high, reach out to discuss your infrastructure.