7 days ago
Hi — I cut a production site over to Railway today and both custom-domain certificates have been stuck in CERTIFICATE_STATUS_TYPE_VALIDATING_OWNERSHIP since roughly 2:00 PM EDT (18:00 UTC). Everything on my side is verified correct, including by Railway's own domain API.
- Project:
4fffbf72-21f0-42e1-bf56-ca630dbc8de9 - Environment:
ef70e996-2b78-488b-82b0-a35c6f3935e3(production) - Service:
2417c411-523a-484e-ac29-e0114d99773b - Domain 1:
savannahsquarepops.com, ID9bac2862-bdf8-4f1e-9bfa-da62355e5810, targetc5al03uc.up.railway.app - Domain 2:
www.savannahsquarepops.com, ID8577e13f-7607-47e7-9110-b1fbd59db583, targets59mktik.up.railway.app
Evidence already checked against your SSL troubleshooting guide:
-
Both domain objects report
Sync status: ACTIVEandVerified: yes(ownership TXT records published and confirmed). -
wwwCNAME reportsDNS_RECORD_STATUS_PROPAGATEDwith the exact target echoed back by your own checker. -
The root domain uses Namecheap ALIAS flattening at the apex, exactly as your root-domain doc section recommends; authoritative Namecheap DNS returns A
69.46.46.108and your edge servesmy app on both hostnames (health endpoint returns 200 over HTTPS when certificate checking is bypassed). Your checker shows
REQUIRES_UPDATE, current: -on the root only because ALIASflattening hides the literal CNAME — the doc says this configuration is supported.
-
No CAA records exist on either hostname.
-
DNSSEC is off for savannahsquarepops.com (dnsviz.net shows an unsigned/"Insecure" delegation; no DS record at the .com registry).
-
No Cloudflare or any other proxy — DNS goes straight from Namecheap to your edge.
-
Registry delegation to
dns1/dns2.registrar-servers.comcompleted at 2026-08-14T17:40:30Z (Verisign RDAP). -
The MCP
retry_domain_certificatetool refuses to run: "Certificate retry is only availableafter certificate issuance fails. Current status: CERTIFICATE_STATUS_TYPE_VALIDATING_OWNERSHIP." So the issuance job appears stuck in progress rather than failed, and I have no self-service way to kick it.
-
Both hostnames are still serving the fallback
*.up.railway.appcertificate.
I have deliberately NOT deleted/re-added the domains (your doc warns about Let's Encrypt duplicate-certificate rate limits) and cannot use the "Toggle Trick" because there is no
Cloudflare proxy involved. Could you take a look at the certificate issuance jobs for those two domain IDs? This is a small business's launch day. Thank you!
Pinned Solution
7 days ago
Since your DNS records are set up correctly for the root domain, I'd just wait for a certificate to be issued. If no certificate is issued within a day (as it may take up to day in rare cases) I'd just try to re-add the root domain again at that point.
5 Replies
7 days ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • 7 days ago
7 days ago
If you haven't deleted and re-added your domain, you're safe if you do it once (IIRC, LE rate limit is 5 tries per week) since re-adding the domain usually fixes the stuck state, I suggest you try to remove your custom domain and all its related DNS records, wait for 10 - 15 minutes, and add it again.
darseen
If you haven't deleted and re-added your domain, you're safe if you do it once (IIRC, LE rate limit is 5 tries per week) since re-adding the domain usually fixes the stuck state, I suggest you try to remove your custom domain and all its related DNS records, wait for 10 - 15 minutes, and add it again.
7 days ago
Thanks darseen, your fix worked, but only halfway. Update:
I did exactly what you suggested. Deleted both custom domains AND all their DNS records at Namecheap, waited a full 15 minutes, then re-added both domains and entered the new records Railway generated.
Result: www.savannahsquarepops.com verified and had a valid Let's Encrypt cert about 9 minutes later. It's live right now. So the stuck state was real and the re-add cleared it for that one.
But the bare domain savannahsquarepops.com is still sitting at "Validating domain ownership" roughly 20 minutes after the re-add. New domain ID is ae1ba407-e302-43d5-8dc7-a4fe8d58f911, target 55nc9eh3.up.railway.app.
What I've verified since:
- The _railway-verify TXT is an exact byte-for-byte match on Namecheap's own authoritative servers, on Google DNS, and on Cloudflare DNS. All 79 characters.
- The root uses a Namecheap ALIAS record (their CNAME flattening), which publishes A 69.46.46.17, one of your edge IPs. I know the dashboard's CNAME row will never show a literal CNAME because of flattening. My other Railway project (aisle-scout.com, root on Cloudflare flattening) works the same way, so I don't think the record shape is the issue.
- The bare domain currently returns Railway's 404 "Application not found", which your docs say is the unverified-domain response.
My questions:
- Is it possible Railway's resolver cached the ABSENCE of the TXT during the 15-minute deletion window and is still serving that negative answer? If so, how long before your verifier re-checks?
- With ALIAS/flattening at the root, does verification need anything beyond the TXT?
- Would you delete and re-add JUST the root one more time at this point, or does that risk making it worse?
- Is there any way to force a re-verification on domain ID ae1ba407-e302-43d5-8dc7-a4fe8d58f911?
The www half being fixed proves the pipeline works. I just need the bare domain to take the same trip. Thanks again.
7 days ago
Since your DNS records are set up correctly for the root domain, I'd just wait for a certificate to be issued. If no certificate is issued within a day (as it may take up to day in rare cases) I'd just try to re-add the root domain again at that point.
darseen
Since your DNS records are set up correctly for the root domain, I'd just wait for a certificate to be issued. If no certificate is issued within a day (as it may take up to day in rare cases) I'd just try to re-add the root domain again at that point.
7 days ago
RESOLVED — both domains live with valid certificates. Here's the complete recipe for anyone who lands on this thread with a root/apex domain stuck at "Validating domain ownership":
-
darseen's delete/re-add fixed my www subdomain on the first cycle (cert about 9 minutes after re-adding). Accepting that answer for the bounty — thank you.
-
My bare domain needed more. A second, root-only delete/re-add with a much longer gap (about 2.5 hours instead of 15 minutes) got it verified and routing in about 5 minutes — the longer gap matters because resolvers can negative-cache the ABSENCE of your _railway-verify TXT from the deletion window.
-
The certificate still sat at "validating ownership" after that, and here's the part I couldn't find documented anywhere: Railway's public GraphQL API has a mutation that force-runs the certificate order:
mutation { customDomainIssueCertificate(id: "") }
POST it to https://backboard.railway.com/graphql/v2 with your account token. It returned true, and my certificate went from "validating ownership" to issued in under a minute — after being wedged for over five hours across earlier attempts today. The dashboard has no button for this, and the retry endpoint refuses while the status is stuck "in progress" rather than "failed," so this mutation is the only self-service kick.
Notes for anyone searching: apex on Namecheap ALIAS (their CNAME flattening) works fine with Railway — the dashboard's CNAME row will always show yellow at the apex because flattening never exposes a literal CNAME. Trust the TXT check and your app answering on the domain, not the widget. And the Let's Encrypt duplicate-cert limit only counts ISSUED certs, so failed validation cycles don't burn it.
Railway team: a dashboard "re-issue certificate" button (or letting the retry endpoint work on stuck-in-progress orders) would have saved my whole launch day. Thanks darseen!
slyfox1186
RESOLVED — both domains live with valid certificates. Here's the complete recipe for anyone who lands on this thread with a root/apex domain stuck at "Validating domain ownership": 1. darseen's delete/re-add fixed my www subdomain on the first cycle (cert about 9 minutes after re-adding). Accepting that answer for the bounty — thank you. 2. My bare domain needed more. A second, root-only delete/re-add with a much longer gap (about 2.5 hours instead of 15 minutes) got it verified and routing in about 5 minutes — the longer gap matters because resolvers can negative-cache the ABSENCE of your _railway-verify TXT from the deletion window. 3. The certificate still sat at "validating ownership" after that, and here's the part I couldn't find documented anywhere: Railway's public GraphQL API has a mutation that force-runs the certificate order: mutation { customDomainIssueCertificate(id: "<your-custom-domain-id>") } POST it to https://backboard.railway.com/graphql/v2 with your account token. It returned true, and my certificate went from "validating ownership" to issued in under a minute — after being wedged for over five hours across earlier attempts today. The dashboard has no button for this, and the retry endpoint refuses while the status is stuck "in progress" rather than "failed," so this mutation is the only self-service kick. Notes for anyone searching: apex on Namecheap ALIAS (their CNAME flattening) works fine with Railway — the dashboard's CNAME row will always show yellow at the apex because flattening never exposes a literal CNAME. Trust the TXT check and your app answering on the domain, not the widget. And the Let's Encrypt duplicate-cert limit only counts ISSUED certs, so failed validation cycles don't burn it. Railway team: a dashboard "re-issue certificate" button (or letting the retry endpoint work on stuck-in-progress orders) would have saved my whole launch day. Thanks darseen!
7 days ago
You're welcome! Glad you got it working.
Status changed to Solved mayori • 7 days ago