19 days ago
Two custom domains will not serve TLS, even though their certificates have been issued.
Affected:
- www.tldrsearch.ru -> service "happy-stillness" (frontend), CNAME target 7sye6189.up.railway.app
-
- api.tldrsearch.ru -> service "geo" (api), CNAME target 6wcnl3lh.up.railway.app
- Project: spirited-youth, environment: production.
Symptom:
- HTTPS to either custom domain fails. The TLS handshake is reset by the edge with "no peer certificate available" (openssl: 0 bytes read, server closes). Browsers show a TLS/connection error page.
-
- The native *.up.railway.app domains work perfectly (frontend happy-stillness-production.up.railway.app returns 200), so the apps/deploys are healthy. Only the custom-domain TLS is broken.
What I have verified:
- DNS is correct and the dashboard shows it verified (green): CNAME www -> 7sye6189.up.railway.app, CNAME api -> 6wcnl3lh.up.railway.app, plus the matching _railway-verify.www / _railway-verify.api TXT records.
-
- The certificates ARE issued. Certificate Transparency (crt.sh?q=tldrsearch.ru) shows Let's Encrypt issued certs for both hostnames today, 2026-06-18 ~11:18-11:19 UTC. Yet 3+ hours later the edge still does not present them.
-
- No CAA records on the zone (issuance is not blocked).
-
- Domains were already deleted and re-added once (hence the current targets 7sye6189 / 6wcnl3lh), and services redeployed. The edge still resets.
This looks like an edge-side issue: the issued certificate is not being deployed/bound to the edge node serving these hostnames.
Request: could you please force the edge to (re)bind and serve the already-issued certificates for www.tldrsearch.ru and api.tldrsearch.ru? Happy to provide further details. Thank you!
Pinned Solution
19 days ago
I can confirm that the Amsterdam POP has valid TLS certificates for www.tldrsearch.ru. It does not have valid certificates for the pure apex tldrsearch.ru as that domain has not been configured on Railway. If you are having issues with the www subdomain specifically, then it sounds like an issue with your local machine (e.g. not having up to date certificate chains) or your ISP. Some ISPs enforce censorship by hijacking TLS handshakes and responding with invalid certificates.
If you would like to debug further, please run the following command and show me the output:
openssl s_client -connect www.tldrsearch.ru:443 -servername www.tldrsearch.ru -showcerts </dev/null
9 Replies
19 days ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • 19 days ago
19 days ago
I'm able to access your site just fine. Try accessing the site from an incognito browser or a different device.
Attachments
19 days ago
Thanks for checking! The problem is regional — it works from your location but is still fully broken from ours (Russia), where all our users are. Not a client issue: tested in incognito and from a second network, browsers show the TLS error page every time.
Proof from our region, same Railway edge IP 69.46.46.58, TCP 443 open:
- SNI happy-stillness-production.up.railway.app -> serves a valid cert, CN=*.up.railway.app (TLS to your edge works fine from here)
-
- SNI www.tldrsearch.ru -> TLS reset, "no peer certificate available" (openssl: 0 bytes read)
So the edge PoP serving our region has the *.up.railway.app wildcard loaded but NOT the www.tldrsearch.ru / api.tldrsearch.ru custom-domain certificate. The cert is issued (confirmed in CT logs) and works on some PoPs, just not the one serving Russia. Could you check whether the issued certs are propagated to ALL edge PoPs, specifically the one serving RU / the 69.46.46.0/24 edge? Happy to run further tests from here. Thanks!
19 days ago
Update: I tested from multiple devices, incognito, and over a VPN — still completely broken for us. So it's definitively not client- or browser-side. The certificate for www.tldrsearch.ru / api.tldrsearch.ru is simply not being served by the edge PoP that handles our traffic (Russia), while the *.up.railway.app wildcard on the very same IP works. Could you push the issued custom-domain certs to that PoP (the 69.46.46.0/24 edge serving RU)? Thanks!
19 days ago
Hi, can you visit https://railway.com/.railway/cdn-trace and let me know what the pop field is equal to? Thank you.
19 days ago
pop=ams1 (node=kxr8). Full trace from our network:
v=hikari:0.1.2:1305a1583dc517b7e2603638b5710b21
r=production-hikari-dpams-1
pop=ams1
node=kxr8
So we're served by the Amsterdam PoP. That's the edge missing the cert: from ams1, SNI=*.up.railway.app serves the wildcard fine on the same IP (69.46.46.58), but SNI=www.tldrsearch.ru / api.tldrsearch.ru resets with no certificate. The issued Let's Encrypt certs just aren't bound on ams1. Could you rebind/push them to that PoP? Thanks!
19 days ago
I can confirm that the Amsterdam POP has valid TLS certificates for www.tldrsearch.ru. It does not have valid certificates for the pure apex tldrsearch.ru as that domain has not been configured on Railway. If you are having issues with the www subdomain specifically, then it sounds like an issue with your local machine (e.g. not having up to date certificate chains) or your ISP. Some ISPs enforce censorship by hijacking TLS handshakes and responding with invalid certificates.
If you would like to debug further, please run the following command and show me the output:
openssl s_client -connect www.tldrsearch.ru:443 -servername www.tldrsearch.ru -showcerts </dev/null
19 days ago
Thanks phin. Re-ran it from a Netherlands datacenter (NovoServe, AS204601, Lelystad) — not Russia, not a consumer ISP, no DPI on the path — and it still fails: CONNECTED to 69.46.46.58, "no peer certificate available", 0 bytes read (server closes before ServerHello).
The www target 7sye6189.up.railway.app resolves to 69.46.46.58. On that exact IP, only the SNI differs:
- SNI=www.tldrsearch.ru -> reset, no cert
-
- SNI=happy-stillness-production.up.railway.app -> valid CN=*.up.railway.app (Let's Encrypt E7)
A censoring middlebox isn't inside a NovoServe NL datacenter, and can't serve a valid LE cert for one SNI while resetting another on the same TCP connection. So this is server-side and SNI-selective on 69.46.46.58 — ams1 may have the www cert on some ingress nodes but not on the IP that 7sye6189 (the www target) actually resolves to. Could you rebind on that specific ingress IP? Same for api -> 6wcnl3lh (69.46.46.22). Thanks!
19 days ago
Resolved — thank you! Both www.tldrsearch.ru and api.tldrsearch.ru now serve valid certs and work from our region (www returns 200, API health OK, CORS good). The rebind on the ams1 ingress fixed it. Appreciate the help!
Status changed to Solved 0x5b62656e5d • 18 days ago