a month ago
My custom domain is serving the Railway wildcard cert (CN=*.up.railway.app) instead of a cert for the domain itself. Browsers show "Connection not private" / SSL_ERROR_BAD_CERT_DOMAIN to some visitors.
Evidence: five fresh openssl s_client -connect :443 -servername probes from outside Railway all return subject CN=*.up.railway.app — none return a cert containing my actual domain name. DNS verified clean (apex points directly to Railway, no proxy in front).
Networking panel: the domain is configured and shows healthy. There is no "Regenerate certificate" or "Re-verify SSL" button — only Copy / Edit / Delete options. Edit only changes domain + port.
Ask: can a staff member please trigger a backend cert re-issuance without forcing a delete + re-add cycle (which would cause downtime and burn a weekly Let's Encrypt slot)?
Thanks!
3 Replies
Status changed to Open Railway • about 1 month ago
a month ago
Have you tried accessing the site from an incognito window?
If that doesn’t work, unfortunately the only thing I can suggest is to remove the domain from Railway and re-add it after 10-15 mins.
20 days ago
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.
18 days ago
Hello,
We had discovered an issue which would've affected services that have both a wildcard and exact-matching SAN for the same second-level domain, on the same service. We have been migrating traffic to our new edge network over the past week, which had tree lookup logic that erroneously preferred the wildcard certificate over the exact match, specifically if the exact-matching SAN was generated/renewed after the wildcard certificate.
We have since rolled out a fleet-wide patch to this issue, and added regression testing to make sure this doesn't happen again. We apologize for the inconvenience - please let me know if you have any further questions.
Status changed to Solved dizzydes90 • 18 days ago