A production custom domain has been in CERTIFICATE_STATUS_TYPE_VALIDATING_OWNERSHIP for over 15 hours. The hostname still serves the Railway wildcard certificate (CN=*.up.railway.app), so every HTTPS request fails TLS name verification and the service is unreachable. The service itself deployed successfully and answers correctly on its *.up.railway.app service domain. Everything checkable on my side is correct: 1) DNS matches and Railway agrees. The domain status reports dnsRecords[0].currentValue == requiredValue and DNS_RECORD_STATUS_PROPAGATED. Confirmed independently with dig: exactly one CNAME for the label, pointing at the target Railway asked for, no conflicting A record. Only a CNAME is required for this domain - no TXT ownership record is listed. 2) The ACME HTTP-01 path reaches Railway's edge, not my container: curl -sSI http:// /.well-known/acme-challenge/probe HTTP/1.1 404 Not Found Server: railway-edge A 404 for a non-existent token is expected, and Server: railway-edge confirms the challenge terminates at the edge rather than being proxied to my app, so my application is not interfering with validation. 3) CAA permits Let's Encrypt: dig +short CAA 0 issue "sectigo.com" 0 issue "letsencrypt.org" 0 issue "pki.goog" DNS is hosted on Vercel nameservers. No DNSSEC. History: an earlier custom domain for the same hostname also sat in VALIDATING_OWNERSHIP for about 45 minutes with correct DNS. I deleted and recreated it; the recreate allocated a different CNAME target, so DNS was briefly stale until I repointed it. It has been correct and propagated since. I called the issue-certificate action twice early on and have deliberately stopped retrying, in case repeated failed validations are consuming a Let's Encrypt rate-limit budget for this hostname. Questions: - Is issuance for this hostname blocked by a rate limit, or by a stuck job on your side? - If it is a stuck job, can it be cleared without another delete and recreate, given that a recreate changes the CNAME target and forces another DNS change? - If it is a Let's Encrypt rate limit, when does the window expire? I can share the project, environment, service and custom-domain IDs privately with a team member rather than post them here. This is the production API hostname for a platform preparing to launch, so any indication of timeline would help.

Custom domain stuck in VALIDATING_OWNERSHIP for 15 hours with correct propagated DNS

northshoremn

HOBBYOP

3 hours ago

A production custom domain has been in CERTIFICATE_STATUS_TYPE_VALIDATING_OWNERSHIP for over 15 hours. The hostname still serves the Railway wildcard certificate (CN=*.up.railway.app), so every HTTPS request fails TLS name verification and the service is unreachable. The service itself deployed successfully and answers correctly on its *.up.railway.app service domain.

Everything checkable on my side is correct:

DNS matches and Railway agrees. The domain status reports dnsRecords[0].currentValue == requiredValue and DNS_RECORD_STATUS_PROPAGATED. Confirmed independently with dig: exactly one CNAME for the label, pointing at the target Railway asked for, no conflicting A record. Only a CNAME is required for this domain - no TXT ownership record is listed.
The ACME HTTP-01 path reaches Railway's edge, not my container:

curl -sSI http:///.well-known/acme-challenge/probe

HTTP/1.1 404 Not Found

Server: railway-edge

A 404 for a non-existent token is expected, and Server: railway-edge confirms the challenge terminates at the edge rather than being proxied to my app, so my application is not interfering with validation.

CAA permits Let's Encrypt:

dig +short CAA

0 issue "sectigo.com"

0 issue "letsencrypt.org"

0 issue "pki.goog"

DNS is hosted on Vercel nameservers. No DNSSEC.

History: an earlier custom domain for the same hostname also sat in VALIDATING_OWNERSHIP for about 45 minutes with correct DNS. I deleted and recreated it; the recreate allocated a different CNAME target, so DNS was briefly stale until I repointed it. It has been correct and propagated since. I called the issue-certificate action twice early on and have deliberately stopped retrying, in case repeated failed validations are consuming a Let's Encrypt rate-limit budget for this hostname.

Questions:

Is issuance for this hostname blocked by a rate limit, or by a stuck job on your side?
If it is a stuck job, can it be cleared without another delete and recreate, given that a recreate changes the CNAME target and forces another DNS change?
If it is a Let's Encrypt rate limit, when does the window expire?

I can share the project, environment, service and custom-domain IDs privately with a team member rather than post them here. This is the production API hostname for a platform preparing to launch, so any indication of timeline would help.

Solved

2 Replies

Railway

BOT

3 hours ago

The certificate is stuck because the domain's ownership verification has not passed yet. In addition to the CNAME (which is correctly propagated), a TXT record is required at the verification host shown in the domain's settings for ownership proof. That record is currently absent from DNS, so verification cannot complete and no certificate can issue. Once you publish the TXT record with the exact value shown in the domain's settings and it propagates, verification and certificate issuance will resume automatically, with no need to delete and recreate the domain entry.

Status changed to Awaiting User Response Railway • about 3 hours ago

northshoremn

HOBBYOP

2 hours ago

Update from the original poster: this was on our side, not Railway's. The bot's reply above is correct.

A Railway custom domain needs two DNS records — the CNAME, and a TXT at _railway-verify.. We had published only the CNAME.

The API's dnsRecords readback lists only the CNAME, so every "the record matches" check we ran looked complete. That is where my original post's claim that "no TXT ownership record is listed" came from, and it was wrong. Both records are shown only in the dashboard, under Settings → Networking → Show DNS records. That link also renders only while a record is unsatisfied — once both are in place the row collapses to a plain "DNS records" label, so the link's presence is itself the signal.

Once the TXT was added, the certificate issued in under a minute.

Answering my own three questions, in case someone finds this later: it was not a rate limit and not a stuck job on Railway's side. VALIDATING_OWNERSHIP was literally true the whole time — ownership was unverified because nothing had been published to verify it against. That also explains the null certificateErrorType and errorMessage: there was no error, just an unmet precondition.

Deleting and recreating the domain does not help and makes it worse. Each recreation mints a new CNAME target and a new verification token, invalidating whatever was already published. If you have seen this fail across two different CNAME targets, that is likely this loop rather than a Railway defect.

Apologies for the noise, and thanks to anyone who read it.

Status changed to Awaiting Railway Response Railway • about 2 hours ago

Status changed to Solved Railway • about 2 hours ago

Welcome!