Issue:

Queried via customDomain — Railway's own API simultaneously reports the CNAME as propagated and the certificate as stuck:

{

"domain": "www.[ourdomain].net",

"targetPort": 3000,

"syncStatus": "ACTIVE",

"status": {

"verified": false,

"certificateStatus": "CERTIFICATE_STATUS_TYPE_VALIDATING_OWNERSHIP",

"certificateErrorMessage": null,

"dnsRecords": [

  {

    "hostlabel": "www",

    "fqdn": "www.[ourdomain].net",

    "recordType": "DNS_RECORD_TYPE_CNAME",

    "requiredValue": "[token].up.railway.app",

    "currentValue": "[token].up.railway.app",

    "status": "DNS_RECORD_STATUS_PROPAGATED",

    "purpose": "DNS_RECORD_PURPOSE_TRAFFIC_ROUTE"

  }

]

}

}

requiredValue and currentValue are identical. DNS_RECORD_STATUS_PROPAGATED is confirmed. Yet verified: false and the certificate is stuck.

External DNS Verification

Checked via Google (dns.google) and Cloudflare (cloudflare-dns.com) DoH resolvers — both return identical results:

www.[ourdomain].net CNAME [token].up.railway.app. ← matches Railway's required value

www.[ourdomain].net A [Railway edge IP]

TLS Handshake

A direct TLS handshake to www.[ourdomain].net:443 succeeds. Railway's edge is reachable and presents CN=*.up.railway.app (the Railway wildcard cert) — confirming the CNAME is routing traffic to Railway correctly, but the domain-specific certificate has not yet been issued.

Confirmed Clean on Our Side

We have verified all common causes before posting:

_acme-challenge TXT records on the domain: None (NXDOMAIN confirmed via Google DoH)

CAA records restricting certificate authorities: None — Let's Encrypt permitted by default

www CNAME is DNS-only (unproxied) in Cloudflare: Confirmed — TLS handshake shows Railway cert, not Cloudflare cert

Cloudflare proxy (orange cloud) on www: Off — grey cloud / DNS-only

Server binds to process.env.PORT on 0.0.0.0 : Confirmed in source code

Host-header validation or CORS restrictions: None |

certificateErrorMessage : null — no error reason surfaced by Railway |

The Contradiction

Railway's API reports both of these simultaneously:

•"status": "DNS_RECORD_STATUS_PROPAGATED" — Railway's verifier sees the CNAME as correct

•"certificateStatus": "CERTIFICATE_STATUS_TYPE_VALIDATING_OWNERSHIP" — ACME challenge is stalled

•"certificateErrorMessage": null — no error reason provided

There is nothing on our side to fix. The ACME ownership validation appears to be stalled on Railway's end with no diagnostic information.

Question / Request

Has anyone else experienced this state where DNS_RECORD_STATUS_PROPAGATED is confirmed but CERTIFICATE_STATUS_TYPE_VALIDATING_OWNERSHIP never resolves?

Is there a way to manually trigger certificate re-validation from the Railway dashboard, or does this require Railway staff to intervene? Any guidance on what might cause the ACME challenge to stall silently (with certificateErrorMessage: null) would be appreciated.