[Feature Request] PKI Engine: Rate Limiting per CN/SAN to prevent Raft storage exhaustion (DoS vector)

[Alexsandr-Random]

Is your feature request related to a problem? Please describe.
Yes. Currently, the PKI secrets engine is highly vulnerable to an asymmetric Denial of Service (DoS) attack or accidental infrastructure collapse caused by a single malfunctioning (or compromised) valid client.

If a client node enters a read-only filesystem state (e.g., due to a disk error), agents like consul-template or nomad will successfully request an mTLS certificate from Vault, fail to save it locally, and immediately retry. This creates a tight, infinite loop. Since Vault defaults to storing all issued certificates in the storage backend (to support CRLs), a single broken client can generate hundreds of thousands of certificates in a few days.

This rapidly bloats the Raft database to multiple gigabytes, leading to:

1. Severe I/O bottlenecks and HTTP timeouts.
2. OOM (Out of Memory) kills on Vault nodes.
3. Total cluster degradation.
4. Snapshots becoming so large that vault operator raft snapshot restore fails consistently due to hardcoded I/O timeouts, making disaster recovery extremely painful.

Describe the solution you'd like
We urgently need a built-in Rate Limiting feature at the PKI role level, similar to Let's Encrypt's duplicate certificate limits.

Vault should have configuration options such as:

• max_requests_per_cn (e.g., 5)
• rate_limit_window (e.g., 1h)

If a client requests a certificate with the exact same Common Name (CN) or Subject Alternative Name (SAN) more than $X$ times within the time window, Vault should reject the request with an HTTP 429 Too Many Requests. This would instantly stop the storage exhaustion loop.

Describe alternatives you've considered

1. no_store = true: This prevents Raft bloat, but it is not a viable workaround for environments that strictly require CRLs to be functional.
2. Automatic Tidy: While helpful for general cleanup, Tidy cannot keep up with a tight loop generating thousands of certificates per minute. Furthermore, BoltDB does not automatically shrink its physical file size on disk after Tidy deletes the entries, meaning the damage to storage is already done.
3. External API Gateways/Load Balancers: Difficult to implement rate limiting per-CN because the requested CN is encrypted inside the TLS payload or CSR body, which L4 load balancers cannot inspect.

Explain any additional use-cases
Beyond infrastructure bugs, this is a critical security enhancement. Currently, if an attacker compromises a single low-privileged node that has permission to request its own mTLS certificate, they can intentionally spam the Vault PKI endpoint. Without rate limiting, the attacker can easily bloat the Raft database and take down the entire centralized secrets management infrastructure for the whole organization.

Implementing rate limits on duplicate certificate generation is a standard industry practice (e.g., Public CAs) and is highly needed in Vault PKI.

[dosubot]

Hi @Alexsandr-Random! I'm Dosu and I'm helping the HashiCorp, an IBM Company team.

This is a well-articulated feature request. I wasn't able to find any existing duplicate issues tracking per-CN/SAN rate limiting for the PKI engine, so this appears to be a novel request.

Existing mitigations you may already be aware of:

While Vault doesn't have per-CN rate limiting today, there are some general-purpose mechanisms that can partially address this scenario:

1. Resource Quotas (Rate Limit Quotas) — Vault supports rate limit quotas using a token-bucket algorithm that can be applied at the mount or path level. You could configure a quota targeting your PKI issue endpoint (e.g., pki/issue/my-role) to throttle total requests per second. This won't differentiate by CN, but it would cap the overall issuance rate and prevent unbounded growth. Quotas return HTTP 429 with a Retry-After header when exhausted [1].

2. PKI "Limited" path classification — The PKI backend already marks issue and issue/* paths as CPU-bound limited paths [2], which provides some capacity-based throttling, though it's not configurable per-CN.

3. Lease Count Quotas (Enterprise only) — Vault Enterprise offers lease count quotas that can cap the total number of active leases on a mount or namespace, which would indirectly limit outstanding certificates.

Why the gap exists: The PKI engine indexes certificates by serial number, not by CN [3], so there's currently no mechanism to detect or prevent duplicate issuance for the same CN/SAN within a time window. Your proposed max_requests_per_cn / rate_limit_window would require a new indexing and tracking layer.

Practical workaround suggestion: As an interim measure, you could apply a path-specific rate limit quota on your PKI issue endpoint with a conservative rate. This won't give you per-CN granularity, but it would prevent a single runaway client from generating thousands of certificates per minute and exhausting Raft storage. Combined with configuring consul-template with appropriate retry backoff settings, this could significantly reduce the blast radius.

I agree this would be a valuable addition — per-CN/SAN rate limiting is indeed standard practice for public CAs and would close a real operational gap.

Tagging @heatherezell to flag this for product and engineering review.

Written by @dosu, approved by heatherezell

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.