Fizl TrustVault

What it is

One service for everything you would rather not leave lying in a config file.

Secrets, cryptographic keys, certificates, signing identities, SSH and OpenPGP material, and the identity to get at them — held in one place you control, on hardware you can point at.

TrustVault runs as a Windows service, a hardened systemd unit or a container, alongside a YubiKey or any PKCS#11 HSM. Applications, people, pipelines and agents authenticate against it, and it performs cryptography on their behalf — so a private key can be used without ever being handed out.

It was built because the Ariadne platform needed somewhere trustworthy to keep its own credentials when running inside a customer's walls, with no hyperscaler in reach. It is useful well beyond that: anywhere a cloud key vault is the right shape but the wrong address.

The security model → With Ariadne

🔐

Keys that never leave

Encrypt, decrypt, wrap, unwrap and sign through the vault. Private key material stays inside — and for hardware keys, stays on the device.

🏛️

Your address, your rules

On your servers, in your cloud tenancy, or air-gapped. No vendor holds the key material and no outbound dependency decides whether you can boot.

🧩

Drop-in APIs

Key Vault style routes, an OpenBao/Vault compatible API, ACME, OpenID Connect and an audited REST surface — so existing clients need a URL change, not a rewrite.

Sealed by design

A vault that is genuinely shut when it is shut.

Everything sensitive on disk is encrypted under a master key that exists only in memory, only after someone has deliberately unsealed the vault — and never survives a restart.

Seal and unseal

Unseal with a passphrase, a one-time recovery key, or a YubiKey or HSM that holds the wrapping key. Seal it, let it auto-seal after inactivity or simply restart the service, and every buffer is zeroed, hardware sessions are logged out, and the API answers 503 VaultSealed until a human comes back.

Bound ciphertext

Every encrypted field is AES-256-GCM with associated data tying it to its purpose and its exact record, so no ciphertext can be lifted out of one secret and dropped into another. Separate derived keys protect secret values, key material and homomorphic keys.

Hardware relay

Keys in the Windows certificate store, on a smart card, on a YubiKey or in a PKCS#11 HSM are used where they live. The vault relays the operation; the key never comes out. Their PINs are themselves vault secrets, so hardware keys are unusable while the vault is sealed too.

Hash-chained audit

Every action is journalled into a tamper-evident, hash-chained audit log naming the principal that caused it — user, client, API key, federated workload, role or ACME account — with an Auditor role that can read the trail without being able to use anything in the vault.

Least privilege, item by item

Roles and scopes set the ceiling; access policies decide the detail. Rules of the form principal × resource type × name pattern → allow or deny can confine a client to secret:ariadne.* and nothing else, and a built-in checker explains any decision before you rely on it.

Vault domains

A node can hold several vault domains, each with its own master key and signing key. Every node replicates every domain's data, but can only use the domains it has been unsealed for — so one site can hold another's material without ever being able to read it.

Capabilities

What TrustVault holds, and what it will do with it.

A secrets manager, a key management service, a certificate authority, a code-signing service and an identity provider — one service, one audit trail, one thing to back up.

Secrets

Secrets with a life cycle

Versioned values with staging labels — current, previous, pending — plus rotation policies, scheduled random rotation, tags, allow-lists, and soft delete, recover and purge.

Two-phase rotation. A new value is staged as pending, a webhook receiver applies it downstream, and only then is it promoted — so readers never get a credential the system behind it hasn't accepted yet.
Bulk retrieval. One call returns every secret a credential is entitled to, for container start-up and pipelines.

Keys & cryptography

Cryptography without handing out the key

RSA, EC and AES keys in software or in hardware, with encrypt, decrypt, wrapkey, unwrapkey, sign and verify all performed inside the vault.

Transit encryption. Versioned tv1: ciphertexts that keep decrypting after a key rotation, plus derived data keys for envelope encryption.
JOSE helpers. JWE, JWS and JWT produced and verified against vault keys, so applications stop shipping their own crypto.

Code signing

Release signing with the key in a vault, not on a build agent

Sign where the key can't escape: Windows Authenticode, Android APK v2/v3 and AAB/JAR v1, CMS/PKCS#7, XMLDSig, raw, JWS and JWT — with RFC 3161 timestamps.

Verification too. Signatures checked against vault keys, registered public keys or trusted CA certificates.
Existing tools work. The signing route is jsign compatible, so a signing step becomes a URL and a scoped key instead of a key file on the runner.

PKI

