2 months ago
Hi Railway team, certificate issuance for a custom domain has been stuck for more than 20 hours and never reaches the CA.
Project: aqsha-prod (c3883ad1-750c-4226-bc49-585b3252337b)
Environment: production (c36d10e7-0830-4604-97ab-a039d04868fb)
Service: aqsha-api (7df6ae30-6f64-4820-a189-fa8ac82a620a)
Domain: portal.jbs.finance (dfd55e3d-cd80-4379-9cfa-3462240c2420)
Status stays CERTIFICATE_STATUS_TYPE_VALIDATING_OWNERSHIP. It never moves to ISSUING and never fails, it just sits there. Certificate Transparency logs show zero entries for this hostname, so it looks like no ACME order is submitted at all.
DNS (Cloudflare, DNS only, verified with dig against the authoritative nameserver and public resolvers):
- CNAME portal -> v0xcba10.up.railway.app, reported by your API as DNS_RECORD_STATUS_PROPAGATED
- CNAME _acme-challenge.portal -> v0xcba10.authorize.railwaydns.net, also propagated
Note: your API returns only one required record for this domain (purpose DNS_RECORD_PURPOSE_TRAFFIC_ROUTE) and never lists the _acme-challenge record. I added it manually after seeing it in another thread here. It changed nothing.
Ruled out on our side: no CAA records on jbs.finance or on the .finance parent, DNSSEC disabled, Cloudflare proxy off, targetPort unset, no duplicate of this domain in any other project of the account, workspace billing ACTIVE, and the account is not at the customDomains limit (this is currently the only custom domain on the service). The domain was deleted and recreated three times, issuance was triggered manually six times.
The strongest signal: aqsha.jbs.finance lived on the same service with a valid Let's Encrypt certificate issued 2026-08-05 and served production traffic. After I removed and re-added it, it went into the same VALIDATING_OWNERSHIP state and never recovered. A hostname that provably worked stops working after recreation, which points at the issuance pipeline for this account rather than at our DNS.
Two other threads opened here in the last day describe the same symptom on HOBBY accounts, so this may be wider than us.
As a temporary workaround the domain is served through a Cloudflare Worker that rewrites requests to the service railway.app hostname. I would rather drop that layer and use the domain directly.
Could you check server side whether an ACME order was ever created for this domain, and what blocks ownership validation from completing?
Thanks.
1 Replies
2 months ago
The domain is stuck because Railway cannot see either of the two required DNS records. Our check shows the CNAME for portal.jbs.finance is not resolving (current value: none), and the ownership-verification TXT record is missing entirely. The _acme-challenge CNAME you added is not used by our verification system. Custom domains require both a CNAME and a TXT record. In Cloudflare, confirm the CNAME for portal points to the Railway target shown in your domain settings (proxy off), and add a TXT record at the host shown in your domain's verification section with the provided token value. Both records are visible in the domain configuration panel on your service's settings page. Once both propagate, verification and certificate issuance will proceed automatically. Reply here once both records are in place and we can re-check.
Status changed to Awaiting User Response Railway • about 2 months ago
Status changed to Solved bagdatjbs • about 2 months ago