15 days ago
Hi team, my wildcard custom domain *.lemonfy.io is not getting an SSL cert issued. All subdomains under the wildcard (e.g. afiliadasplinq.lemonfy.io, remofy.lemonfy.io) return Cloudflare error 525, while specific custom domains on the same service (app.lemonfy.io) work perfectly.
Setup:
- Project: d646e2a5-2e15-4af4-8fd5-7b5f157d7ca1
- Service: b29f9c88-e7b7-42b8-bcbf-7ca98f7294bd
- Wildcard domain: *.lemonfy.io
- Current Railway identifier shown in dashboard: 6097egny
- Origin IP from Railway: 66.33.22.27
- DNS: Cloudflare (proxied)
What I verified on my end:
- DNS records match what Railway requests:
- CNAME * -> 6097egny.up.railway.app (proxied)
- CNAME _acme-challenge -> 6097egny.authorize.railwaydns.net (DNS only / gray cloud, as required for wildcards behind Cloudflare)
- TXT _railway-verify -> railway-verify=f6c3f1b3...
- Cloudflare SSL/TLS mode: Full (not Strict, per Railway docs)
- Universal SSL is enabled and covers *.lemonfy.io
- I removed and re-added the wildcard domain in Railway multiple times — no improvement after 30+ minutes each time
Diagnostic evidence the cert was never issued:
- Direct TLS connection to 66.33.22.27:443 with SNI 6097egny.up.railway.app -> succeeds, returns the default *.up.railway.app cert (Let's Encrypt)
- Same connection with SNI afiliadasplinq.lemonfy.io -> TLS handshake fails (origin has no cert for the custom hostname). This means Railway never issued the wildcard cert for *.lemonfy.io.
- _acme-challenge.lemonfy.io resolves correctly to 6097egny.authorize.railwaydns.net (DNS-only, no Cloudflare proxy interfering)
I suspect the previous attempts hit a Let's Encrypt rate limit when _acme-challenge was accidentally proxied (now fixed), or the cert provisioning is stuck on Railway's side. Could you investigate, retry the issuance manually, or let me know if I need to wait out a rate limit?
Thanks!
1 Replies
15 days ago
This thread has been marked as public for community involvement, as it does not contain any sensitive or personal information. Any further activity in this thread will be visible to everyone.
Status changed to Open Railway • 15 days ago
12 days ago
I think this is still a DNS / ACME validation mismatch, not a Railway edge outage.
I rechecked public DNS from Cloudflare, Google, and Quad9 resolvers. They all currently show *.lemonfy.io pointing to 06augz1s.up.railway.app, but your post says Railway was expecting 6097egny.up.railway.app. More importantly, _acme-challenge.lemonfy.io is not returning the required *.authorize.railwaydns.net CNAME; it resolves to Cloudflare IPs, which means the ACME challenge record is either proxied or not present as an explicit DNS-only CNAME.
Railway's wildcard domain docs say wildcard domains need two CNAME records plus the TXT verification record. The _acme-challenge CNAME is required for Railway to issue the SSL certificate, and on Cloudflare it must be DNS only / grey cloud.
I'd fix it by opening Railway's current custom-domain panel for *.lemonfy.io, copying the exact current values, then setting Cloudflare to:
1. CNAME * -> the exact current Railway *.up.railway.app target
2. CNAME _acme-challenge -> the exact current authorize.railwaydns.net target, DNS only
3. TXT _railway-verify -> the exact Railway verification value
Also remove any stale or conflicting wildcard record. After DNS matches the current Railway values, wait for validation/issuance. Avoid deleting and re-adding repeatedly, since Let's Encrypt duplicate certificate limits can block issuance for up to 7 days.
This matches the symptom: direct TLS to the wildcard hostname fails with no usable peer certificate, while the specific domain app.lemonfy.io routes successfully.