How does Vault's PKI engine automate certificates, and what prevents cert outages?

Think of an office building where instead of giving out permanent key cards that work forever, the security desk issues temporary visitor badges that expire every 8 hours. If a badge is stolen, it stops working by end of day without anyone having to manually deactivate it. Vault's PKI engine with short-lived certificates works the same way: certificates expire fast enough that revocation becomes less important, and issuance is fully automated.

Traditional certificate management involves a CA (often manual), long-lived certificates lasting 1-2 years, manual renewal, and revocation infrastructure (CRL/OCSP) for compromised certificates. This creates three problems at scale: outages when someone forgets to renew a certificate, large revocation lists when compromised certificates have long lifetimes, and bottlenecks when a security team manually processes certificate signing requests. Vault's PKI engine fixes all three by making certificate issuance programmatic, fast, and short-lived.

Under the hood, Vault's PKI engine supports a CA hierarchy. The root CA is typically kept offline or in a separate, heavily locked-down Vault mount. An intermediate CA is created within Vault and signed by the root CA. This intermediate CA issues the actual certificates your services use. When a service requests a certificate via vault write pki/issue/payments-tls, Vault generates a private key and certificate, signs it with the intermediate CA, and returns both with a TTL. The certificate and key are not stored in Vault after issuance (unless you configure that), making the issuance path stateless and fast. Vault supports RSA, ECDSA, and Ed25519 key types, and can enforce domain restrictions through allowed_domains, key usage constraints, and maximum TTL per role.

At production scale, teams set up cert-manager in Kubernetes to request certificates from Vault automatically, or use Vault's built-in ACME server (added in Vault 1.14) to let any ACME-compatible client get certificates. Short-lived certificates with 24-72 hour TTLs dramatically shrink the revocation problem: even if a certificate is stolen, it expires before a CRL update would have reached everyone in a traditional PKI setup. Monitoring needs to cover intermediate CA certificate expiry (the number one cause of PKI outages), CRL size growth, certificate issuance rate and errors, and storage backend performance under heavy issuance load.

The gotcha that causes the worst outages is intermediate CA rotation. The intermediate CA certificate has its own TTL (typically 1-5 years). If it expires, every certificate it issued becomes invalid, and every service using those certificates breaks at the same time. Vault does not rotate the intermediate CA automatically. You need alerts for intermediate CA expiry, automation for the CSR-sign-import cycle, and the new trust chain distributed to all TLS clients before the old intermediate expires. A second gotcha is CRL endpoint availability: if services check certificates against a CRL or OCSP endpoint hosted by Vault, then Vault's availability becomes part of the TLS handshake path, creating a circular dependency where you need Vault to be up to verify the certificates that connect you to Vault.