1.4 KiB
1.4 KiB
Diagnosis — 2026-09-21
- 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.
- 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.
- 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.
- 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.