Hi Railway team,

I added a custom domain api.inventoryquick.com to my inventoryquick service (project inventoryquick) on 2026-05-21 around 02:49 UTC. DNS propagated within minutes — Railway's customDomain status query confirms dnsRecords[0].status = DNS_RECORD_STATUS_PROPAGATED and currentValue matches requiredValue. But the TLS certificate has been stuck on CERTIFICATE_STATUS_TYPE_VALIDATING_OWNERSHIP for ~35 hours now.

Details:

• Account email: corychamber@gmail.com
• Custom domain: api.inventoryquick.com
• Service: inventoryquick (FastAPI on Python)
• Project ID: c500a80c-696b-481a-9be7-7987d9b24a01
• Service ID: 787bfc68-a3e3-4f8a-9421-e044da4e2447
• Custom domain ID: c8b26418-d15a-45e9-8c75-bfc06c032582 (current; I detached + reattached twice during initial setup, each time you generated a new edge target — final CNAME points at zebqst9c.up.railway.app)
• External probe: TLS handshake returns SEC_E_WRONG_PRINCIPAL — your edge is presenting the wildcard *.up.railway.app Let's Encrypt cert instead of one for api.inventoryquick.com.

DNS verification (from multiple resolvers):

$ nslookup api.inventoryquick.com 1.1.1.1

api.inventoryquick.com → zebqst9c.up.railway.app → 66.33.22.x

CAA records on inventoryquick.com allow letsencrypt.org, sectigo.com, and pki.goog — so CAA isn't blocking.

What I think went wrong: I detached + re-added the custom domain twice during initial setup (each cycle handed me a new CNAME target). I won't cycle it again — aware of the Let's Encrypt 5-duplicates-per-week rate limit. Could the queued cert orders from the earlier attempts be blocking the current one? If you can purge any pending cert orders for this domain and trigger a fresh Let's Encrypt request, that would unblock me (same fix that resolved thread dee04403).

Additional diagnostic from 2026-05-22 02:25 UTC:

• Until I poked it, updatedAt on the customDomain record had not advanced since one second after creation (2026-05-21T02:49:54.239Z). 27 hours frozen suggests the cert worker never picked up the job.
• I called customDomainUpdate with targetPort: 8600 (no real change — the service was already routing on that port). The mutation succeeded and bumped updatedAt to 2026-05-22T02:25:22.917Z, but the cert status stayed at VALIDATING_OWNERSHIP and didn't advance over the next 3 minutes of polling.
• So the customDomain record itself is mutable, but the cert provisioning queue is not picking up the work for this domain. Looks like a queue/worker issue on your side rather than a DNS or CAA problem on mine.
• HTTP-01 challenge path works: curl http://api.inventoryquick.com/.well-known/acme-challenge/test returns Railway's own 404 (correct — no challenge file planted yet), confirming your edge is routing HTTP traffic for the hostname.

Non-blocking for production — my web and mobile clients use inventoryquick-production.up.railway.app directly. The custom domain is for branding alignment with auth.inventoryquick.com. Happy to wait if it's queued, but 35h on VALIDATING_OWNERSHIP feels stuck rather than slow.

Thanks,

Cory