2026-09-21 20:13:21 +00:00
2 changed files with 22 additions and 2 deletions
@@ -1,8 +1,8 @@
 ---
-status: open
+status: resolved
 opened: 2026-08-31
 located-in: [mesh-control, mesh-lab]
-fixed-by:
+fixed-by: mesh-lab multiple-fixes — the bed, not the proxy: its backend stub never listened and its check read a subject the authority leaves empty; against both Pebble and the catalogue's step-ca the same proxy now orders, answers the challenge, is issued and serves
 amended-design:
 ---

@@ -0,0 +1,20 @@
+# Diagnosis — 2026-09-21
+
+1. The report's own remedy was taken: the same order against a second ACME implementation. The
+   catalogue's own certificate authority, step-ca, was raised in the bed beside Pebble, pinned as
+   the catalogue pins it, and the same proxy pointed at it over the same challenge path. It issued
+   within a second of the order.
+2. The name was still not served, and the reason was neither authority's: the bed's stand-in
+   backend, a netcat loop behind the route, used flags this machine's netcat has not got and never
+   listened. Every request through the proxy was refused by the backend after a completed
+   handshake, which read as "never served over TLS" — and, against Pebble, had hidden behind
+   whatever Pebble refused first. Replaced with a real small server.
+3. With a backend that answers, Pebble issued too. The last failure was the bed's check that the
+   certificate is for the name: it read the subject, which Pebble — like the public authority it
+   stands in for — leaves empty, putting the name in the alternative names alone.
+4. So the symptom was the bed's, twice over, and the proxy's ACME client is right against both
+   implementations. Ruled out: a Pebble interop detail, and a fault in the client's order or
+   challenge handling.
+
+**Located in:** the certificate bed. Both authorities remain in it: Pebble because it models the
+public authority's strictness, step-ca because it is what a mesh runs.