14 days ago
I am opening this thread to report an issue with wildcard certificate issuance for *.
The Issue:
My wildcard domain is stuck in an infinite validation loop. It stays on "Certificate Authority is validating challenges"
As a result, all my subdomains are currently inaccessible due to SSL errors.
DNS Provider: Cloudflare.
Verified Configuration:
DNS Records: Validated CNAME records for both the wildcard (*) and _acme-challenge
Both are pointing to the correct Railway target provided
Cloudflare Settings:
The _acme-challenge record is strictly set to DNS Only (Grey Cloud).
Domain Reset:
Deleted the domain from the project, waited several hours, and re-added it to force a fresh challenge.
Propagation Check:
Verified that DNS records are propagating correctly and pointing to the Railway infrastructure.
8 Replies
Status changed to Open Railway • 14 days ago
14 days ago
Ensure that the CNAME record for authorize.railwaydns.net is not proxied by your provider (eg: Cloudflare). This is required for the verification process to work.
14 days ago
DNS Only (grey) is set
14 days ago
If _acme-challenge is already grey-clouded, I’d check two specific things before deleting/re-adding again.
First, make sure the exact challenge Railway generated is what resolves publicly, not just what Cloudflare shows in the dashboard:
dig +short CNAME _acme-challenge.<domain>
dig +short CAA <domain>For a wildcard cert, the ACME check is normally _acme-challenge.<domain>, not _acme-challenge.*.<domain>. If there’s an old CNAME/TXT from a previous Railway target still hanging around, Let’s Encrypt can keep chasing the wrong thing.
Second, check CAA. If the zone has CAA records and they don’t allow Let’s Encrypt, DNS can look “right” but cert issuance still won’t complete. For wildcard you’d want issuewild covered too, something like:
0 issue "letsencrypt.org"
0 issuewild "letsencrypt.org"Also keep the actual wildcard/apex records DNS-only until the cert exists. A 525 is basically Cloudflare trying HTTPS to Railway before Railway has a cert, so proxy/strict SSL just adds noise until issuance finishes.
If both dig checks look right from 1.1.1.1 / 8.8.8.8 and it still loops, then yeah, I’d treat it as Railway-side and include the exact _acme-challenge target Railway generated so staff can inspect that validation run.
14 days ago
Thanks for all the info and instructions
My wildcard custom domain *.domain has been stuck on "Certificate Authority is validating challenges" for several hours. I've verified everything on my end and the DNS chain is fully correct:
_acme-challenge resolves via CNAME to lg7b.... ✓
TXT record at lg7... exists and returns the expected ACME challenge token ✓
No CAA records on the zone (Let's Encrypt is not restricted) ✓
All DNS records are set to DNS-only — no Cloudflare proxy active ✓
I have deleted and re-added the custom domain twice to force a retry, each time receiving new targets which I updated in Cloudflare immediately. The challenge token resolves correctly from public resolvers (Google and Cloudflare DNS).
The issue still happen
testuser123
If `_acme-challenge` is already grey-clouded, I’d check two specific things before deleting/re-adding again. First, make sure the exact challenge Railway generated is what resolves publicly, not just what Cloudflare shows in the dashboard: ```bash dig +short CNAME _acme-challenge.<domain> dig +short CAA <domain> ``` For a wildcard cert, the ACME check is normally `_acme-challenge.<domain>`, not `_acme-challenge.*.<domain>`. If there’s an old CNAME/TXT from a previous Railway target still hanging around, Let’s Encrypt can keep chasing the wrong thing. Second, check CAA. If the zone has CAA records and they don’t allow Let’s Encrypt, DNS can look “right” but cert issuance still won’t complete. For wildcard you’d want `issuewild` covered too, something like: ```txt 0 issue "letsencrypt.org" 0 issuewild "letsencrypt.org" ``` Also keep the actual wildcard/apex records DNS-only until the cert exists. A 525 is basically Cloudflare trying HTTPS to Railway before Railway has a cert, so proxy/strict SSL just adds noise until issuance finishes. If both `dig` checks look right from 1.1.1.1 / 8.8.8.8 and it still loops, then yeah, I’d treat it as Railway-side and include the exact `_acme-challenge` target Railway generated so staff can inspect that validation run.
14 days ago
Thanks for all the info and instructions
My wildcard custom domain *.domain has been stuck on "Certificate Authority is validating challenges" for several hours. I've verified everything on my end and the DNS chain is fully correct:
_acme-challenge resolves via CNAME to lg7b.... ✓
TXT record at lg7... exists and returns the expected ACME challenge token ✓
No CAA records on the zone (Let's Encrypt is not restricted) ✓
All DNS records are set to DNS-only — no Cloudflare proxy active ✓
I have deleted and re-added the custom domain twice to force a retry, each time receiving new targets which I updated in Cloudflare immediately. The challenge token resolves correctly from public resolvers (Google and Cloudflare DNS).
The issue still happen
darseen
Ensure that the CNAME record for `authorize.railwaydns.net` is not proxied by your provider (eg: Cloudflare). This is required for the verification process to work.
14 days ago
DNS Only (grey) is set
14 days ago
It failed the TLS. I tried again without changing any config and it works
14 days ago
It failed the TLS. I tried again without changing any config and it works