The certificate is failing because Cloudflare's authoritative nameservers are serving stale ACME challenge TXT values that were never published by our authorization server for the current order. Your CNAME delegation record is correct and propagated, but Cloudflare has flattened and cached TXT values from an earlier attempt and keeps serving those instead of following the delegation to fetch the current token. The CA reads those stale values, they don't match, and issuance fails. Every retry fails identically for the same reason, so holding off on retries was the right call. To fix this, delete the _acme-challenge CNAME record in Cloudflare, wait a minute or two, then recreate it using the value shown in your Railway dashboard. If Cloudflare continues serving the old values after that, you'll need to contact Cloudflare support and ask them to flush the cached records for that name.

Update, two days on.

The stale-cache problem is fixed on my side. _acme-challenge.basta.my has

published your current token continuously for 48 hours:

pQ5f2pG9cbGcnbXyjvkR6XmiU9GLOeh80IhgKhx_L9s

Confirmed from both 1.1.1.1 and 8.8.8.8:

$ dig @1.1.1.1 +short TXT _acme-challenge.basta.my

"JNomwUzRvloF-ikReGXvgjl7J8cxIf3jBSBWs5O06VY"

"mklOO57FuD4RO5-9JYtbaNiYYOX7Z-7JF2a8F8ZWQjM"

"pQ5f2pG9cbGcnbXyjvkR6XmiU9GLOeh80IhgKhx_L9s"

Two stale values are still present alongside it. They are invisible in my

Cloudflare dashboard — it shows a single record at that name — which is why

deleting and recreating the CNAME didn't clear them. Extra TXT records

shouldn't affect validation, since the CA looks for its expected value among

the set.

Current state: the certificate still fails with "An internal error occurred".

My service is healthy and the generated domain

(storefront-production-c31d.up.railway.app) returns 200.

Could you re-trigger issuance from your side? The same thing was resolved that

way here:

https://station.railway.com/questions/wildcard-cert-repeatedly-fails-with-an-7cc0a274

Also, if you can see whether I've hit Let's Encrypt's failed-validation rate

limit after the attempts on the 10th, that would tell me whether to simply

wait rather than retry. I've deliberately stopped retrying.

One note in case it comes up: I replaced the _acme-challenge CNAME with a

literal TXT record holding the current token, which is how the correct value

got published. Happy to restore the CNAME, but the stale phantom records are

still in the zone and I can't see or delete them, so restoring it risks

returning to the original failure.

Heads-up: I'm going to try a non-wildcard custom domain

(dumpling-mama.basta.my) on the same service, since every recent thread

with this symptom has been a wildcard. That means I have to delete

*.basta.my first — one custom domain on the trial plan.

I'd still like the wildcard investigated: every seller on this platform

gets their own subdomain, so individual domains are a stopgap, not a

solution. I'll report back whether the non-wildcard certificate issues,

which should tell you whether the fault is specific to wildcard issuance.

Resolved on my side, and the result isolates the bug fairly cleanly.

I deleted *.basta.my and added dumpling-mama.basta.my instead — same service,

same Cloudflare zone, same nameservers, nothing else changed. The certificate

issued in about two minutes:

subject = CN=dumpling-mama.basta.my

issuer = Let's Encrypt

valid = Sep 13 09:08:05 2026 GMT -> Dec 12 09:08:04 2026 GMT

So, on one domain, in one zone, on one service:

*.basta.my 5 attempts over 4 days, all "an internal error

                      occurred", never issued

dumpling-mama.basta.my issued in ~2 minutes, first attempt

Two details that may help narrow it:

1. The non-wildcard domain asked for no _acme-challenge record at all — only a

   CNAME and a _railway-verify TXT. So it validated over HTTP-01, while the

   wildcard necessarily used DNS-01.

2. The stale TXT values you identified are STILL in my zone. There are three

   records at _acme-challenge.basta.my right now, two of them leftovers I

   cannot see or delete in the Cloudflare dashboard. The non-wildcard

   certificate issued anyway, because that path never reads them.

   That suggests the stale values were a real problem specific to the DNS-01

   path, but not the whole story: they were correct and stable for three days

   before I switched, and the wildcard still failed with the same internal

   error throughout that window.

I have left the *.basta.my CNAME in place in Cloudflare, so the wildcard can be

re-added and retried if that is useful to you.

This is a workaround rather than a fix for me. Every seller on this platform

gets their own subdomain, so I will need the wildcard working before I have

more than one shop. Happy to test anything on this domain if it helps — it is a

live zone with a reproducible failure, which sounds more useful than a bug

report.

For anyone finding this thread with the same symptom: if you only need a

handful of subdomains today, a non-wildcard custom domain may get you running

while this is looked at.

Non-wildcard domains validate over HTTP-01, which never touches the challenge TXT records at all. Your test will tell you whether everything else (DNS, service health, traffic routing) is working, and a successful non-wildcard certificate would confirm the issue is specific to the DNS-01 path that only wildcards use.

When you're ready to re-add the wildcard, the two phantom TXT values your dig output showed will need to be gone. Since they're invisible in your DNS dashboard, your DNS provider's support is the path to getting them flushed. Once clean, restore the CNAME delegation record using the value shown in your Railway dashboard so future certificate orders can pick up fresh tokens via delegation.