HashiCorp Vault PKI Secrets Engine: Performance Limits, Pricing & Enterprise Alternatives

Complete guide to HashiCorp Vault PKI secrets engine — API usage, agent-inject setup, scaling limits at high concurrency, HCP Vault pricing, ACME support, and when to choose Venafi or Keyfactor instead. This page helps you run Vault PKI in production and decide when to use it versus a dedicated certificate management platform.

HashiCorp Vault PKI Secrets Engine: Performance Limits, Pricing & Enterprise Alternatives

HashiCorp Vault’s PKI Secrets Engine is a dynamic certificate authority that generates short-lived certificates on-demand through API calls. Unlike traditional certificate management platforms (Venafi, Keyfactor) that track and renew long-lived certificates from external CAs, Vault is the CA—issuing ephemeral certificates with TTLs measured in hours or days. Applications request certificates via the Vault PKI API, receive them immediately, and auto-renew before expiry. No inventory tracking, no expiry monitoring, no manual rotation.

Best fit: Cloud-native applications, Kubernetes workloads, microservices needing mTLS, DevOps teams wanting programmatic certificate generation without traditional PKI complexity.

Not suitable for: Long-lived certificates (1+ year), public CA validation (OV/EV), Windows/Active Directory environments, legacy applications that can’t auto-renew, or organizations needing turnkey certificate lifecycle management.

Key differentiator: Dynamic, short-lived certificates generated via API rather than traditional long-lived certificate management. This is a paradigm shift, not just a different vendor.

