VaulTLS

A self-hostable web application that issues and tracks mTLS certificates — “Selfhostable web app to make managing mTLS certificates a breeze” in the repository’s own description. Rust backend, Vue front end, GPL-3.0, shipped as a Docker/Podman image. 813★, 40 forks, 16 open issues on 2026-08-05; created 2025-01-22, last pushed 2026-08-01, latest release v1.3.0 (2026-07-10). Written by 7ritn.

The stated motivation is bookkeeping, not cryptography. The author “didn’t like messing with shell scripts and OpenSSL” and had no view of which certificates across the estate were about to expire. Everything the tool does follows from those two complaints: a CA that generates itself on first launch, a web UI over issuance, and email warnings before a certificate runs out. It is the first source in this spoke on certificate lifecycle management, and the first on mTLS as a control rather than as a line in an architecture diagram.

What it manages

• X.509 client and server certificates. Client certificates download as PKCS#12 bundles with a configurable password policy (optional / required / system-generated). Server certificates take SAN DNS entries. A reverse proxy wanting separate cert and key files has to split the PKCS#12 itself — the format the tool distributes is not the format most proxies consume.
• A CA that is also an ACME CA. With VAULTLS_ACME_ENABLED=true and an account created in the admin UI for EAB credentials, Traefik or acme.sh can request certificates the way they would from a public CA. That is the one path in the tool where issuance is not a human clicking a button.
• SSH certificates, from a separate CA the admin creates by hand; the download is a ZIP holding the private key and certificate rather than a single bundle.
• Revocation by CRL. The README states the constraint plainly: “TLS certificates cannot be simply deleted since their validity period is cryptographically encoded.” Revoked serials go to a CRL under /app/data/crl/, which is deliberately reachable without authentication — a revocation list only works if every verifier can fetch it.
• Access model: “Users can only see certificates created for them. Only admins can create new certificates.”

Where the trust actually sits

Three configuration details decide how much the CA is worth, and all three are the operator’s problem rather than the software’s:

• VAULTLS_API_SECRET is a 256-bit base64 value the operator generates. VAULTLS_DB_SECRET turns on database encryption and the README calls enabling it irreversible. Both can be delivered as container secrets under /run/secrets/. The CA private key lives in a mounted data volume at /app/data/ca/ca.cert — self-hosting a CA moves the key from a vendor’s HSM to a Docker volume, and the tool does not pretend otherwise.
• OIDC account linking is by email. A first-time OIDC user is matched to an existing local account when the email matches, or created if it doesn’t. That is convenient and it makes the identity provider’s email verification load-bearing: an IdP that lets a user assert an unverified address hands over the matching account. The README documents the behaviour and not the assumption behind it. (Reading, not a claim from the source — no exploit is evidenced.)
• The password-recovery path is an admin backdoor by design. Set VAULTLS_ACCOUNT_EMAIL and VAULTLS_ACCOUNT_PASSWORD at startup, reset, then remove the variables. Anyone who can edit the compose file owns the CA, which is true of most self-hosted software and worth stating for one that issues credentials.

VAULTLS_INSECURE=true allows non-HTTPS access and is documented for development only; the normal deployment is behind Caddy or nginx doing TLS termination.

What it doesn’t have

No published security review of the CA implementation, no threat model in the repository, no test figures — the roadmap lists “improved testing coverage” as pending work. This is the spoke’s standing pattern in a new place: shuffle publishes its whole platform and no efficacy data, and VaulTLS publishes a certificate authority with no independent examination of the part that has to be right. For a SOAR platform the missing number is an error rate; for a CA it is an audit of key handling and certificate generation. The corpus keeps meeting tools whose inspectable part is the code and whose unmeasured part is whether it works.

Version, star count and release cadence here are a 2026-08-05 snapshot.

Why this page is in this spoke

Routed by the hub on subject: certificate issuance, expiry and revocation are access control, and this spoke’s CLAUDE.md names cryptographic hygiene as a direction to widen into. Runner-up was ../platform-ops-wiki, where certificate expiry is an outage cause rather than a control — the seam is real, and a source about cert-expiry incidents would go there.

The tool is also self-hosted homelab software, which is the subject of an open hub _inbox cluster (self-hosted-homelab, holding hometube at tally 1). It did not count toward that cluster: HomeTube was parked because no spoke owns video downloading, while mTLS certificate management has an owner. Self-hosting is this tool’s deployment model, not what it is about.

Related

mutual-tls · certificate-lifecycle-management · zero-trust · 7ritn · defensive-security · synthesis