21 lines
1.4 KiB
Markdown
21 lines
1.4 KiB
Markdown
# 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.
|