jschoubben
122405df8e
Pinned 2.5.0 rather than latest, on the suspicion that its draft profiles extension was involved. Identical failure, so that is ruled out and recorded — two of the three guesses in this issue have now been tested and both were wrong, which is the useful half. The scenario keeps the pin regardless; it should have had one from the start.
95 lines
4.0 KiB
Markdown
95 lines
4.0 KiB
Markdown
---
|
|
status: open
|
|
opened: 2026-08-31
|
|
located-in: [mesh-control, mesh-lab]
|
|
fixed-by:
|
|
amended-design:
|
|
---
|
|
|
|
# 020 — A certificate is issued and never collected
|
|
|
|
## Symptom
|
|
|
|
Against a real ACME server in the lab, the proxy orders a certificate for a name the mesh routes,
|
|
the challenge is answered, the authority **issues the certificate** — and the proxy never obtains
|
|
it. Every TLS handshake then fails, and the order is retried indefinitely.
|
|
|
|
The client's error, once per attempt:
|
|
|
|
```
|
|
http: TLS handshake error: Post "": unsupported protocol scheme ""
|
|
```
|
|
|
|
A POST to an empty URL: the certificate's location, on an order the authority considers valid.
|
|
|
|
## What is proven, and it is most of it
|
|
|
|
Read from the authority's own log rather than inferred:
|
|
|
|
```
|
|
Starting 3 validations
|
|
authz … set VALID by completed challenge …
|
|
POST /finalize-order/ → Order … is fully authorized. Processing finalization
|
|
Issued certificate serial 3ef142939115ee88
|
|
```
|
|
|
|
**The hard half works.** The order is created, the HTTP-01 challenge is answered *at the name being
|
|
certified* on port 80 through the proxy itself, the authorisation goes valid, finalisation is
|
|
accepted, and a certificate is issued. Across one run the authority issued **two** certificates and
|
|
accepted finalise **three** times — the client reaches issuance every attempt and fails at the same
|
|
step after it.
|
|
|
|
**And the policy that guards the quota is proven too.** The second assertion in the same file
|
|
passes: no certificate is ordered for a name nothing routes, so a scan cannot spend an account's
|
|
rate limit.
|
|
|
|
## What is not known
|
|
|
|
**Whether this happens against a real authority at all.** Everything above is against Pebble, which
|
|
exists to be a test server. The failure is in the last hop between one client and one server, and
|
|
may say nothing about behaviour against a public authority.
|
|
|
|
## Ruled out
|
|
|
|
| | |
|
|
|---|---|
|
|
| the directory | fetched and complete — `newAccount`, `newNonce`, `newOrder`, `revokeCert` all present |
|
|
| the authority's API certificate | covers `127.0.0.1`; the bundle is named explicitly and verification is not skipped |
|
|
| a hand-written server config | suspected, and wrong. Replacing it with the server's **own** default config, changing only the challenge port, gives the identical error |
|
|
| the finalize URL being empty | the authority logs finalisation being accepted |
|
|
| the challenge path | the authorisation goes valid |
|
|
| the server version | pinned 2.5.0 behaves exactly as `latest`, so the draft profiles extension is not it |
|
|
|
|
## Where it might be
|
|
|
|
- **The order's `certificate` field is absent when the client reads it.** The client waits for the
|
|
order to become valid and only then fetches, so an empty location on a valid order is the
|
|
remaining shape.
|
|
- ~~**A moving tag was used.**~~ **Ruled out.** `pebble:latest` advertises a draft *profiles*
|
|
extension, so a pinned 2.5.0 was tried: **identical failure**. The scenario now pins it anyway,
|
|
which it should have from the start.
|
|
|
|
## Why this is filed rather than pursued
|
|
|
|
**The mesh-side behaviour is proven and the remainder is interop between two libraries.** Continuing
|
|
would be several more twenty-minute lab runs against a server that is not the one production uses,
|
|
to chase a defect that may not exist there.
|
|
|
|
**What the mesh needed to show, it showed**: a name it routes gets a certificate ordered from a
|
|
configured authority, and a name it does not route gets nothing. The configuration is right, the
|
|
challenge path is right, and issuance happens.
|
|
|
|
## What would close it
|
|
|
|
- The same scenario against a different ACME implementation — a second server, or a real staging
|
|
endpoint from a machine that can reach one. **If it passes there, this is a Pebble interop
|
|
detail and the issue closes with that recorded.**
|
|
- Or the client's request captured on the wire, showing what the order actually contained when the
|
|
location was read.
|
|
|
|
## Evidence
|
|
|
|
- `mesh-lab test/integration/certificates.test.ts`, scenario `a-public-name`
|
|
- One assertion passes (no certificate for an unrouted name); one fails (a routed name is never
|
|
served).
|