Files
hq/04-ISSUES/030-asking-what-a-machine-should-be-re-signed-its-certificate/00-report.md
T
jschoubben 6bdd3f2bfa 030 — asking what a machine should be re-signed its certificate
Composing a declaration signed the machine's certificate anew each
time, and a signing carries a fresh random serial — so what the mesh
would send differed from what it had sent by one byte, for ever, and
every machine carrying a certificate stood eternally waiting.

Third find of the same rule: issued once and kept. The port had it, the
secret had it, the certificate composed fresh on every asking — and the
keeping column had existed since the serving-key migration, written by
nothing, the same shape ReleasePorts was found in.

Found by keeping the scenario standing and diffing two plans seconds
apart: one line, where four theories had none.
2026-09-01 22:28:26 +02:00

2.6 KiB

status, opened, located-in, fixed-by, amended-design
status opened located-in fixed-by amended-design
fixed 2026-09-01
mesh-control
mesh-control 38d4e77

030 — Asking what a machine should be re-signed its certificate

Symptom

Every machine carrying a certificate reported as waiting — not running what the mesh would send it — for ever. Pushed seconds ago, already behind again. Nothing wrong, nothing failed, nothing quiet; only a comparison that never came out equal.

It surfaced as the one red test in four consecutive runs, and wore three other faults' clothes first: a test racing the apply it asserted on, a status command that wrote to the database it was reading, a machine starved at its default size. Each was real; each was fixed; the symptom stayed.

Cause

The mesh signs a certificate for a machine's internal name as part of composing its declaration — and signed anew on every composition. Same authority, same key, same name, same validity window; a fresh random serial each time, because that is what signing does. So the declaration composed to answer is this machine current differed from the declaration sent by exactly one serial number, every time, deterministically.

The comparison is a digest, so one changed byte is as unequal as a different world.

How it was found, which is the lesson

Not by deduction — deduction produced the three wrong theories above. The suite was run once with its scenario kept standing, and the standing mesh was asked twice: plan, plan, diff. Two answers seconds apart, identical to the byte but for one serial, in the certificate file. The diff had one line where four theories had none.

A verdict machine that can be kept and interrogated is worth more than the verdict.

The rule it broke, third find of its kind

Issued once and kept. The port had it, the secret had it, the certificate did not — composed fresh on every asking, by the same code that holds the other two still. And like 028's ReleasePorts, the keeping was designed and never wired: the serving-key migration added a column "and what was issued for it", and nothing wrote it.

A kept certificate stands while the name, the key and the clock agree. A node that rejoined with a new key or changed its name gets a fresh signing exactly as if nothing were kept; so does one whose certificate is into its last tenth of life.

Verified

Live, on the kept mesh, before any suite run: one push with the fixed binary and the machine settled; the second machine likewise; then the mesh's own sentence — all doing what they were told, running what the mesh would send them.