9 days ago
Hi Railway team,
Two of my custom domains are stuck in CERTIFICATE_STATUS_TYPE_ISSUING with all preconditions green. I've waited well past the documented 1–10 min ACME window.
Domain 1: api.civixcrm.ai
Project: da1bc68b-95b2-458c-88e8-f2eb3d03c8b0 (friendly-miracle)
Service: dff377d3-6d69-46af-8d6b-ce517dbbc860 (civix)
Custom Domain ID: d4cf59d6-64c6-4f15-905e-2af0e4b9df88
certificateStatus: ISSUING (no error message)
DNS: PROPAGATED, CNAME api.civixcrm.ai → vt20ogl1.up.railway.app (unproxied, TTL 60)
TXT: _railway-verify.api.civixcrm.ai = railway-verify=361e58028... (matches required)
Domain 2: api.dgagentlaunch.com
Project: dg-agent-launch
Service: dgal-api
certificateStatus: same symptom — stuck on ISSUING
Both domains are reachable on port 80 for ACME HTTP-01 challenge. Both CNAMEs are unproxied through Cloudflare. Both TXT records match required values. Both have been recreated multiple times today with no change.
Can you please look at the cert issuance pipeline for these two domains and let me know what's blocking? Production launch is gated on these certs.
Thanks,
Easton Padden
CIVIX LLC
1 Replies
Status changed to Open Railway • 9 days ago
9 days ago
I checked the public DNS from here, and this looks split between the two domains.
For api.civixcrm.ai, public DNS matches what you posted:
- CNAME resolves to vt20ogl1.up.railway.app
- _railway-verify.api.civixcrm.ai returns the Railway verify value
- I do not see any CAA records on civixcrm.ai that would obviously block issuance
- HTTP reaches railway-edge and redirects to HTTPS
For api.dgagentlaunch.com, I do see the CNAME resolving to Railway and HTTP hitting railway-edge, but I do not see a TXT record at either of these from my resolver:
_railway-verify.api.dgagentlaunch.com
_railway-verify.dgagentlaunch.com
So I would double-check the exact TXT record name/value Railway is asking for on that second custom domain. It may be a different generated record, but if Railway expects one of those names, public DNS is not returning it yet.
If the second domain's exact Railway-provided TXT record is present in Cloudflare but not visible publicly, I would fix that first. If Railway already shows DNS/TXT propagated for both domains, then I do not think this is app code. At that point I would ask Railway staff to inspect or retry the issuance state for the custom domain IDs.
The checks I would attach for staff are:
dig CNAME api.civixcrm.ai
dig TXT _railway-verify.api.civixcrm.ai
dig CNAME api.dgagentlaunch.com
dig TXT
dig CAA civixcrm.ai
dig CAA dgagentlaunch.com
curl -I http://api.civixcrm.ai
curl -I http://api.dgagentlaunch.com
The useful signal from the curl checks is that both HTTP requests are hitting railway-edge. So if ownership verification is confirmed inside Railway too, this looks much more like a stuck issuance/retry state than something in the deployed service.
Docs I checked: https://docs.railway.com/networking/domains/working-with-domains