Vault PKI vs Venafi vs Keyfactor: Quick Comparison {#vault-pki-vs-venafi-vs-keyfactor}

Aspect	Vault PKI	Keyfactor Command	Venafi (CyberArk)
What it is	CA that issues certs	Management platform	Management platform
Best for	Short-lived certs, microservices	Mid-market, 10K–500K certs	Enterprise-wide, 50K+ certs
Pricing	Free (open source)	~$75K–$200K/year*	~$250K–$500K+/year*
Certificate lifespan	Minutes to days	Months to years	Months to years
Scale limit	~50K certs/day (default config)	~500K active certs	1M+ active certs
ACME support	Yes (Vault 1.14+)	Yes (native with EJBCA)	Yes
Kubernetes integration	Native (agent-inject, CSI, cert-manager)	Via orchestrators + cert-manager	Via agents
Integration ecosystem	API-driven (build your own)	50–80 + 100+ community	200+ out-of-box
Deployment	Self-hosted or HCP Vault	On-prem or SaaS	On-prem or SaaS
When NOT to use	Long-lived certs, >50K/day burst	<10K certs, simple needs	Small scale, budget-limited

*Pricing estimates vary significantly based on certificate count, features, and deployment model. Contact vendors for accurate quotes.

The fundamental distinction: Vault PKI eliminates certificate lifecycle management by making certificates ephemeral. Traditional platforms (Venafi, Keyfactor) manage the lifecycle of long-lived certificates. These are different philosophies, not just different products.

How Vault PKI Works: Core Concepts {#vault-pki-overview}

The Paradigm Shift from Traditional PKI

The easiest way to understand Vault PKI is to compare it with how traditional certificate management works:

Traditional PKI (Venafi, Keyfactor, CertCentral): Issue a certificate valid for 90–365 days. Track it in an inventory. Monitor when it expires. Renew it before expiry. Deploy the new certificate. Hope nothing falls through the cracks. Repeat thousands of times.

Vault PKI: Application calls API. Vault generates certificate valid for 1–24 hours. Application uses certificate. Certificate expires. Application calls API again. No inventory, no tracking, no manual intervention.

This works because Vault’s certificates are so short-lived that the traditional problems—expiry outages, certificate sprawl, manual rotation—simply don’t exist. A compromised certificate is valid for hours, not months. Revocation becomes academic when your CRL is effectively empty.

traditional_pki:
  certificate_lifetime: 365_days
  process:
    1_generate_csr: manual_or_automated
    2_submit_to_ca: hours_to_days
    3_receive_certificate: manual_download
    4_deploy_certificate: manual_or_automated
    5_track_expiry: monitoring_required
    6_renew_before_expiry: 30_days_before
    7_rotate_certificate: manual_deployment

vault_pki:
  certificate_lifetime: 1_hour_to_7_days
  process:
    1_api_request: "vault write pki/issue/my-role common_name=api.example.com"
    2_receive_certificate: immediate (milliseconds)
    3_use_certificate: in-memory, no disk storage needed
    4_expires: application requests new certificate automatically

  what_you_eliminate:
    - certificate_inventory_management
    - expiry_tracking_and_monitoring
    - manual_rotation_workflows
    - certificate_sprawl
    - long_blast_radius  # Compromised cert only valid briefly

PKI Secrets Engine Architecture

┌─────────────────────────────────────────────────────┐
│              HashiCorp Vault Cluster                │
│                                                     │
│  ┌────────────────────────────────────────────────┐ │
│  │         PKI Secrets Engine                     │ │
│  │                                                │ │
│  │  ┌──────────────┐      ┌──────────────────┐    │ │
│  │  │   Root CA    │      │ Intermediate CA  │    │ │
│  │  │  (Offline)   │──────│   (Active)       │    │ │
│  │  └──────────────┘      └────────┬─────────┘    │ │
│  │                                 │              │ │
│  │         ┌───────────────────────┘              │ │
│  │         │                                      │ │
│  │  ┌──────▼─────┐  ┌──────────┐  ┌──────────┐    │ │
│  │  │ Role: Web  │  │Role: API │  │Role: DB  │    │ │
│  │  │ TTL: 24h   │  │TTL: 1h   │  │TTL: 72h  │    │ │
│  │  └────────────┘  └──────────┘  └──────────┘    │ │
│  └────────────────────────────────────────────────┘ │
│                                                     │
│  ┌──────────────────────────────────────────────┐   │
│  │         Storage Backend                      │   │
│  │  (Integrated Raft, Consul, etc.)             │   │
│  └──────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────┘
                     │
         ┌───────────┴──────────┬──────────────┐
         ▼                      ▼              ▼
    ┌─────────┐          ┌──────────┐    ┌─────────┐
    │ Service │          │   API    │    │  K8s    │
    │   A     │          │ Gateway  │    │  Pods   │
    └─────────┘          └──────────┘    └─────────┘
      ↓ Request cert via API
      ↑ Receive cert immediately

Vault’s architecture separates the Root CA (which should be generated offline or stored in an HSM) from Intermediate CAs that handle day-to-day issuance. Roles define policies: allowed domains, maximum TTLs, key types, and SANs. Each role acts as a constrained template for certificate issuance.

Vault PKI API: Issuing Certificates Programmatically

The Vault PKI API is the primary interface for certificate operations. Every certificate operation—issuance, signing, revocation, CRL retrieval—is a REST API call.

Setup: Enabling and Configuring PKI

# Enable PKI secrets engine
vault secrets enable pki

# Configure max TTL (10 years for root)
vault secrets tune -max-lease-ttl=87600h pki

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

# Configure issuing and CRL URLs
vault write pki/config/urls \
    issuing_certificates="https://vault.example.com:8200/v1/pki/ca" \
    crl_distribution_points="https://vault.example.com:8200/v1/pki/crl"

# Set up intermediate CA (recommended for production)
vault secrets enable -path=pki_int pki
vault secrets tune -max-lease-ttl=43800h pki_int

vault write -format=json pki_int/intermediate/generate/internal \
    common_name="Example Intermediate CA" \
    issuer_name="intermediate-2026" \
    | jq -r '.data.csr' > pki_intermediate.csr

vault write -format=json pki/root/sign-intermediate \
    csr=@pki_intermediate.csr \
    format=pem_bundle ttl="43800h" \
    | jq -r '.data.certificate' > intermediate.cert.pem

vault write pki_int/intermediate/set-signed \
    certificate=@intermediate.cert.pem

# Create a role (policy for certificate issuance)
vault write pki_int/roles/web-server \
    allowed_domains="example.com" \
    allow_subdomains=true \
    max_ttl="720h" \
    key_type="ec" \
    key_bits=256 \
    generate_lease=true

Issuing Certificates via CLI

# Request a certificate
vault write pki_int/issue/web-server \
    common_name="api.example.com" \
    ttl="24h"

# Response includes:
# - certificate (PEM)
# - private_key (PEM)
# - issuing_ca (PEM)
# - ca_chain (PEM array)
# - serial_number
# - expiration (Unix timestamp)

Issuing Certificates via REST API

# Direct API call (equivalent to CLI above)
curl --header "X-Vault-Token: $VAULT_TOKEN" \
     --request POST \
     --data '{
       "common_name": "api.example.com",
       "ttl": "24h",
       "alt_names": "www.api.example.com",
       "ip_sans": "10.0.1.50"
     }' \
     https://vault.example.com:8200/v1/pki_int/issue/web-server

# Sign an existing CSR (instead of generating keys)
curl --header "X-Vault-Token: $VAULT_TOKEN" \
     --request POST \
     --data "{
       \"csr\": \"$(cat my.csr | sed ':a;N;$!ba;s/\n/\\n/g')\",
       \"ttl\": \"24h\"
     }" \
     https://vault.example.com:8200/v1/pki_int/sign/web-server

