Try removing the domain from Railway and add it back after ~10-15 mins. Update DNS records as necessary.

Also, Cloudflare currently has an incident related to certificates so it may or may not be causing this issue. (https://new.cloudflarestatus.com/incidents/j17t8xz91xs0)

We did that yesterday and it fixed it, but the problem has already come back again so this is clearly not sustainable. Especially given the limit of 5 new certs per week (if I remember correctly).

And this time it didn't work. Why would we have to wait ~10-15 mins before adding?

It's less about a specific amount of time, and more about TTL expiration and Let's Encrypt rate limits. Waiting a few minutes is better to avoid any caching issues.

This time it also affected an entirely different service not on the apex domain, so that disproves the previous theory about flattening of the apex CNAME to an A record being the cause. We've switched to Cloudflare proxying and that works around the broken certificate, but it's very concerning that these things are just randomly failing out of the blue after weeks or months without issue.

The problem only manifests when Cloudflare proxying is disabled. In that case certified.one incorrectly uses the certificate for *.certified.one which causes service outages due to TLS validation failures. (We have to have both of these as custom domains for the same service for it to function correctly, due to the nature of the workload.)

Unfortunately we can no longer rely on Railway TLS, given that:

• this happened three times within 18 hours (including on non-apex domains)
• re-adding the domain didn't even work the second time
• Let's Encrypt rate limits will be reached very quickly at this rate
• there is apparently no issue acknowledged from Railway's side

From the link shared above, it seems that even relying on Cloudflare is questionable. So we are looking into running our own TLS proxy where we have full control of the certificates. Pretty disappointing, and super strange considering we had months without any issues and didn't change anything recently.

BTW we already had instatus monitoring set up but it inexplicably failed to spot the TLS certificate issue - maybe their monitors cache certificates. I have raised a support request with them separately.

This morning yet another of our services fell victim to the same outage - this time it was one on a subdomain (with 4 domain segments). This is yet more evidence that it is nothing to do with CNAME flattening on apex domains. Worse, Cloudflare doesn't support proxying of nested subdomains, so this time that workaround is not an available option.

This is a very serious failure of Railway (or perhaps an upstream provider), and we are still no closer to a) understanding the root cause, or b) a proper solution rather than a workaround which very quickly fails due to Let's Encrypt rate limiting.

Same thing on nahltime.com — apex served the *.nahltime.com wildcard (ERR_CERT_COMMON_NAME_INVALID) even though the apex cert was issued (saw it in CT logs) but never bound to the edge. Worked for weeks, broke after a wildcard renewal, and remove/re-add only helped for a few hours while burning the LE weekly cert limit. Fix that worked: apex behind Cloudflare proxied (orange) with SSL/TLS = Full, subdomains left grey — Cloudflare serves its own apex cert so Railway's broken edge never comes into it. Grey/DNS-only did nothing; only proxying worked. It's a workaround though — the real bug is Railway not binding the issued apex cert.

+1 — we're hitting the identical failure on our apex, every.ai, starting in roughly the same window — the last ~24–48h — after months of stability with no DNS or domain config changes on our side.

Same signature as the OP:

• Apex is served a wildcard that doesn't cover it: *.every.ai on the bare every.ai, resulting in ERR_CERT_COMMON_NAME_INVALID.
• It's spread beyond the apex. Some subdomains now get a non-covering wildcard too. For example, staging.every.ai is handed *.staging.every.ai, which doesn't cover the parent label.
• For anyone confused by the symptom: a *.foo.com cert never covers the bare foo.com. So when the edge serves the wildcard for the parent name, it always shows up as a CN/SAN mismatch.

What convinced us this is edge cert selection, not issuance:

• Certificate Transparency proves the right certs exist. crt.sh shows valid, unexpired certs for our exact apex hostname were provisioned recently, but the edge keeps serving the older wildcard instead.

Anyone can check their own:

• Issuance history: https://crt.sh/?q=yourdomain.com
• What's actually served:

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com | openssl x509 -noout -subject -dates

• All DNS records show verified/green in Railway's Networking panel — CNAME + _railway-verify TXT both checkmarked — yet the wrong cert is still served. So this is not fixable from the DNS side.

Heads-up for others landing here:

• Remove + re-add is only a temporary fix. It reverts.
• Repeated re-issuance can burn your Let's Encrypt rate limit: 5 duplicate certs/week per identical hostname set. Don't loop on it or you can lock yourself out of issuing any cert for ~a week.

Railway team — can you confirm whether this is a known edge/cert incident? Multiple customers are now reporting the same “certs provisioned but not served at the edge” behavior in the same window, and the remove/re-add guidance isn't holding. Is it related to the Cloudflare certificate incident mentioned earlier?

I am having the exact same problem. Did you find any fix for this?

chiming in to say I've hit this problem too. Not good

Any solution to this?

Thanks a lot - everything seems to have started working again, so I am cautiously optimistic. However this was a major production outage evidently affecting multiple customres, so it was extremely painful to have to wait multiple days for a response.