A certificate authority that renews things for you

Root and intermediate CAs, issuance from a policy or from a CSR, external-CA workflows (CSR out, certificate merged back), PFX and PEM import, links to keys already in a store or an HSM, auto-renewal, revocation, and CRL plus AIA publishing.

Built-in ACME server. Any vault CA can serve RFC 8555 with http-01 or dns-01 validation, wildcards, external account binding and revocation.
Clients you already use. certbot, acme.sh, Caddy, Traefik and cert-manager point at your own CA and renew internal TLS unattended.

Identity

An identity provider in front of it all

A full OpenID Connect provider: authorization code with PKCE, client credentials, workload identity federation, and UI login with optional TOTP. Bearer tokens and scoped tvk_ API keys for machines — never cookies on the API.

Sign in how your estate already does. LDAP passthrough against your directory, or TLS client certificates, alongside tokens and federation.
Delegated access is intersected. A user-delegated token carries the application's scopes narrowed to the user's own permissions, re-checked on every request.

End-user directory

Accounts and passkeys for your applications

A replicated end-user directory per resource scope: your application's users sign in at any node with a password and an authenticator code, or with a passkey — including from a phone, by scanning a QR code.

Self-service. Users manage their own passkeys and authenticators; vault administrators get passkeys too.
An API for your app. Create users and verify passwords, TOTP codes and passkeys without building any of it yourself.

OpenPGP & SSH

The keys your operations actually run on

A central OpenPGP keyring — generate, import, or build keys over vault or YubiKey keys, then sign (detached, cleartext or inline), verify against the keyring, and encrypt to one or many recipients. GnuPG compatible.

SSH public key distribution. Pre-prepared authorized-keys packs that the CLI installs into a user's authorized_keys in one command.
Private keys with a passphrase the vault never keeps. Stored encrypted and ssh-keygen compatible — useless to whoever ends up holding the database.

Automation

Events, policies and namespaces

Webhooks for secret rotation, key rotation and certificate issuance, renewal or revocation — HMAC-SHA256 signed, retried with exponential backoff, and never carrying a value or any key material in the payload.

Resource scopes. One vault, separate namespaces per environment or per customer. Dev and UAT can both ask for key app-enc and get different keys, decided purely by the credential used.
TOTP engine. Enrol authenticator apps and validate their codes once each, or generate codes for imported MFA seeds.

TrustVault also carries things the cloud services don't offer at all: code signing, JOSE helpers, an ACME server, homomorphic (Paillier) keys for encrypted aggregation — and the seal model itself.

☁️

Key Vault style

Azure-shaped routes for secrets, keys and certificates, so Key Vault clients and jsign work against it.

🧰

OpenBao / Vault

KV v2, transit, PKI, TOTP, AppRole and JWT login, plus namespaces mapped onto resource scopes.

📜

ACME

RFC 8555 per CA — certbot, acme.sh, Caddy, Traefik and cert-manager.

🔑

Open formats

GnuPG, ssh-keygen, PKCS#11, PKCS#7, XMLDSig, JOSE and OpenID Connect.

Drop in, don't rewrite

It speaks the APIs your tooling was written against.

Migrating off a cloud vault is usually a tooling problem, not a cryptography problem. TrustVault answers on the interfaces those tools already target.

The bao and vault CLIs, Vault Agent, the External Secrets Operator and the Terraform provider all work against the OpenBao-compatible API. cert-manager issues from the PKI engine or over ACME. Key Vault style clients use the Azure-shaped routes.

For everything specific to TrustVault there is a documented REST API, a .NET client library, and the trustvault CLI as a dotnet tool.

Pipelines & containers

No long-lived secrets on your build agents.

A pipeline proves what it is and gets a short-lived token for exactly what it needs — then signs, reads and deploys without a key file ever touching the runner.

Workload identity federation

A Kubernetes service-account token or a Gitea/GitHub Actions OIDC token is exchanged for a 15-minute vault token — issued only if every claim rule matches. No stored credential to leak.

trustvault run

The CLI fetches the secrets a job is entitled to, injects them into the child process's environment and gets out of the way — nothing written to disk, nothing left behind.

Ready-made actions

Composite Gitea and GitHub actions for setup, secrets and signing, worked examples for Android and Windows releases, and the External Secrets Operator for Kubernetes.

Resilience

A vault nobody can take down by unplugging one rack.

Nodes in different locations replicate to each other multi-master, so a site outage doesn't become a credential outage.

