inbuxa/inbuxa-server
1
0
Fork 0
Code Issues Pull Requests 1 Actions 2 Packages Projects Releases 1 Wiki Activity

Specs: the ACME network question is open, not answered

Browse Source 
Probing further contradicted the previous two commits. During a live run,
when the suite is certainly listening on 8899, twelve handshakes from a
container completed nothing, with or without the ACME ALPN, while the same
openssl in the same container talks to pebble's TLS port and prints its
certificate. A listener that is up but unreachable from a container is what
a ufw DROP looks like. An instant refusal on a closed port, which nc saw
from two images, is not. Both were observed minutes apart.

So the ufw suspicion is neither confirmed nor dismissed, and the page now
says that rather than picking the reading that suits the last probe.
Settling it needs `sudo ufw status verbose` and a listener bound by hand,
neither of which this session could do.

What stands on pebble's own log, and does not depend on any of this: it
runs validations and marks the authorizations invalid, so "never validates,
stays pending" was wrong.
This commit is contained in:
jcoffey-dev
2026-09-19 18:10:22 -07:00
parent 261175aae5
commit 2a127d6b9a
1 changed files with 19 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/spec/container-tests.md
+19 -8
View File
@@ -121,9 +121,10 @@ them.
poll. That was a real renewal bug and is fixed; this run logged no 400 at
all, and the client polls as RFC 8555 section 7.5.1 says to.
The suite still doesn't pass here, and the reason first recorded on this
page — that `ufw` blocks the docker bridge, so pebble never validates and
the authorizations stay pending — is wrong. Checked on 2026-09-19:
The suite still doesn't pass here. Half of the reason first recorded on
this page is wrong: pebble does validate, and the authorizations do not
stay pending. Whether `ufw` is in the way is still open. Checked on
2026-09-19:
- **TCP reaches the host.** From containers on `stalwart-test-acme`, on
two different images, `nc` to the host's gateway addresses connects on
@@ -132,11 +133,21 @@ them.
firewall rule was read or changed to establish this — `ufw status`
needs a privilege this session doesn't have.
One thing this doesn't explain: `openssl s_client` against the same
closed 8899 hung for its full timeout rather than reporting the refusal
`nc` saw a second earlier. The probe, not the path, is the likely
culprit, but it is unexplained, so treat "the bridge is open" as what
`nc` shows rather than as settled.
**But the network question is not settled, and the probes disagree.**
`openssl s_client` against the same closed 8899 hung for its full
timeout instead of reporting the refusal `nc` had just seen. Worse,
during a live run — when the suite certainly is listening on 8899, it
takes `with_default_listeners()` — twelve probes from a container
completed no handshake at all, with or without `-alpn acme-tls/1`,
while the same `openssl` connects to pebble's own TLS port from the
same container and prints its certificate.
A listener that is up but unreachable from a container is what a `ufw`
DROP looks like; an instant refusal when nothing listens is not. Both
were observed, minutes apart. Settling it needs `sudo ufw status
verbose`, and a listener bound by hand on `0.0.0.0:8899` to probe
against — neither of which this session could do. Until then the
original `ufw` suspicion is neither confirmed nor dismissed.
- **Pebble does validate.** Its log shows 20 validation attempts in the
regression run, five for each of `autoconfig`, `autodiscover`,
`mta-sts` and `ua-auto-config.tls.org`, and it then sets each