Your wildcard domain's DNS delegation CNAME is correct and propagated, but the certificate is stuck because your DNS provider's authoritative nameservers are returning conflicting TXT values at the ACME challenge hostname. Railway publishes one challenge token at the delegation target, but the authoritative response includes additional TXT values that don't match, which causes the CA's DNS-01 validation to fail.

Cloudflare can automatically create hidden _acme-challenge TXT records for its own Universal/Advanced certificates. These won't appear in your zone's editable record list but are still served authoritatively, and they interfere with the delegated validation Railway needs. You can verify this yourself by running dig @your-nameserver _acme-challenge.yourdomain TXT +norecurse and comparing the result against what Railway's delegation target serves.

To resolve this, contact Cloudflare support with evidence that their authoritative nameservers are returning extra TXT values on the ACME challenge name that conflict with your delegated DNS-01 validation. They can remove or suppress those managed records. Disabling Universal SSL on the zone is another documented path, but it can interrupt HTTPS for any proxied hostnames relying on those certificates, so confirm impact first. After the conflicting records are cleared, the existing ACME authorization is likely already invalid, so a fresh certificate order will be needed from the domain's settings in your dashboard.

Thanks, this matches what I've already found myself. Cloudflare's free plan doesn't open support tickets for SSL/DNS issues, so I've raised it on Cloudflare's community forum instead (a Cloudflare MVP replied suggesting we disable Universal SSL entirely, which isn't viable since our apex domain is a live site depending on it for HTTPS - still waiting on a better answer there).

Could a human on your side take a look? Specifically: once the conflicting Cloudflare-side TXT records are cleared, is there anything Railway needs to do beyond a fresh certificate order from the domain's settings, or does that happen automatically? Just want to know what to expect on our end when this eventually gets unblocked.

It does not happen automatically. The current ACME authorization is almost certainly already terminal, so Railway polling it only re-reads the existing failure rather than triggering a fresh DNS-01 check. Once the conflicting TXT values on Cloudflare's side are cleared, you will need to start a new certificate order. The CLI command railway domain certificate retry does this, and it is the quickest path since the dashboard may not surface a retry button while the domain is stuck in the "issuing" state.

Fixed - closing the loop for anyone else who hits this. Cloudflare's hidden _acme-challenge TXT records (from Universal SSL) were the actual blocker on our end. Resolved by ordering a Cloudflare Advanced Certificate Manager cert for the apex + www (no wildcard, HTTP-validated instead of DNS-validated), then disabling Universal SSL - the hidden TXT records cleared within a couple of minutes once that was done.

Exactly as you said: the existing ACME authorization was terminal, so clearing the DNS alone didn't trigger a retry. railway domain certificate retry refused since status was still "issuing" from the old attempt, so I deleted the custom domain and re-added it from the dashboard instead. That fresh attempt succeeded within a few minutes once the DNS was clean. Thanks for the help.