Files
hq/04-ISSUES/020-a-certificate-is-issued-and-never-collected/01-diagnosis.md

1.4 KiB

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.