Your wildcard certificate is stuck because your DNS provider's authoritative nameservers are serving cached ACME challenge TXT values from a previous issuance attempt, which don't match the current token we published. The delegation CNAME itself is correct, but the provider is flattening it and answering with stale data, so every issuance attempt fails identically. To fix this, delete the ACME challenge CNAME record at your DNS provider, wait a moment, then recreate it using the value shown in your service's Settings under Networking in the Railway dashboard. If your provider continues serving the old values after that, you'll need to ask their support to flush the cached records for that challenge subdomain.

I have already tried deleting and recreating the _acme-challenge CNAME

record multiple times over several days. The issue persists.

Railway support in another thread confirmed this is a Cloudflare internal

cache problem — Cloudflare is flattening the CNAME and serving stale TXT

values even after the record is deleted and recreated.

I contacted Cloudflare support to purge the cached records for

_acme-challenge.audigrowth.com.br. While waiting for their response,

can a Railway staff member please force-issue the certificate manually

on your end, or confirm if there is a backend fix available?

This has been failing for over a week.

I have already tried deleting and recreating the _acme-challenge CNAME

multiple times over several days, including waiting hours between attempts.

The issue persists.

I found this thread where a Railway employee (brody) manually kicked off

a certificate re-issuance for a user with the same symptoms:

https://station.railway.com/questions/ssl-certificate-not-provisioning-for-cus-dfa2f3bd

My DNS configuration is correct (verified), no CAA records, Cloudflare

SSL/TLS in Full mode, Universal SSL active. This appears to be the same

internal Railway certificate issuance error.

Could a Railway staff member please manually kick off a certificate

re-issuance for *.audigrowth.com.br?

Project: grand-nourishment

Service: audi-growth

Environment: production

Domain: *.audigrowth.com.br

A manual re-issue won't fix this. When we query the ACME challenge subdomain against your DNS provider's own nameservers, they return two TXT values we don't publish anywhere. Your provider is resolving our delegation itself and serving a cached result instead of following the CNAME live, so Let's Encrypt reads stale values and every attempt fails identically, including one we trigger by hand. The "internal error" is a generic wrapper, not a fault on our side.

A full reset usually clears it. Remove the wildcard domain from the service in Railway and delete the challenge CNAME at your provider. Turn Universal SSL off under SSL/TLS, Edge Certificates, wait about ten minutes, then turn it back on. Re-add the wildcard in Railway and set up the records the dashboard gives you. The Universal SSL toggle is the part that matters, since editing the record alone doesn't clear their cache. Your other subdomain's certificate is valid and stays untouched.

If it still fails, your provider's support ticket will move faster with a reproducible query: a TXT lookup for the challenge subdomain against their nameservers, and the same lookup against our delegation target, should return matching values. Right now they don't.