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.
This commit is contained in:
2026-09-01 22:28:26 +02:00
parent 6385d52bc0
commit 6bdd3f2bfa
@@ -0,0 +1,56 @@
---
status: fixed
opened: 2026-09-01
located-in: [mesh-control]
fixed-by: mesh-control 38d4e77
amended-design:
---
# 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`](../028-two-things-want-one-port-and-nothing-says-so/00-report.md)'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.