Standalone Provisioning

Standalone provisioning

Since v0.4.0, the Windows executable can provision and test endpoints without OpenSSL, Python, Rust, or a source checkout. The signed x64 executable is available from GitHub Releases. The same subcommands work in Linux builds.

Quick demo (PowerShell)

.\qkd-stub.exe demo init
.\qkd-stub.exe --config qkd-demo/a.toml serve

In a second terminal, run qkd-stub.exe --config qkd-demo/b.toml serve. In a third, run qkd-stub.exe demo verify. In PowerShell prefix the executable with .\. Verification uses mTLS and checks matching keys in both directions. Stop servers with Ctrl-C or Ctrl-Break.

demo init creates separate server and client credentials, a local test CA, one shared PSK, and a shared SAE registry. It refuses existing directories. Certificates last one year; the CA private key is not retained. Use a new demo directory to regenerate credentials. --dir selects a different directory; demo verify --url-a URL --url-b URL supports custom listener ports.

Device-style provisioning

qkd-stub configure guides you through endpoint IDs, listening address, a local private key and CSR (or existing identity import), PSK, client CA trust, and SAE registration. Setup can be saved while waiting for CA signing, then resumed. Existing secrets and SAE codes are preserved. configure --non-interactive creates/updates configuration without prompting; use provisioning subcommands to populate credentials.

The default file is qkd-stub-data/config.toml; --config FILE selects another. Paths inside it resolve relative to the configuration file. CLI file arguments resolve relative to the working directory. serve loads saved configuration; check validates local files, certificate/key consistency, and SAE setup. Saved-config serving always requires mTLS and SAE authorization.

Commands	Purpose
tls csr --dns NAME / --ip ADDRESS [--out FILE]	Generate/reuse a local ECDSA P-256 key and emit a PEM CSR
tls install FILE [--chain FILE]	Install the signed certificate after validating key match, validity, SANs, usage, and supplied chain
tls trust add FILE / list / remove SHA256	Manage trusted client CA certificates
cert inspect FILE	Show certificate metadata and numbered SAE selectors
psk generate / psk import FILE	Provision the same 32-byte PSK on both endpoints
sae add ID --code N [--cert FILE --selector N]	Register a local or remote-only SAE
sae list / sae remove ID	Inspect/remove registry entries

Generate the PSK once per endpoint pair and securely import it at the peer. Both PSK commands refuse to overwrite existing files. CSR generation reuses the private key and refuses to overwrite its output; choose a new --out for renewal. Keys are software-stored, not hardware-backed/non-exportable.

cert inspect and SAE selector extraction do not establish trust or pin a certificate. The client CA bundle supplies trust. Applications separately trust the server CA. Both endpoints must agree on stable SAE codes. check does not verify peer agreement, listening-port availability, client trust, or hostname agreement with a client's URL. Restart endpoints after configuration changes.

New data directories are owner-only on Unix and grant owner/SYSTEM access with a protected inheritable ACL on Windows. Existing directories retain their permissions. Provision one configuration from one process at a time. Writes are atomic per file, not a transaction across the whole wizard.

Full examples, semantics, and limitations: standalone provisioning reference.