Files
hq/02-DECISIONS/0098-a-fact-a-provider-makes-at-first-start-is-fetched-from-it.md
T

3.1 KiB

topic, status, date, deciders, reconstructed, extends
topic status date deciders reconstructed extends
the tiers accepted 2026-09-21 jochen false 02-DECISIONS/0085-a-secret-is-a-provision.md

98. A fact a provider makes at first start is fetched from it, not carried in its manifest

Context

The catalogue's certificate authority declared its root certificate, its root key and that key's password as its own secrets, and told the container to initialise from them. The mesh mints an own secret nobody delivers as random bytes, and random bytes are not a certificate: issued, the authority could not start; only an operator hand-making its root could raise it (issue 076). The authority can make its own root at first start. What it could not do then was tell the mesh what that root is: a consumer was given ${bound:acme-ca:root} from the provider's serves, which is written in the manifest before anything runs.

Considered Options

  1. A secret the module makes, with the mesh taking custody once the file exists. Rejected for now: a node would have to send a value up to the mesh, which no channel does today, and a root key is the one thing the mesh has no reason to hold.
  2. A served fact the provider contributes at run time. Rejected for now: the same new channel, for a fact that is not secret at all.
  3. The consumer fetches it from the provider, over the mesh network, through a gate before the thing that needs it starts. Adopted.

Decision

A provider's serves names where a fact made at first start can be fetched — the authority serves its root at a path beside its ACME directory — and a consumer fetches it in a run-once step declared before the resource that needs it, from the provider's bound address. The mesh network is where the fetch happens, which is what makes fetching without a prior trust acceptable: it is the network the mesh itself authenticates. The mesh mints only what it can make: the authority's password. The root key stays where it was made.

Consequences

The catalogue's authority starts, and the proxy that requires it trusts what it fetched. What got harder: a consumer of such a fact carries one more resource, the gate that fetches it, and a fact that changes after first start is refetched only when the declaration changes.

How it is checked

The route-forwarding bed installs the authority, the proxy and a consumer from the catalogue and asserts a routed name is served through the proxy. The proxy refuses to start on a bundle that is not a certificate, so the name being served proves the gate fetched one; the gate itself refuses a body that is not a certificate. That the proxy obtains a certificate from this authority through that root is the certificate bed's proof, against the same authority with the same proxy. The catalogue-wide manifest test parses both manifests.

References