BetterSign™

What VLAD-CA Is

VLAD-CA is an embedded credential authority for BetterSign identities. It issues service credentials from verified VLAD and plog state instead of treating a private CA database as the only source of truth.

The CA can mint short-TTL X.509 leaf certificates and, when enabled, OpenSSH user certificates. The durable identity remains the VLAD; certificates are current operational artifacts that can expire, rotate, and be replaced routinely.

This gives operators the compatibility of TLS and X.509 while preserving BetterSign provenance: relying systems can track which VLAD authorized the CA material and which plog state was current when credentials were issued.

See it in action: BetterSign as a SPIFFE issuer with the trust bundle rooted in a provenance log, and short-lived X.509-SVIDs that renew themselves before they expire.

Example: Web App ↔ Postgres, Mutually Authenticated

A common need is securing the link between an application and its database. Both the web app and Postgres enroll once with the vlad-ca — each proving control of its VLAD through the enrollment protocol, which is why the vlad-ca trusts them — and the vlad-ca issues each a short-lived TLS certificate. After that one-time enrollment there is no re-enrollment: keys and certificates are refreshed purely by key rotation, which the instance records in its plog. Both ends can then prove who they are on every connection.

This replaces the database password entirely: there is nothing to hardcode in an env file, a secrets manager, or the code itself, and therefore nothing to leak or copy across deploys. The app authenticates with a certificate whose key BetterSign manages and rotates for it.

The database owner decides which vlad-ca to trust — one they run in-house or one operated by a trusted third party — and configures Postgres to trust exactly that one root, with `ssl = on`, `ssl_ca_file` pointed at the vlad-ca root, and `clientcert = verify-full` in `pg_hba.conf`. Now a client is accepted only if its certificate chains to the trusted vlad-ca and its identity matches; a rogue app carrying a certificate from any other authority is rejected. Because Postgres trusts the CA rather than a pinned certificate, the app’s short-lived cert can rotate without reconfiguring the database — to rotate, an instance simply records its new key as a signed entry in its plog and asks the vlad-ca for a fresh certificate.

See the web-app-to-Postgres mutual TLS demo — both sides verified against the vlad-ca, an imposter rejected.

TLS Plog Paths

TLS state is represented as plog paths, so services can separate signing keys, encryption keys, leaf certificates, and chains without changing identity.

Common TLS paths include /data/tls/sign for service signing authority, /data/tls/cert for the current leaf certificate, /data/tls/chain for the certificate chain, and /keys/encrypt for encrypted control-plane messages.

Because these paths are plog state, watchers can react to changes after verification. A service does not need to trust a copied certificate file just because it appeared on disk.

Self-Certifying CA State

A normal CA asks relying parties to trust the CA key directly. VLAD-CA keeps the CA key under BetterSign identity state, so the verifier can follow provenance before accepting current CA material.

Followers can track a CA VLAD, verify its plog, and update local trust bundles only after the current CA key or certificate passes BetterSign authorization.

This makes CA rotation an identity lifecycle event. If the CA key changes, followers can see the signed transition instead of treating the replacement as a disconnected trust anchor.

Key Separation

VLAD-CA treats key purpose as part of policy. CA signing, TLS service signing, and encryption material should live under separate paths and separate keys.

The server-side handlers reject unsafe reuse between CA signing material and TLS signing material. This keeps a service leaf key from quietly becoming a CA key and keeps CA authority from leaking into ordinary service credentials.

The same pattern supports future algorithm agility: a service can move a TLS path to a new key family while keeping CA authority, encryption keys, and the stable VLAD separate.

Post-Quantum TLS Integration

BetterSign can carry post-quantum and hybrid cryptographic material in identity state even when a downstream protocol accepts only a narrower subset.

For native BetterSign TLS paths, hybrid key exchange such as X25519-ML-KEM-768 can be used alongside classical fallback. For stock X.509 compatibility, VLAD-CA can keep issuing conventional certificates while the verified BetterSign identity carries richer PQ state for control-plane and future-native use.

This is the practical migration model: keep today’s TLS clients working, publish stronger identity state under the VLAD, and rotate algorithms as relying systems learn to consume them.

Developer Commands

Developers can configure TLS and CA behavior through bs-server configuration and daemon admin commands. The exact flags can evolve, but the workflow is stable: create or follow the service VLAD, register TLS paths, and let the daemon update current material from verified plog state.

The important local invariant is that handlers consume verified entries. They should not accept certificate, CA, or key files merely because a peer or bucket served them.