Project: torchable-base (1af84445-8abb-4fcf-9c6d-340acf0aeb53)

Environment: production (31b128f9-82e1-42c8-8cd1-11770eeb9942)

Service: torchable-connect-web-production (c962a3cf-01e8-46a4-aa06-5b2c96b0c152)

Domain: connect.torchable.com (current registration id: ae6529d1-6957-443f-b7fe-c748dc34d0fa, targetPort 8080)

Problem: certificateStatus has been stuck at CERTIFICATE_STATUS_TYPE_VALIDATING_OWNERSHIP across three separate registrations of this domain (ids 8ece0ce5-e478-497f-aec7-32569eff88a4, 13677e1b-261a-409b-8fd2-47b198842046, ae6529d1-6957-443f-b7fe-c748dc34d0fa) over ~5 hours (2026-06-10, starting ~20:00 UTC). certificates[] stays empty. The edge serves only the fallback *.up.railway.app certificate for SNI connect.torchable.com, so HTTPS fails hostname verification.

What we've verified / ruled out:

DNS: unproxied (DNS-only) Cloudflare CNAME, currentValue == requiredValue (sa8j9gsi.up.railway.app), your API reports DNS_RECORD_STATUS_PROPAGATED.

No CAA records on torchable.com; no DNSSEC on the zone.

The same zone already has working Railway custom domains on a sibling service (base.torchable.com + *.base.torchable.com, both CERTIFICATE_STATUS_TYPE_VALID, Let's Encrypt) — so issuance for this zone works in this project.

The service is healthy: its service domain (torchable-connect-web-production-production.up.railway.app) serves /health 200.

targetPort explicitly set to 8080 (matches the app's listening port and the sibling service's working domain config).

Tried: two redeploys, domain remove/re-add twice (DNS updated to the newly issued target each time), several hours of quiet waiting between attempts.

Request: please check your ACME/cert-issuance pipeline for this hostname — it looks like the certificate order for connect.torchable.com is wedged on your side (possibly stale state from the first registration, which spent ~40 minutes pending before our DNS record existed).