You've already done more debugging than most custom-domain reports, and based on the evidence you've shared, DNS itself does not appear to be the issue:

• Railway reports DNS_RECORD_STATUS_PROPAGATED
• currentValue == requiredValue
• Public DNS resolvers return www.comoxcoach.ca -> hu6hbxl1.up.railway.app
• No CAA restrictions
• No DNSSEC
• Multiple delete/recreate attempts show the same behavior

At this point I'd try to verify the certificate challenge path from outside Railway before concluding the cert order is stuck.

Could you share the output of:

curl -I http://www.comoxcoach.ca/.well-known/acme-challenge/test

and

curl -Iv https://www.comoxcoach.ca

One thing that stands out is your note about a temporary registrar forward. Depending on how that forwarding is implemented, it could potentially interfere with ACME validation even if DNS appears correct. I'd temporarily disable any registrar-level forwarding and leave only the Railway CNAME in place while testing.

If the challenge path is reachable, forwarding is disabled, DNS remains propagated, and the domain continues to sit in CERTIFICATE_STATUS_TYPE_VALIDATING_OWNERSHIP for many hours across multiple registrations, then the remaining evidence starts to point toward a certificate issuance workflow issue that Railway staff would need to investigate.

For now, I'd gather the curl outputs above since they'll help rule out the last major external variable.

Resolved! Thank you both — posting the wrap-up for anyone who lands here from a search later.

@pancharasshubham — I ran the curls you asked for before the fix landed, and they're useful for the record. The challenge path was reaching Railway's edge directly:

$ curl -I http://www.comoxcoach.ca/.well-known/acme-challenge/test

HTTP/1.1 404 Not Found

Server: railway-edge

X-Railway-Edge: railway/us-west2

The registrar forward turned out not to be a factor — it was on the apex only, while www was a bare CNAME straight to Railway (which the railway-edge response confirms). But your instinct to rule out the last external variables before blaming the platform was the right diagnostic discipline, and I appreciate you engaging with the evidence in detail.

@darseen had it exactly right. VALIDATING_OWNERSHIP was Railway waiting on the ownership-verification TXT record:

_railway-verify.www.comoxcoach.ca TXT "railway-verify=<status.verificationToken>"

Added it → verified: true and the certificate went VALID within about two minutes. All pages now serve over HTTPS with a proper CN=www.comoxcoach.ca cert. Accepting darseen's solution.

The trap, for future searchers: status.dnsRecords in the API only lists the CNAME requirement — mine showed fully PROPAGATED, which made everything look like a stuck cert order. The TXT requirement lives in separate fields: status.verified, status.verificationDnsHost, and status.verificationToken. Also worth knowing: deleting and re-adding the custom domain rotates both the CNAME target and the verification token, so retry-by-reset makes this strictly worse. Check verified first.

Thanks again to both of you.

Thanks for sharing the resolution.

Credit to @darseen for spotting the ownership verification requirement. I focused on ruling out DNS propagation, routing, and forwarding issues based on the evidence provided, but the missing piece was the _railway-verify TXT record.

The important takeaway for future readers is that a domain can show DNS_RECORD_STATUS_PROPAGATED and still remain stuck in VALIDATING_OWNERSHIP if status.verified is false. Be sure to check the verification token and TXT record requirements before recreating the domain.

Glad you got HTTPS working.