What I Want From My VPS and Vault

This whole project is my attempt to turn a simple VPS into a mini security platform: my own PKI, my own secret management, and my own little “production” environment that behaves like a serious setup, not just a random box on the internet.

In one sentence, the goal is:

Use a single VPS (plus a few logical components) to run my own PKI with an offline root, Vault as intermediate CA for test/prod, and mTLS all the way from proxies down to apps.

More concretely, I want:

  • My own PKI hierarchy

  • An offline root CA whose private key never leaves /root and is only used to sign intermediate CAs.

  • One intermediate CA per environment (at least test and prod), managed by Vault (pki-test, pki-prod).

  • Reproducible server certificates for Vault, proxies and apps, issued from Vault instead of random ad-hoc OpenSSL commands.

  • A layered VPS architecture instead of “one big box”

  • A public entry proxy (mainproxy) that terminates incoming traffic for *.test.privsec.ch and *.prod.privsec.ch.

  • Separate internal proxies (proxytest, proxyprod), each running as its own Unix user.

  • Dedicated Vault instances per environment (Vault test, Vault prod) as the trust and secrets backbone.

  • Applications (Nextcloud etc.) that talk to Vault through sidecar agents, not with static secrets hardcoded somewhere.

  • mTLS everywhere it matters

  • Vault API only over HTTPS with proper CN/SAN.

  • Proxies authenticate to Vault with client certificates, not just tokens.

  • Apps use Vault Agents with mTLS to fetch short-lived certs and secrets.

  • Strong isolation instead of “one user does everything”

  • Clear separation between test and prod (separate PKI, separate Vault mounts).

  • Separation between Vault servers, proxies, and apps, each with their own Unix user and key directory.

  • Each logical component has its own key space under /home/<user>/..., so a compromise in one place doesn’t automatically leak keys from another.

  • Something that feels closer to “real infra” than a toy lab

  • Short-lived admin credentials and certificates.

  • Proper paths for TLS material (offline root, intermediate CA, Vault TLS, proxy CA chains).

  • A setup that I can later mirror into Kubernetes concepts (sidecars, annotations, secret volumes) if I want to go that way.

This blog is where I’ll document how I try to get from the messy reality on my VPS to this clean model: what actually works, what breaks, and how I glue Vault, PKI, proxies and apps together without losing my mind.