Custom domain certificate stuck in VALIDATING_OWNERSHIP — DNS propagated, ACME reachable, no error

Question

# Railway support post — stuck custom-domain certificate

**Where to post:** https://station.railway.com → **Get Help** → new Question.

(`railway.com/help` redirects here. On the HOBBY plan this is Railway's support channel; there is no

private ticket queue and no support-ticket API — the Railway GraphQL schema exposes no

support/ticket/feedback mutation.)

**Note:** Central Station is a **public forum**. Everything below is visible to anyone. It contains

no secrets — only the domain, project/service names, and the Railway-issued domain id, which is the

information Railway asks for. It contains no credentials, database URLs, or customer data.

---

## Title

```
Custom domain certificate stuck in VALIDATING_OWNERSHIP — DNS propagated, ACME reachable, no error
```

## Body

```
Custom domain control.coxtpx.com has been stuck at CERTIFICATE_STATUS_TYPE_VALIDATING_OWNERSHIP for
several hours. certificateErrorType is null, so there is no error surfaced anywhere I can see.
HTTPS serves no peer certificate. Could someone check the ACME logs for this domain?

Domain:            control.coxtpx.com
Project:           empowering-cooperation (58ef5aa5-d674-46c3-81ee-2b5141e41c81)
Environment:       production (0621f6bc-e36c-4f4d-86bd-1aad79d106ee)
Service:           web (39340189-0375-4643-9979-e0ceef4c4052)
Custom domain id:  7be4f226-41ed-44ab-8223-b6f2f74a64aa
DNS record:        CNAME  control  ->  u9x67le7.up.railway.app  (Spaceship DNS)

Current state reported by your own API:
  dnsRecords[0].status        = DNS_RECORD_STATUS_PROPAGATED
  dnsRecords[0].currentValue  = u9x67le7.up.railway.app   (matches requiredValue)
  certificateStatus           = CERTIFICATE_STATUS_TYPE_VALIDATING_OWNERSHIP
  certificateErrorType        = null

What I have already verified, so you can skip the usual first steps:

1. DNS is correct and propagated. Railway itself reports DNS_RECORD_STATUS_PROPAGATED with
   currentValue matching requiredValue. Cloudflare (1.1.1.1), Google (8.8.8.8) and Quad9 (9.9.9.9)
   all return u9x67le7.up.railway.app.
2. No CAA records exist on coxtpx.com, so Let's Encrypt issuance is not restricted.
3. The HTTP-01 challenge path is reachable and is NOT redirected:
   http://control.coxtpx.com/.well-known/acme-challenge/test returns 404 — identical behaviour to
   my working *.up.railway.app hostname.
4. The domain is attached to the edge: http://control.coxtpx.com already 301s to HTTPS.
5. customDomainIssueCertificate returned true. The status did not change.
6. A full service redeploy did not change the status. The service is healthy and serving normally
   on its .up.railway.app hostname throughout.
7. The workspace is on HOBBY, which includes custom domains (only maxBackupsCount is capped at 0),
   so this should not be a plan limitation.

I would prefer not to delete and re-create the domain: I verified on a throwaway domain that Railway
issues a unique CNAME target per custom-domain registration, so re-creating would invalidate the DNS
record I have already published and require another DNS change. Happy to do it if you confirm that
is the only fix.

Separately: I noticed several other threads reporting the same VALIDATING_OWNERSHIP symptom in the
last few hours (including one open for 4+ days). If this is a known platform-side issue rather than
anything specific to my project, please say so and I will simply wait.
```

---

## Related open threads (worth linking or watching)

- "Custom domains stuck in VALIDATING_OWNERSHIP for 4+ days — DNS now" — **Awaiting Railway Response**
- "Wildcard certificate issuance stuck — two custom domains, same project"
- "Wildcard domain *.mihotel.xyz stuck in VALIDATING_OWNERSHIP challenge loop"

Railway's status page (https://status.railway.com) shows **Fully Operational** with Domains at 100%

uptime, and states that it only reports incidents with "significant, widespread user impact" —

directing smaller issues to Central Station.

## While waiting

Production continues on `https://web-production-16797.up.railway.app`. `PUBLIC_APP_URL`,

`PUBLIC_API_URL` and `CORS_ORIGINS` are deliberately unchanged, so there is no half-applied cutover.

The remaining cutover steps are in [DEPLOYMENT.md](DEPLOYMENT.md#custom-domain).