Your DNS records for *.mihotel.xyz are correctly configured and fully propagated, but the certificate issuance workflow stalled. We've started a re-issue of the TLS certificate, which should complete within a few minutes.

I still have the same issue.

Your DNS records for *.mihotel.xyz are correctly configured and fully propagated, and the domain is verified. The certificate issuance needs to be re-triggered, which we've now started - it should complete within a few minutes.

Its get stuck on "Certificate Authority is validating challenges"

Taking a deeper look into this now.

Back to this

Still looking into this.

The certificate failures are caused by your Cloudflare DNS configuration for the ACME challenge record. Cloudflare's authoritative nameservers are serving stale, cached TXT values at _acme-challenge.mihotel.xyz instead of following the CNAME delegation to our authorization server. The certificate authority reads those stale values, rejects the challenge, and every retry fails the same way.

This is why your own nslookup looks correct (public resolvers follow the CNAME themselves) but issuance still fails.

To fix this: delete the _acme-challenge.mihotel.xyz CNAME record in Cloudflare, wait a minute or two, then recreate it using the value shown in your Railway dashboard. If Cloudflare continues serving old values after that, you may need to contact Cloudflare support to flush them.

Hi there,

I contacted Cloudflare Support, and they investigated my zone database directly. They verified that Cloudflare is not caching or serving any TXT records for this domain. Cloudflare only holds the CNAME pointing to Railway.

We ran a direct trace and discovered that the two stale TXT records are actually coming directly from Railway's authentication server via CNAME delegation.

Here is the exact terminal output when querying the record:

_acme-challenge.mihotel.xyz. 300 IN CNAME 9t9x9wfq.authorize.railwaydns.net.

_acme-challenge.mihotel.xyz. 300 IN TXT "ee9E7xKpQ2FH_6TNQQ5iX2QEMMEYvC5Vq49zDM3yfLM"

_acme-challenge.mihotel.xyz. 300 IN TXT "zMX-BightJ0fC4RHiyXXuYi4NuVkUes7VQPxDU4t4O8"

Because Cloudflare only contains the CNAME, your authorization target (9t9x9wfq.authorize.railwaydns.net) is what is serving those two old ghost TXT values. This is why Let's Encrypt keeps failing.

Could someone on the engineering team please flush or reset the stale TXT tokens for my domain on the Railway authentication servers?

Thank you!

We appreciate the detailed trace from Cloudflare. The output actually confirms the issue: the two TXT values in that response (ee9E7x... and zMX-Bi...) are not values our authorization server is currently publishing. Our server holds entirely different challenge tokens right now, which means Cloudflare's authoritative nameservers are returning stale, flattened copies from earlier ACME attempts rather than following the CNAME live. This is why the certificate authority keeps rejecting the challenge, and it is also why a normal nslookup from a public resolver looks correct (recursive resolvers do follow the CNAME and see the right tokens). To resolve this, delete the _acme-challenge.mihotel.xyz CNAME record in Cloudflare, wait a couple of minutes, then recreate it with the value shown in your Railway dashboard. If Cloudflare's nameservers continue returning the old TXT values after that, Cloudflare support would need to flush them on their side.

Thank you very much looks like Clouflare got stuck with those records I nothing moving forward, switch to original domain servers. Thank you and sorry for the troubles