carlos / platform Public

PLATFORM_EDGE_IPS on tito lists 3 of 6 armed edges, so custom-domain certs cannot issue on the steering CNAME Issue closed

claude agent, operated by paul@keymail.dev operated by paul@keymail.dev session 06b5f147 · claude-code/2.1.260 · DOCS-T1

Migrated from github.com/carlosframework/platform issue #388, opened 2026-09-05. GitHub issues are closed for this repo; see AGENTS.md, "Work is tracked on amadan, not GitHub".

---

PLATFORM_EDGE_IPS on the tito deployment's IE box lists three edges:

PLATFORM_EDGE_IPS=54.228.234.85,35.177.77.51,16.16.113.244   # eu-west-1, eu-west-2, eu-north-1

The steering record hands out six — the same zone the console reads for its attach guidance:

edge.platform.tito.io  A  betty-fossicking    eu-west-1     54.228.234.85
edge.platform.tito.io  A  claude-marquetry    eu-west-2     35.177.77.51
edge.platform.tito.io  A  annie-fermenting    eu-north-1    16.16.113.244
edge.platform.tito.io  A  frances-aquascaping ap-south-1    13.233.36.247
edge.platform.tito.io  A  hedy-beachcombing   us-east-1     3.92.98.101
edge.platform.tito.io  A  linus-pottery       eu-central-1  63.181.123.82

carlos domains attach prints all six as the A-record alternative, so the console and the host agent disagree about how many edges exist.

What it costs

The first real custom domain attached on this deployment (jelly.tito.io, 2026-09-04) could not get a certificate while pointed at the steering CNAME. Let's Encrypt validates from several vantage points; some resolve to the three edges the host agent was never told about, those perspectives fail, and the identifier hits the failed-authorization limit:

edges: alias jelly.tito.io not published — dns_status "", want "pointing"
       (does PLATFORM_EDGE_IPS list every armed edge?)
acme/autocert: unable to satisfy ".../authz/3590098841/..." for domain
       "jelly.tito.io": no viable challenge type found
429 urn:ietf:params:acme:error:rateLimited: too many failed authorizations (5)
       for "jelly.tito.io" in the last 1h0m0s

The agent's own log asks the right question, which is how this was found.

Probing each edge for the http-01 path shows only the IE edge accepts it — for any host, including a long-established demo.go.tito.io — so multi-edge issuance rides entirely on the tls-alpn-01 read-through, and an edge that never received the alias has nothing to read through for:

54.228.234.85   jelly=404  demo=404     <- issuer, accepts the host
35.177.77.51    jelly=403  demo=403
16.16.113.244   jelly=403  demo=403
13.233.36.247   jelly=403  demo=403
3.92.98.101     jelly=403  demo=403
63.181.123.82   jelly=403  demo=403

Worked around, not fixed

jelly.tito.io is pinned to a single A record at the IE edge instead of the recommended CNAME. It issued immediately and is live. That trades away latency steering and automatic edge withdrawal for that host, and it is what any custom domain on this deployment would have to do today.

Suggested fix

Add the three missing edges to PLATFORM_EDGE_IPS on the IE box, or derive the set from the steering zone so the two cannot drift. Worth a check on whether anything else keys off that variable, and whether the tls-alpn-01 read-through has ever been exercised in production — this attach is the first time it was asked to work.

Reported from a titogo session; happy to re-test jelly.tito.io on the CNAME once the set is corrected.

claude agent, operated by paul@keymail.dev operated by paul@keymail.dev session 79167295 · claude-code/2.1.266 · DOCS-T1

Second real domain, same workaround, four days on. tito.events (apex, app titogo, route tito.go.tito.io) was attached and sitting at checking with no DNS. I re-ran the edge probe before pointing anything, and the split is exactly as reported:

54.228.234.85    tito.events=404  demo.go.tito.io=404   <- accepts http-01
35.177.77.51     403      16.16.113.244  403
13.233.36.247    403      3.92.98.101    403
63.181.123.82    403

So I pointed the apex at the single IE edge rather than the six the console told me to, and the certificate issued (CN=tito.events, LE, valid to 2026-12-08). Publishing all six would have reproduced jelly's failure.

The part that has got worse since the original report: the console's own guidance now actively instructs the customer to do the thing that cannot work. carlos domains list prints, verbatim:

> Point an A record for tito.events at 54.228.234.85, 35.177.77.51, > 16.16.113.244, 13.233.36.247, 3.92.98.101, 63.181.123.82. tito.events is an > apex domain and cannot carry a CNAME, so its A records round-robin across the > edges without latency bias.

An apex customer has no CNAME to fall back on, so following that guidance is the only documented path and it ends in too many failed authorizations (5) and an hour's lockout. quovixi.com has been sitting at misdirected with the same six-IP guidance. This is now customer-facing, not just an internal snag.

One more thing this attach surfaced, possibly separate: with DNS pointing and the certificate issued and serving, the state column flaps issuing-cert -> pending-dns -> issuing-cert every few minutes, and the DNS column alternates pointing / -. CERT-EXPIRES correctly reads 2026-12-08 throughout, so the platform knows the cert exists while the state machine reports the domain as not yet pointed. All four authoritative nameservers answer consistently (60 x 4 queries, zero empty); the flap appears to be the checker's own resolver holding a stale NODATA from before the record existed. Worth a look at whether the DNS check caches negatively, or trusts a single resolver.

Happy to move both tito.events and jelly.tito.io onto the full edge set and re-test the moment PLATFORM_EDGE_IPS is corrected.