# List certificates
curl --header "X-Vault-Token: $VAULT_TOKEN" \
     https://vault.example.com:8200/v1/pki_int/certs

# Revoke a certificate
curl --header "X-Vault-Token: $VAULT_TOKEN" \
     --request POST \
     --data '{"serial_number": "39:dd:2e:90:b7:23:..."}' \
     https://vault.example.com:8200/v1/pki_int/revoke

# Retrieve CRL
curl https://vault.example.com:8200/v1/pki_int/crl/pem

Python Client (hvac library)

import hvac
import time
from datetime import datetime, timedelta

class VaultCertificateManager:
    """Automatic certificate renewal with Vault PKI API."""

    def __init__(self, vault_addr: str, vault_token: str, role: str, mount: str = "pki_int"):
        self.client = hvac.Client(url=vault_addr, token=vault_token)
        self.role = role
        self.mount = mount
        self.current_cert = None
        self.cert_expiry = None

    def request_certificate(self, common_name: str, ttl: str = "24h") -> dict:
        """Request new certificate from Vault PKI."""
        response = self.client.secrets.pki.generate_certificate(
            name=self.role,
            common_name=common_name,
            extra_params={"ttl": ttl},
            mount_point=self.mount
        )

        self.current_cert = {
            'certificate': response['data']['certificate'],
            'private_key': response['data']['private_key'],
            'ca_chain': response['data']['ca_chain'],
            'serial': response['data']['serial_number']
        }

        # Calculate expiry
        self.cert_expiry = datetime.fromtimestamp(response['data']['expiration'])
        return self.current_cert

    def auto_renew_loop(self, common_name: str, ttl: str = "24h"):
        """Continuously renew certificate before expiry."""
        cert = self.request_certificate(common_name, ttl)
        print(f"Initial cert issued, expires: {self.cert_expiry}")

        while True:
            time_until_expiry = (self.cert_expiry - datetime.now()).total_seconds()
            # Renew at 50% of lifetime
            renew_at = max(time_until_expiry * 0.5, 60)

            time.sleep(renew_at)
            cert = self.request_certificate(common_name, ttl)
            print(f"Renewed, new expiry: {self.cert_expiry}")
            self.reload_certificate(cert)

    def reload_certificate(self, cert: dict):
        """Signal application to reload — implementation varies."""
        with open('/etc/ssl/current.crt', 'w') as f:
            f.write(cert['certificate'])
        with open('/etc/ssl/current.key', 'w') as f:
            f.write(cert['private_key'])

# Usage
manager = VaultCertificateManager(
    vault_addr='https://vault.example.com:8200',
    vault_token='hvs.xyz123...',
    role='web-server'
)
manager.auto_renew_loop('api.example.com', ttl='24h')

Go Client

package main

import (
    "fmt"
    "time"
    vault "github.com/hashicorp/vault/api"
)

func issueCertificate(client *vault.Client, role, cn, ttl string) (map[string]interface{}, error) {
    secret, err := client.Logical().Write(
        fmt.Sprintf("pki_int/issue/%s", role),
        map[string]interface{}{
            "common_name": cn,
            "ttl":         ttl,
        },
    )
    if err != nil {
        return nil, err
    }
    return secret.Data, nil
}

func main() {
    config := vault.DefaultConfig()
    config.Address = "https://vault.example.com:8200"

    client, _ := vault.NewClient(config)
    client.SetToken("hvs.xyz123...")

    data, _ := issueCertificate(client, "web-server", "api.example.com", "24h")

    fmt.Printf("Certificate:\n%s\n", data["certificate"])
    fmt.Printf("Serial: %s\n", data["serial_number"])
}

