Skip to content

Security model summary

One page, operator altitude: what protects what, and where the full detail lives. Every claim here is expanded on a linked page — this is the map, not the territory.

Everything runs on your network

There are no SaaS dependencies. The Hub, its PostgreSQL database, the NATS bus, and every Scout run on infrastructure you operate; the only outbound traffic the product requires is the Hub's ACME conversation with whichever certificate authorities you configure (see Certificate providers). Nothing phones home.

The crypto boundary

The Hub's cryptography is OpenSSL-backed, and that boundary is enforced by a build-time gate — no alternative TLS or crypto stacks are admitted into the Hub or signer build.

The Scout is a Go binary and uses Go's crypto/tls. That split is deliberate, and it is what makes legacy detection possible: modern OpenSSL cannot negotiate TLS 1.0/1.1 at all, while Go's stack still can — so the Scout's probe plane deliberately offers TLS 1.0 upward, purely to detect endpoints that still accept legacy protocols (a scoring finding, never a recommendation). Its control plane — the NATS connection to the Hub and the enrollment dial — holds a TLS 1.2 floor. The two planes are separate code paths; a probe's permissiveness never touches the channel the Scout trusts.

FIPS

The Hub ships in standard mode, which claims nothing — no FIPS or CMVP claim is made, and no validated-provider package ships today. The machinery for a strict mode exists, but until an independent compliance review completes, treat any FIPS requirement as unmet by this product.

Key locality: endpoint keys never travel

Endpoint private keys are generated on the endpoint (by its Scout) and never leave it. The Hub receives CSRs and returns signed certificates; it has no path that returns an endpoint private key. When a renewal reuses an existing key — key reuse — the Scout builds the CSR against the key already on disk. Even adopting an incumbent private key (e.g. taking over a certbot-managed key) is an on-host copy: the Scout copies the file between two paths on the same machine, and the key still never crosses the network.

The Hub does hold its CA private keys (that is its job); those are encrypted at rest under the CA passphrase.

The Scout's trust position

A Scout runs as root and executes Hub commands, so its safety model reduces to one question — is this really my Hub? — answered in layers, all fail-closed:

  • mTLS identity. Enrollment issues each Scout a client certificate signed by the Hub CA; every connection after that is mutually authenticated. See Enrollment & identity.
  • CA-fingerprint pinning. Enrollment refuses to proceed without a --ca-fingerprint pin, and every subsequent start re-verifies the stored CA against it — a swapped CA or a different Hub answering is fatal. See Security — CA-fingerprint pinning.
  • Per-agent NATS ACLs. The NATS server maps each verified client certificate to an ACL confining it to its own subjects — a compromised Scout cannot read another agent's commands or forge another agent's reports. The blast radius of one compromised host is that host. See Transport — the ACL wall.
  • Signed acceptance policy. On every connection the Scout additionally checks the Hub's identity against a policy signed with a key whose fingerprint was pinned at install (--policy-signer-fp). Enforcement is mandatory and fail-closed: no verified policy, no connection. See Security — independent verification of the Hub's identity.

What limits a compromised Hub

The Scout does not extend the Hub unconditional trust. Even a Hub that holds valid credentials is boxed in on the Scout side:

  • Path containment. Every Hub-supplied file path must resolve under the Scout's data dir or an operator-configured certificate directory — the Hub cannot write outside the fence.
  • Hooks are operator-local. Lifecycle hooks are executables you place on the Scout host; there is no mechanism by which the Hub can ship, select, or run code on a Scout. See Security — lifecycle hooks.
  • Cert–key pairing guards. Before installing a certificate, the Scout verifies it matches the private key it will sit beside — a mismatched delivery is refused, not written.
  • Probe targets are operator-authorized. The Scout only dials scan targets the operator listed on the box; a target the Hub merely names is refused, so a compromised Hub cannot use the fleet for internal recon. See Security — endpoint probing.

The full list, including rollback behaviour: Commands — safety mechanisms. Known residual limits are stated honestly at Limitations — security residuals.

Secrets at rest on the Hub

Stored credentials — ACME account credentials, per-provider EAB secrets, DNS-provider API tokens, and the backup encryption passphrase — are encrypted with AES-256-GCM under the CA passphrase, each in its own envelope so one secret can never be substituted for another. Secrets are write-only in the UI: once saved, Settings shows only that a value is set.

CA passphrase rotation does not re-wrap EAB secrets

After cyphers-hub rotate-ca-passphrase, stored EAB secrets remain sealed under the old passphrase and can no longer be decrypted — re-enter them per provider. The recovery steps are in Certificate providers — operational notes.