a month ago
I'm trying to set up two custom domains for my service (10key-app / web / production):
-
www.10key.app — Added successfully, Railway shows "Issuing TLS certificate", but when I visit https://www.10key.app in Chrome it shows "Your connection is not private" with error NET::ERR_CERT_COMMON_NAME_INVALID. The browser is being served Railway's wildcard cert for *.up.railway.app instead of a cert for www.10key.app.
-
10key.app (apex/root) — Stuck on "Waiting for DNS update".
For the apex domain issue: Railway's "Show DNS records" instructs me to add a CNAME record for the apex domain (@), but my DNS provider does not support CNAME on the root domain (this is a standard DNS limitation — RFC 1034). My provider only supports A, AAAA, CNAME, MX, TXT, SRV, CAA, NS, HTTPS, SVCB, and TLSA records.
I added the TXT verification record (_railway-verify) as instructed.
I also tried using an A record pointing @ to the IP that the Railway CNAME target (s9yjg7pg.up.railway.app) resolves to (69.46.46.80), but I understand this may break if Railway changes the IP.
The www.10key.app domain is currently broken for end users — they see a full-page SSL warning and cannot access the application.
Questions:
- Why is the TLS certificate for www.10key.app not being issued/served? Is there something blocking it on Railway's side?
- Does Railway provide a static A record IP for apex/root domain support?
- If not, what is the recommended approach for customers whose DNS providers don't support ALIAS/ANAME records?
- Is there a way to make the apex domain work without migrating to a different DNS provider (e.g., Cloudflare)?
Service: 10key-app / web / production
Domains: www.10key.app, 10key.app
DNS Provider: does not support ALIAS/ANAME
Browser error: NET::ERR_CERT_COMMON_NAME_INVALID on https://www.10key.app
Certificate served: *.up.railway.app (should be www.10key.app)
1 Replies
a month ago
This thread has been opened as a public bounty so the community can help solve it. The thread and any further activity are now visible to everyone.
Status changed to Open Railway • about 1 month ago
a month ago
Resolved — and here's the why, plus answers to each question.
The fix for both domains is to front them with Cloudflare (proxied / orange cloud), which is now live on 10key.app. Verified just now: www.10key.app and 10key.app both serve a valid CN=10key.app cert (Google Trust Services, SAN 10key.app + *.10key.app), both return HTTP 200, and the apex correctly redirects to www. The NET::ERR_CERT_COMMON_NAME_INVALID is gone because Cloudflare now terminates TLS in front of Railway, so Railway's *.up.railway.app wildcard is no longer what the browser sees.
- Why was the cert for www.10key.app not being served?
While Railway shows "Issuing TLS certificate," its edge falls back to serving the default *.up.railway.app wildcard for any hostname it doesn't yet have a cert for — and that wildcard doesn't match www.10key.app, which is exactly what triggers ERR_CERT_COMMON_NAME_INVALID. Railway only issues the per-domain Let's Encrypt cert after the domain resolves to Railway's edge and the ACME challenge completes; until then you get the mismatched fallback. (Nothing was blocking it on your DNS — no CAA records present.) Once you put Cloudflare in front, you no longer need Railway's cert at all — Cloudflare issues and serves the public cert, so the "Issuing…" state becomes irrelevant.
- Does Railway provide a static A-record IP for apex support?
No. Railway does not publish or guarantee a static edge IP — the IP behind the CNAME target (e.g. 69.46.46.80) can change without notice. Pointing an apex A record at it works for routing temporarily, but it's unsupported and brittle, and worse: Railway's edge will serve its wildcard cert for the bare apex hostname, reproducing the same ERR_CERT_COMMON_NAME_INVALID. So the A-record-to-IP route fails on two counts — IP instability and cert mismatch. Don't rely on it.
- Recommended approach when your DNS provider doesn't support ALIAS/ANAME?
Move your domain's nameservers to Cloudflare (free). This is not a registrar migration — your domain registration/ownership stays exactly where it is; you only delegate DNS. Cloudflare does apex CNAME-flattening automatically (solving the RFC 1034 limitation), and when the records are Proxied (orange) it terminates TLS with a valid cert for both the apex and www. This is the setup now running on 10key.app.
- Can the apex work without using Cloudflare?
Realistically, no clean option if your provider supports none of ALIAS / ANAME / CNAME-flattening:
Registrar URL forwarding (10key.app → https://www.10key.app) works only if your registrar serves a valid HTTPS cert on the apex during the redirect — many don't, which just reproduces the warning.
Apex A-record to Railway's IP — brittle + hits the cert bug (see #2).
Delegating DNS to Cloudflare is the only approach that reliably solves both the apex-CNAME limitation and the certificate. It's ~5 minutes and free, and again — you keep your registrar.
Cloudflare settings to use (for anyone replicating this): SSL/TLS mode = Full (not Flexible → redirect loop; not Full (strict) → can reject the Railway origin leg, which only presents its wildcard). Keep the Railway custom domains added so Railway's router still accepts the Host header — but you can safely ignore Railway's "Issuing TLS certificate" / "Waiting for DNS update" statuses, since Cloudflare now owns the public TLS.