Replacing HashiCorp Vault for Certificate Management

HashiCorp Vault is one of the most widely deployed secrets management platforms. Its PKI secrets engine can issue TLS certificates, sign certificate signing requests, and act as an intermediate CA. For organizations that already run Vault, using it for certificate management is a reasonable choice — the infrastructure is already there.

But for organizations considering Vault specifically for certificate management, or for those already running Vault for PKI and feeling the operational weight of it, it's worth asking whether Vault is the right tool for this specific job.

This article is an honest look at where Vault PKI works well, where it struggles, and when a purpose-built certificate management tool makes more sense.

What Vault PKI does well

Let's start with the honest case for Vault PKI, because there genuinely is one.

Deep integration with other Vault features. If you're already using Vault for database credentials, API keys, and application secrets, having certificates in the same system means one less piece of infrastructure to operate. The audit log is unified, access policies are unified, and your team only needs to know one system.

Flexible CA configuration. Vault can act as a root CA, an intermediate CA signed by an external root, or a leaf CA. The PKI engine supports OCSP, CRL distribution, and multiple role configurations. For organizations with complex PKI requirements, Vault provides the flexibility to implement them.

Service mesh and Kubernetes integration. Vault is well-integrated with Consul, Kubernetes (via cert-manager Vault issuer), and several service mesh implementations. If you're running that stack, Vault is a natural fit.

Enterprise features. Vault Enterprise includes HSM integration, performance replication, DR replication, and namespace isolation. For large organizations with those requirements, the Vault Enterprise feature set is difficult to match.

Where Vault PKI struggles

The challenges with Vault PKI aren't limitations of the PKI engine itself — they're the cost of operating Vault as infrastructure.

The operational overhead of running Vault. A production Vault cluster requires: a storage backend (Consul, integrated Raft, or external), an unsealing strategy (cloud KMS, HSM, or Shamir), HA configuration, backup procedures, upgrade procedures, and monitoring. Before you've issued a single certificate, you've built a complex piece of infrastructure that needs ongoing maintenance.

For organizations that are already running this infrastructure for secrets management, the incremental cost of adding PKI is low. For organizations that want to run Vault specifically for PKI, the overhead is significant for the use case.

No built-in cert delivery. Vault's PKI engine issues certificates. It doesn't deliver them to your HAProxy, Nginx, or OpenVPN instances. That integration requires custom scripts, Consul-template, or Vault Agent — additional tooling that has to be configured, tested, and maintained for each target type.

Compare this to a dedicated cert management platform where delivery to specific targets — HAProxy, Nginx, OpenVPN, MT4/MT5 — is a first-class feature, not a custom integration project.

No integrated SSH access management. Vault has an SSH secrets engine, but it's separate from the PKI engine. If you want both certificate management and SSH access management in one system with a unified audit log, you need to configure and operate both Vault secrets engines and build the integration between them yourself.

License and pricing changes. HashiCorp's move from MPL 2.0 to the Business Source License (BSL) in 2023 changed the license terms for self-hosting Vault. While Vault is still source-available, organizations running Vault in a competing or commercial context need to review their compliance position. OpenTofu and OpenBao (the Vault fork) emerged as responses to this change, but operating a fork of Vault adds its own complexity.

The "we already use Vault" situation

The most common scenario for evaluating a Vault alternative for PKI is an organization that runs Vault for secrets management and has bolted PKI onto it — and is finding the experience mediocre.

The typical pain points:

• Cert delivery to specific targets requires Vault Agent or Consul-template, which are additional things to configure and maintain
• There's no dashboard showing all certificates and their expiry status across all Vault roles and paths
• Automated renewal requires scripts that call the Vault API, check expiry dates, and trigger re-issuance — custom code that has to be maintained
• Delivery to non-standard targets (MT4/MT5, custom services) requires writing custom integration code

In this situation, the question is whether to continue building on top of Vault's PKI engine or to use Vault for secrets management (which it does well) while offloading certificate management to a dedicated platform.

The answer depends on how central certificates are to your operational pain. If cert management is a major source of toil or incidents, a dedicated platform that handles renewal, delivery, and SSH access natively is likely worth the migration.

The "considering Vault for PKI" situation

If your team doesn't already run Vault and is evaluating it for certificate management specifically, the calculus is clearer: you'd be adopting Vault's full operational overhead for one use case.

The alternative — a purpose-built certificate management platform — delivers the specific capabilities you need (automated lifecycle, cert delivery, audit trail) without requiring you to stand up and operate a distributed secrets cluster.

This doesn't mean Vault is the wrong choice if you have broader secrets management needs. If you need Vault's database credentials engine, AWS credential rotation, and PKI all in one system, adopting Vault is defensible. But if PKI is the primary driver, a specialized tool has meaningful advantages:

• Faster setup (minutes vs. hours/days for a production Vault cluster)
• Built-in cert delivery to common targets, no custom integration required
• Dashboard visibility into all certs and their status
• SSH access management co-located with cert management
• Simpler ongoing operational requirements

How to evaluate the decision

If you're deciding whether to keep using Vault PKI or move to a dedicated platform, these questions help frame the decision:

Are you using Vault for anything else? If Vault handles other secrets management needs, the incremental cost of using it for PKI is lower. If PKI is the only thing in Vault, you're paying the full operational cost for one feature.

Do you have a platform team with Vault expertise? Vault is operationally complex. Organizations without dedicated platform engineering capacity often find the maintenance burden falls on people who need to be doing other things.

Is cert delivery a pain point? If getting renewed certs to the right services is where your process breaks, and Vault doesn't have native integration with your targets, a dedicated platform with built-in delivery is likely a better fit.

Do you need SSH access management? If you want cert management and SSH access management in the same system with a unified audit log, check whether your current Vault setup provides that natively or requires additional configuration.

Migration approach

Migrating from Vault PKI to a dedicated cert management platform is a gradual process. The typical approach:

1. Stand up the new platform and register existing certs from the Vault inventory
2. Run the new platform in parallel for non-critical certs — let it handle renewal while Vault continues handling production
3. Once confident, migrate production certs to the new platform
4. Revoke the corresponding certificates in Vault
5. If Vault is still used for other secrets management, keep it — just not for PKI

The migration doesn't require any downtime. Certs continue being served by existing services throughout — the management layer change is invisible to end services.

Summary

HashiCorp Vault's PKI engine is capable. For organizations running Vault for comprehensive secrets management, using it for PKI is reasonable — the infrastructure is already there, and the integration is built.

For organizations whose primary need is certificate management, or for those finding Vault PKI's operational overhead high relative to the value, a purpose-built platform offers a better-fit tool: faster to set up, purpose-built delivery to common targets, and simpler ongoing operations.

The right choice depends on your specific situation. But if you're spending meaningful time on Vault cluster operations to support a certificate use case, it's worth asking whether that overhead is justified.