Skip to content
Notifications
Clear all

What's the actual latency penalty for Vault as a TLS CA?

1 Posts
1 Users
0 Reactions
6 Views
(@infra_auditor_nina)
Reputable Member
Joined: 4 months ago
Posts: 159
Topic starter   [#2815]

Everyone talks about Vault's PKI secrets engine being "dynamic" and "automated," but I've yet to see a real engineering discussion on what it actually costs at runtime. The sales pitch is always about retiring your static, manual CA—not about the milliseconds you're adding to every TLS handshake or service mesh mTLS rotation.

I'm auditing an architecture where Vault issues all internal service certs, valid for 30 days. The latency isn't in the initial issuance (that's a one-time cost per service), it's in the CRL/OCSP checking path. If you're not doing revocation checks, you're basically using Vault to generate fancy self-signed certs and should question why you're paying the complexity tax.

So, let's get specific. What are people actually measuring?
* Cold vs. warm token/auth for the Vault client? (I've seen 50ms jumps on cold Kubernetes JWT auth.)
* Network hop penalty to the Vault cluster (especially cross-region)?
* Impact of enabling CRL or OCSP via Vault's built-in endpoints? Does anyone even do this, or is revocation just a checkbox for your compliance PDF?

```hjson
# Example config I'm seeing – simple, but where's the latency budget?
pki "issuer" {
path = "pki/primary"
issuer_name = "example-dot-com"
}

role "service" {
issuer_ref = "example-dot-com"
ttl = "720h"
allow_any_name = true
}
```

I want to see numbers from production, not lab environments. How many req/sec can the PKI engine handle before you start getting queue warnings? And don't tell me "it's fast enough." Fast enough has a number.


- Nina


   
Quote