Pairing is a one-time invitation carrying the other node's key fingerprint; accepting it configures both directions. Changes are pushed immediately, with periodic catch-up after an outage, and every revision is retained for manual rollback.

Every change is signed by its domain's master key, and material can only be altered by the domain that owns it. OIDC applications, end users and token keys replicate too, so an application can authenticate at whichever node it can reach.

An optional fourth unseal method lets a paired partner unseal a restarted node automatically — and it releases its half of the wrapping key only after calling the node back at its paired address and checking its identity.

📦

Sealed backups

One file containing every item and its signed history, encrypted under the domain master key. Restoring onto a fresh node completes when that domain is unsealed there — so the backup alone is worthless to whoever holds it.

⏱️

On a schedule, off-site

Scheduled backups to a directory and/or S3-compatible storage such as Backblaze B2, configured from the administration UI.

🧱

Storage you can swap

Persistence sits behind a small set of interfaces, with EF Core on SQLite included and migrations provided. Sensitive columns arrive already encrypted, so the store never sees plaintext.

TrustVault is where Ariadne keeps what it must never reveal.

Better together

The credential store behind an autonomous platform.

An agent that acts on real systems needs real credentials. It should never be able to read them.

Ariadne uses TrustVault as its credential boundary: API keys and provider tokens are fetched as they are needed, user refresh tokens are encrypted with associated data binding each one to its own user, and the keys doing that work stay inside the vault — or on a YubiKey next to it.

That is how a self-hosted Ariadne deployment keeps the posture it advertises. Guard rails decide what an agent may do; TrustVault decides what it may ever see.

Explore Ariadne → Governance & audit

Deployment

Install it where your trust boundary already is.

The same build runs as a Windows service, a hardened systemd unit or a container — and a plugged-in YubiKey works in all three.

Windows service

An install script publishes a self-contained build, writes production settings, locks the data directory down to SYSTEM and Administrators, and registers an auto-restarting service. Host secrets are protected with machine-scope DPAPI.

Linux (systemd)

A hardened unit installed by script, with host secrets encrypted under a host key held in a systemd credential rather than sitting on disk beside them.

Docker

An image that already includes pcsc-lite plus the YubiKey and OpenSC PKCS#11 modules. Forward the host's smart-card daemon or pass the reader straight through, and keep the host key in a Docker secret.

After every restart the vault is sealed — on purpose. Unseal it in the UI, with a YubiKey, from the CLI, or let a paired replication partner do it for you.

FAQ

Questions, answered.

How is this different from a password manager?

A password manager shows a human a secret. TrustVault mostly refuses to: it performs the operation instead — signing, encrypting, unwrapping — so the key stays inside, and the audit log records who asked for what.

Do I need an HSM?

No. Software keys are AES-256-GCM encrypted under the vault master key and work fully. A YubiKey is an inexpensive step up, and any PKCS#11 HSM or smart card can be used where keys must demonstrably never leave hardware.

What happens when the service restarts?

It comes back sealed. Login, seal status, metadata listing and cached CRLs and CA certificates still work; anything needing key material returns 503 until someone unseals it — or until a paired partner does, if you have configured that.

Can I migrate off a cloud vault?

Usually without touching application code. Point Key Vault style and OpenBao/Vault style clients at TrustVault, import existing certificates as PFX or PEM, and link keys that already live in a certificate store or an HSM.

How do environments stay separated?

Resource scopes give one vault separate namespaces per environment or customer, with credentials pinned to a scope. Vault domains go further: separate master keys, so a node can replicate another site's data without being able to read it.

Can it issue our internal TLS certificates?

Yes — run a root and an intermediate CA, publish CRL and AIA endpoints, and switch on ACME for the CAs that should serve it. Internal hosts then renew themselves with certbot, Caddy, Traefik or cert-manager.

Is it only for Ariadne?

No. Ariadne was the first customer and remains the hardest one. TrustVault is a general-purpose secrets, key and certificate service, and plenty of deployments never run an agent at all.

How do we get it?

Talk to us. We'll look at your trust boundary, your hardware and your existing tooling, and work out whether a Windows, Linux or containerised deployment fits best — including installation and handover.

Get started

Put your keys somewhere you trust.

Whether you're moving off a cloud vault, standing up an internal CA, or getting signing keys off your build agents — it starts with a conversation about where your trust boundary actually sits.

Talk to the team Explore Ariadne

Your secrets, keys and certificates — in your own building.