Kubernetes Integration: vault.hashicorp.com/agent-inject for PKI Certificates {#vault-agent-inject-kubernetes}

The Vault Agent Injector is the most common way to deliver Vault PKI certificates to Kubernetes pods. It runs as a sidecar container that authenticates with Vault, requests certificates, writes them to a shared volume, and automatically renews them.

How vault.hashicorp.com/agent-inject-secret-cert.pem Works

When you add vault.hashicorp.com/agent-inject-secret-cert.pem as a pod annotation, the Vault Agent Injector mutating webhook intercepts the pod creation and adds a Vault Agent sidecar. This sidecar:

1. Authenticates to Vault using the pod’s Kubernetes service account
2. Requests a certificate from the PKI secrets engine path specified in the annotation
3. Writes the formatted output to /vault/secrets/cert.pem inside the pod
4. Monitors the certificate and re-requests before the TTL expires

Complete Kubernetes Deployment with Vault PKI

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-app
  template:
    metadata:
      labels:
        app: web-app
      annotations:
        # Enable Vault Agent injection
        vault.hashicorp.com/agent-inject: "true"
        vault.hashicorp.com/role: "web-server"

        # Inject the certificate
        vault.hashicorp.com/agent-inject-secret-cert.pem: "pki_int/issue/web-server"
        vault.hashicorp.com/agent-inject-template-cert.pem: |
          {{- with secret "pki_int/issue/web-server"
              "common_name=api.example.com" "ttl=24h" -}}
          {{ .Data.certificate }}
          {{ .Data.issuing_ca }}
          {{- end }}

        # Inject the private key
        vault.hashicorp.com/agent-inject-secret-key.pem: "pki_int/issue/web-server"
        vault.hashicorp.com/agent-inject-template-key.pem: |
          {{- with secret "pki_int/issue/web-server"
              "common_name=api.example.com" "ttl=24h" -}}
          {{ .Data.private_key }}
          {{- end }}

        # Inject CA chain for trust validation
        vault.hashicorp.com/agent-inject-secret-ca.pem: "pki_int/issue/web-server"
        vault.hashicorp.com/agent-inject-template-ca.pem: |
          {{- with secret "pki_int/issue/web-server"
              "common_name=api.example.com" "ttl=24h" -}}
          {{ .Data.issuing_ca }}
          {{- end }}

        # Keep the agent running for renewal
        vault.hashicorp.com/agent-pre-populate-only: "false"
    spec:
      serviceAccountName: web-app
      containers:
      - name: app
        image: myapp:latest
        ports:
        - containerPort: 8443
        volumeMounts:
        - name: vault-secrets
          mountPath: /vault/secrets
          readOnly: true
        env:
        - name: TLS_CERT_FILE
          value: /vault/secrets/cert.pem
        - name: TLS_KEY_FILE
          value: /vault/secrets/key.pem
        - name: TLS_CA_FILE
          value: /vault/secrets/ca.pem

Alternative: cert-manager with Vault Issuer

For teams already using cert-manager, the Vault issuer provides a Kubernetes-native integration:

# Configure Vault as a cert-manager issuer
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: vault-issuer
  namespace: default
spec:
  vault:
    server: https://vault.example.com:8200
    path: pki_int/sign/web-server
    auth:
      kubernetes:
        role: cert-manager
        mountPath: /v1/auth/kubernetes
        secretRef:
          name: cert-manager-vault-token
          key: token
---
# Request a certificate
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: api-tls
spec:
  secretName: api-tls-secret
  duration: 24h
  renewBefore: 12h
  issuerRef:
    name: vault-issuer
    kind: Issuer
  dnsNames:
    - api.example.com
    - www.api.example.com

The cert-manager approach stores certificates as Kubernetes Secrets, making them accessible to any pod without sidecar injection. Choose agent-inject for per-pod certificate customization; choose cert-manager for centralized certificate management across the cluster.

Vault PKI ACME Support {#vault-acme}

As of Vault 1.14, the PKI secrets engine supports the ACME protocol (RFC 8555), enabling standard ACME clients to request certificates from Vault automatically. This bridges the gap between Vault’s API-first approach and the established ACME ecosystem.

Why ACME on Vault Matters

ACME is the protocol that powers Let’s Encrypt. By supporting it, Vault becomes compatible with every ACME client—certbot, Lego, cert-manager’s ACME issuer, and dozens of others. Organizations running Vault as an internal CA can now offer the same automated certificate experience that public CAs provide, without exposing internal infrastructure to the internet.

Enabling ACME

# Enable ACME on an existing PKI mount
vault write pki_int/config/acme enabled=true

# Optional: require External Account Binding for authenticated access
vault write pki_int/config/acme \
    enabled=true \
    eab_policy="always-required"

# Generate an EAB key for a specific client
vault write pki_int/acme/new-eab

Using certbot with Vault ACME

# Request a certificate from Vault via ACME
certbot certonly \
    --server https://vault.example.com:8200/v1/pki_int/acme/directory \
    --standalone \
    -d api.example.com \
    --eab-kid "$EAB_KEY_ID" \
    --eab-hmac-key "$EAB_HMAC_KEY"

ACME vs Direct API

Use ACME when you have existing ACME infrastructure, legacy applications that support ACME but not Vault’s native API, or when you want to provide a standardized certificate request interface across teams. Use the direct Vault API when you need maximum control, want the smallest possible integration footprint, or are building new services that can integrate Vault natively.

Vault Enterprise additionally supports EST (Enrollment over Secure Transport), CMPv2, and SCEP for device and IoT enrollment scenarios where ACME isn’t appropriate.

Scaling HashiCorp Vault for High Concurrency: Performance Limits and Solutions {#vault-performance-scaling}

This section addresses the real-world performance constraints you’ll hit when running Vault PKI at scale—particularly in CI/CD pipelines with burst patterns and high-concurrency environments.

Where Vault PKI Breaks Under Load

Based on production incidents and community-reported scaling issues:

Symptoms at scale:

• Certificate issuance requests timeout during CI/CD pipeline bursts
• HTTP 429 rate limit errors with 100+ concurrent requests
• Storage backend (Raft/Consul) write bottlenecks under sustained load
• CPU spikes during RSA key generation that block other operations
• Latency spikes from 250ms (normal) to 18+ seconds (under 50 concurrent requests)

Root causes:

• Vault’s storage backend bottlenecks under high write load—every certificate issuance is a write operation
• Certificate generation is CPU-intensive, especially RSA 2048/4096 (single-threaded cryptographic operations)
• Open-source Vault is active/standby: only one node handles write requests, so adding standby nodes doesn’t improve write throughput
• Go goroutine context switching degrades I/O performance under heavy concurrent load (as HashiCorp’s own performance tuning documentation acknowledges)

Breaking point: ~50,000 certificate issuances/day with default configuration on standard hardware. Individual request latency degrades significantly at 50+ concurrent certificate requests.

Solutions If Staying with Vault

1. Use ECDSA instead of RSA: ECDSA P-256 key generation is approximately 10x faster than RSA 2048. If your applications support it, this is the single highest-impact change:

vault write pki_int/roles/web-server \
    key_type="ec" \
    key_bits=256

2. Sign CSRs instead of generating keys: If clients generate their own CSRs and submit them for signing, Vault avoids the expensive key generation step entirely. The /sign/ endpoint is significantly faster than /issue/:

vault write pki_int/sign/web-server \
    csr=@my.csr \
    ttl="24h"

3. Vault Enterprise Performance Standby Nodes: Enterprise-only feature that allows standby nodes to service read-only requests. For PKI, this helps with CRL retrieval, CA chain requests, and certificate listing—reducing load on the active node for write operations.

4. Horizontal scaling with load balancing: Run multiple Vault clusters with separate PKI mounts behind a load balancer. Applications hash their identity to a specific cluster, distributing write load.

5. Application-level request queuing: Implement a queue between your CI/CD pipeline and Vault to smooth out burst patterns. Instead of 200 concurrent certificate requests, process 20 at a time.

6. Use HCP Vault: HashiCorp’s managed service handles scaling, upgrades, and infrastructure. It won’t eliminate the fundamental per-node write limits, but it removes operational overhead.

When to Migrate Away from Vault PKI

If your organization hits these limits repeatedly, the problem may be architectural:

• Need >50K certificates/day consistently: Consider Venafi or Keyfactor for traditional long-lived certificate management, where the bottleneck shifts from issuance throughput to lifecycle orchestration
• Legacy applications can’t auto-renew: Traditional platforms manage renewal on behalf of applications
• Compliance requires certificate inventory and audit trails: Vault issues certificates but doesn’t track them post-issuance
• Need public CA certificates (OV/EV): Vault can only issue certificates from its own CA
• Regulatory requirement for specific CA providers: If you must use DigiCert, Entrust, or another public CA, Vault can’t help

Migration path (Vault → Venafi/Keyfactor): typically 10–20 weeks. Phase 1 (2–4 weeks): inventory existing certificates. Phase 2 (4–8 weeks): parallel operation with new platform. Phase 3 (4–8 weeks): cutover and decommission Vault PKI mounts.

HCP Vault and Vault Enterprise Pricing {#hcp-vault-pricing}

Self-Hosted Vault (Community Edition) — Free

No licensing fees. No per-certificate costs. You pay for infrastructure only. A 3-node self-hosted cluster on AWS (m5.large instances) costs approximately $8K–$12K/year in compute and storage.

Community Edition includes full PKI secrets engine functionality including ACME support. What you don’t get: Performance Standby Nodes, replication, namespaces, HSM auto-unseal, FIPS 140-2 mode, EST/CMPv2/SCEP protocols, and enterprise support with SLAs.

Self-Hosted Vault Enterprise

Enterprise licensing is quote-based. Typical range: $100K–$500K/year depending on cluster size, features, and support level.

Key enterprise features relevant to PKI:

• Performance Standby Nodes: Read-request offloading
• Performance Replication: Multi-region secondary clusters
• Namespaces: Multi-tenant isolation for PKI
• FIPS 140-2: Compliance mode
• EST/CMPv2/SCEP: Device enrollment protocols
• 24/7 Enterprise Support: SLA-backed response times
• HSM Auto-Unseal: Simplified operations

HCP Vault Dedicated (Managed SaaS)

HCP Vault Dedicated is HashiCorp’s fully managed Vault service. Pricing is per-cluster-hour:

Tier	Approximate Cost	Features
Development	$0.50/hr ($360/month)	Single node, no HA, dev/test only
Starter	$1.66/hr ($1,200/month)	3-node HA, basic features
Standard	Custom pricing	HA + performance standbys
Plus	Custom pricing	Full enterprise features

HCP Vault Secrets (the lighter, secrets-only SaaS product) offers a free tier for up to 25 secrets, but does not include the PKI secrets engine.

Cost Comparison for PKI Use Cases

Deployment	10K certs/day	50K certs/day	Notes
Vault Community (self-hosted)	~$10K/year	~$10K/year	Infrastructure only, unlimited certs
Vault Enterprise	~$150K–$200K/year	~$200K–$300K/year	Adds performance scaling + support
HCP Vault Dedicated	~$15K–$50K/year	~$50K–$100K/year	Managed, no ops overhead
Keyfactor Command	~$100K–$150K/year	~$150K–$200K/year	Different model (lifecycle mgmt)
Venafi (CyberArk)	~$150K–$250K/year	~$250K–$400K/year	Enterprise lifecycle mgmt

Vault’s cost advantage is dramatic for high-volume, short-lived certificate use cases. The gap narrows when you factor in engineering time for self-hosted deployments, and it reverses if your organization needs traditional long-lived certificate management features that Vault doesn’t provide.

Service Mesh and mTLS Integration {#service-mesh}

Consul Connect with Vault CA

# Consul server configuration
connect {
  enabled = true
  ca_provider = "vault"
  ca_config {
    address = "https://vault.example.com:8200"
    token = "hvs.abc123..."
    root_pki_path = "connect-root"
    intermediate_pki_path = "connect-intermediate"
    leaf_cert_ttl = "72h"
  }
}

Istio with Vault

Istio can use Vault as an external CA for mesh-internal mTLS certificates. This requires configuring Istio’s caAddress to point to your Vault cluster and setting up appropriate authentication. The integration provides enterprise-grade CA management for service mesh workloads while keeping certificate lifecycle under Vault’s control.

Strengths and Weaknesses: An Honest Assessment

Where Vault PKI Excels

Eliminates certificate management overhead entirely. No inventory tracking. No expiry monitoring. No renewal workflows. For cloud-native environments where applications can auto-renew, this removes an entire operational burden.

Cost-effective at any certificate volume. Zero per-certificate fees. An organization issuing 100,000 certificates per day pays the same Vault license as one issuing 100. This makes Vault the clear winner for high-volume, short-lived certificate scenarios.

API-first design fits DevOps workflows. Every operation is an API call. Infrastructure-as-code via Terraform. GitOps-compatible. CI/CD pipeline integration is natural. No web console clicking required.

Kubernetes-native integration. Agent-inject, CSI driver, cert-manager issuer, Kubernetes auth method. Vault understands Kubernetes natively rather than bolting on container support as an afterthought.

Unified secrets platform. PKI is one of many secrets engines. The same Vault cluster manages database credentials, cloud provider secrets, SSH certificates, and encryption keys. One platform, one set of policies, one audit log.

Where Vault PKI Falls Short

Not traditional PKI. Vault can’t manage long-lived certificates from external CAs. If you need OV/EV certificates from DigiCert, a certificate inventory across your enterprise, or lifecycle management for certificates you didn’t issue—Vault is the wrong tool.

Requires application changes. Every application must be modified to request and auto-renew certificates. Legacy applications that expect certificates in a file on disk, renewed by a human, can’t use Vault without a wrapper (like agent-inject, which solves this for Kubernetes but not for bare-metal or VM workloads).

Operational complexity. Running production Vault is non-trivial: HA cluster management, seal/unseal procedures, backup and disaster recovery, security hardening, and monitoring. HCP Vault reduces this burden but at significant cost.

Limited out-of-box integrations. Venafi offers 200+ pre-built integrations with load balancers, firewalls, CDNs, and cloud services. Vault’s approach is “here’s an API, build what you need.” Powerful but requires engineering investment.

Performance ceiling for certificate issuance. CPU-bound key generation limits throughput. This isn’t a problem for most organizations but becomes one at very high scale or with burst patterns.

Use Cases

Microservices mTLS

Profile: E-commerce platform, 500+ microservices, Kubernetes Solution: Vault PKI with 1-hour certificate TTL via agent-inject Result: Zero-trust networking with no certificate management overhead, automatic rotation, reduced lateral movement risk

Kubernetes Certificate Management

Profile: SaaS company, 1,000+ pods across 20 clusters Solution: cert-manager + Vault issuer with 15-minute TTL Result: Automatic cert provisioning for every pod, zero manual work, $0 certificate costs

CI/CD Pipeline Certificates

Profile: Platform engineering team, 500+ daily deployments Solution: Vault PKI with CSR signing via API Result: Every deployment gets a unique certificate, ephemeral credentials eliminate post-deployment cleanup

IoT Device Onboarding

Profile: Smart home manufacturer, 10M devices Solution: Vault PKI with device-specific roles, 30-day TTL Result: Automated device certificate issuance, unique cert per device, scalable to 100M+ devices

Implementation Guide

Getting Started (Week 1)

1. Install Vault: Self-hosted (Helm chart for K8s) or provision HCP Vault
2. Initialize and unseal: vault operator init then vault operator unseal
3. Enable PKI: Follow the setup commands in the Vault PKI API section
4. Generate root and intermediate CAs: Always use intermediates for day-to-day issuance
5. Create roles: Define allowed domains, TTLs, key types per use case
6. Test issuance: Verify certificates are issued correctly via CLI and API

Integration Phase (Weeks 2–4)

1. Configure authentication: Kubernetes auth, AWS auth, or AppRole for service-to-Vault authentication
2. Update applications: Add Vault agent-inject annotations or direct API integration
3. Implement auto-renewal: Ensure certificates renew before TTL expiry
4. Set up monitoring: Track certificate issuance rate, error rate, and latency via Vault telemetry

Production Hardening (Week 5+)

1. Pilot with non-critical services: Validate the pattern before widespread deployment
2. Tune TTLs: Start longer (24–72h) while building confidence, reduce gradually
3. Root CA offline: Move root CA key to HSM or offline storage
4. HA testing: Verify failover procedures and recovery time
5. Performance baseline: Establish throughput expectations and alerting thresholds

Best Practices

• Always use intermediate CAs for issuance. Keep root CA offline.
• Start with ECDSA P-256 unless you have a specific RSA requirement. Faster key generation, smaller certificates.
• Use CSR signing when possible. Reduces Vault’s CPU load significantly.
• Set generate_lease=true on roles if you need Vault to track issued certificates.
• Rotate intermediate CAs annually. Vault supports cross-signing for seamless rotation.
• Monitor vault.pki.tidy.cert_store_* metrics to track certificate store health.

Conclusion

HashiCorp Vault PKI represents a paradigm shift from “manage long-lived certificates” to “generate short-lived certificates on demand.” For organizations with the technical capability to integrate it—cloud-native, Kubernetes-first, strong DevOps teams—Vault offers unmatched flexibility, security, and cost-effectiveness for certificate operations.

Choose Vault PKI if you’re building cloud-native applications, running microservices or service mesh architecture, can modify applications for auto-renewal, want to eliminate certificate management overhead, need unlimited certificate issuance at minimal cost, and have engineering capacity to integrate and operate it.

Choose Venafi or Keyfactor instead if you need long-lived certificates (1+ year), require public CA validation (OV/EV), have legacy applications that can’t auto-renew, want a turnkey solution with pre-built integrations, lack DevOps engineering capacity, or need comprehensive certificate lifecycle reporting for compliance.

The upcoming shift to 45-day certificate lifetimes (CA/Browser Forum mandate by 2027) actually plays to Vault’s strengths—its short-lived certificate model already operates at far shorter intervals. But for organizations that can’t adopt Vault’s paradigm, this same shift makes traditional platforms like Venafi and Keyfactor more critical than ever.

If you’re evaluating whether Vault PKI fits your specific environment, or planning a migration from traditional PKI to dynamic certificate management, Axelspire provides vendor-neutral guidance based on real enterprise PKI implementations. We’ll tell you honestly whether Vault is the right choice—or whether a traditional platform better fits your constraints.

References

Official HashiCorp Documentation

1. Vault PKI Secrets Engine — developer.hashicorp.com/vault/docs/secrets/pki — Complete PKI engine reference
2. PKI Setup Guide — developer.hashicorp.com/vault/docs/secrets/pki/setup — Step-by-step configuration
3. Vault PKI API Documentation — developer.hashicorp.com/vault/api-docs/secret/pki — REST API reference for all PKI endpoints
4. Performance Tuning Guide — developer.hashicorp.com/vault/tutorials/operations/performance-tuning — Official scaling and tuning advice
5. High Availability Architecture — developer.hashicorp.com/vault/docs/internals/high-availability — HA design and Performance Standby Nodes
6. HCP Vault — hashicorp.com/products/vault — Managed Vault service

Kubernetes Integration

7. Vault Agent Injector — developer.hashicorp.com/vault/docs/platform/k8s — K8s sidecar injection
8. cert-manager Vault Issuer — cert-manager.io/docs/configuration/vault — Kubernetes certificate automation
9. Vault Helm Chart — github.com/hashicorp/vault-helm — Kubernetes deployment
10. Kubernetes Auth Method — developer.hashicorp.com/vault/docs/auth/kubernetes — Pod-based authentication

Client Libraries

11. Python hvac Library — github.com/hvac/hvac — Python Vault client
12. Go API Client — github.com/hashicorp/vault/tree/main/api — Official Go SDK
13. Terraform Vault Provider — registry.terraform.io/providers/hashicorp/vault — Infrastructure-as-code

Performance and Scaling

14. Vault Performance Benchmark — medium.com/hashicorp-engineering — HashiCorp SE benchmarking methodology
15. Vault Backend Performance Comparison — blog.palark.com — Independent backend testing
16. PKI Performance Tuning Discussion — groups.google.com/g/vault-tool — Community-reported PKI scaling data
17. Vault Scalability Updates (HashiConf 24) — techtarget.com — Raft improvements and adaptive overload protection

Protocols and Standards

18. RFC 8555 — ACME Protocol — datatracker.ietf.org/doc/html/rfc8555
19. RFC 7030 — EST Protocol — datatracker.ietf.org/doc/html/rfc7030
20. RFC 5280 — X.509 Certificates — datatracker.ietf.org/doc/html/rfc5280
21. SPIFFE/SPIRE Specifications — spiffe.io/docs — Workload identity standards

Security and Compliance

22. Vault Security Model — developer.hashicorp.com/vault/docs/internals/security
23. Vault Seal/Unseal Process — developer.hashicorp.com/vault/docs/concepts/seal
24. FIPS 140-2 Compliance — developer.hashicorp.com/vault/docs/enterprise/fips
25. Vault Audit Logging — developer.hashicorp.com/vault/docs/audit

Service Mesh Integration

26. Consul Connect with Vault CA — developer.hashicorp.com/consul/docs/connect/ca/vault
27. Istio Custom CA — istio.io/latest/docs/tasks/security/cert-management/custom-ca-k8s

Case Studies

28. SAP Concur — Multi-Cloud PKI — [https://www.hashicorp.com/en/resources/q2-s-multi-cloud-win-using-infrastructure-as-code)
29. Adobe — Large-Scale Vault — hashicorp.com/resources/running-vault-at-adobe-large-scale
30. Robinhood — Financial Services — https://www.hashicorp.com/en/case-studies/deutsche-bank

Alternative Platforms

31. Keyfactor vs Venafi Comparison — axelspire.com/vault/vendors/vendor-comparison-matrix — Enterprise platform comparison
32. Keyfactor Command — axelspire.com/vault/vendors/keyfactor-command — Keyfactor deep dive
33. cert-manager — cert-manager.io — Open-source K8s certificate management
34. Step CA — smallstep.com/docs/step-ca — Open-source certificate authority
35. EJBCA Enterprise — ejbca.org — Open-source PKI (Keyfactor)
36. Private CA architecture (AD CS vs EJBCA vs step-ca vs Vault) — PKI Wiki — Engineer comparison for internal PKI