Why I Wanted My Own PKI

I wanted something between two extremes:

  • random self-signed certificates created by hand whenever a service needed TLS
  • a public-web mindset where everything is designed around browser certificates

Neither model fits a private service stack with internal mTLS, short-lived client certificates, and a real separation between test and production.

So I built a small PKI around three layers:

  • an offline root CA
  • one intermediate CA per environment
  • Vault as the online CA that does the day-to-day issuance

Why the offline root matters

The root should not be part of normal operations.

Its job is simple:

  • sign intermediates
  • stay out of the daily blast radius

That means normal certificate issuance never depends on the most sensitive key in the hierarchy. If I need to rotate or rebuild an intermediate, the root comes back into scope. Otherwise it stays out of the way.

Why I split intermediates by environment

Test and production should not just have different names. They should have different trust paths.

A per-environment intermediate gives me:

  • cleaner revocation boundaries
  • clearer issuance policies
  • less chance of test credentials bleeding into production trust decisions

That makes the environment boundary real in cryptographic terms, not just in folder names.

Why Vault became the online CA

Once the intermediates exist, Vault is the practical control plane:

  • define issuance roles
  • control TTLs and SAN rules
  • issue server, admin, proxy, and agent certificates consistently
  • let agents and scripts consume the result in a repeatable way

That is much better than re-running ad hoc OpenSSL commands every time a service needs a new certificate.

What this changed operationally

The design gave me a cleaner mapping between trust and ownership:

  • root-only material stays in one place
  • admin client certificates are separate from runtime service credentials
  • service users only get the certificates and trust bundles they actually need

That is what made the PKI feel like infrastructure instead of a bag of files.

What I would keep

I would keep the hierarchy exactly for this kind of VPS setup:

  • offline root for rare CA work
  • environment-specific intermediates for daily issuance boundaries
  • Vault for operational certificate management

It is more structure than a tiny hobby setup needs, but much less chaos once the number of services starts growing.