9 days ago
Project: epma-advisor (id b3d9bb49-a362-41c8-9561-eb8a6e35e616)
Environment: production (id 555ec883-6c86-439f-90c3-f26909785839)
Service: epma-advisor (id 63a47505-45ad-4bee-baad-00ee7f0d02eb)
Custom domain: advisor.epma.cloud (created 2026-07-19 17:56 UTC)
Required CNAME target: ss2h44xm.up.railway.app
What I've verified:
DNS is correct and propagated: requiredValue == currentValue == ss2h44xm.up.railway.app, status DNS_RECORD_STATUS_PROPAGATED.
DNS provider is Cloudflare, record is DNS-only (not proxied).
No CAA records on epma.cloud (Let's Encrypt not blocked).
The HTTP-01 challenge path is reachable directly: http://advisor.epma.cloud/.well-known/acme-challenge/ returns 404 from railway-edge (served over HTTP, not redirected to HTTPS).
What I already tried:
Recreated the custom domain once.
Confirmed the Cloudflare proxy is OFF so Railway can validate directly.
Despite all this, certificateStatus never leaves VALIDATING_OWNERSHIP. Please help trigger the cert issuance. Thanks!
2 Replies
9 days ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • 9 days ago
9 days ago
You need to add a TXT record for _railway-verify.advisor.epma.cloud. If you are using the API to add your custom domain, you can find it in verificationToken under status.
8 days ago
Your CNAME's fine. The 404 on the ACME challenge path is what's wrong here, not the DNS. Railway requires a second record for ownership verification: a TXT record at _railway-verify.advisor.epma.cloud, separate from the CNAME. Cert issuance (and routing in general) won't proceed without it as per Railway's own docs, a missing/wrong TXT record produces exactly this symptom: CNAME resolves fine, but you get a 404 and it never leaves VALIDATING_OWNERSHIP.
Check:
- Does
_railway-verify.advisor.epma.cloudTXT record exist at all in Cloudflare? - Is the value exactly 64 characters after
railway-verify=? A truncated/extra character here is a known cause of this specific stuck state. - Since you recreated the domain once, recreating rotates both the CNAME hash and the TXT token. Pull the current expected TXT value fresh from the dashboard (or
verificationTokenunder status if you're using the API) rather than reusing anything from before the recreate.
If the TXT record checks out and it's still wedged, that's Railway-side (possibly a stale cached validation state from the earlier recreate) and needs staff to clear it manually. It's worth flagging that explicitly if you escalate.