a month ago
Service: web (Pro plan). DNS: Cloudflare, DNS-only / gray cloud (no CF proxy — Railway terminates TLS).
DESCRIPTION
Our web service has two custom domains attached: the bare apex instantestimatehq.com and the wildcard *.instantestimatehq.com. Intermittently — typically after a redeploy of the service — the apex stops working over HTTPS because the edge serves the WILDCARD-ONLY certificate for the apex SNI. A TLS wildcard matches only one label, so *.instantestimatehq.com does NOT cover the zero-label apex instantestimatehq.com, and browsers reject it with ERR_CERT_COMMON_NAME_INVALID.
We have HSTS enabled, so there is no click-through — the root domain is fully down until it flips back.
It is intermittent: as I write this it has self-resolved and the apex serves a correct cert again (a fresh CN=instantestimatehq.com cert issued today). It has flipped to broken and back several times.
Deleting + re-adding the apex custom domain fixes it temporarily, but it regresses after a later deploy, so we keep doing this by hand. We'd like a permanent fix.
The service appears to hold two SEPARATE single-SAN certs — an apex-only cert (SAN: instantestimatehq.com) and a wildcard-only cert (SAN: *.instantestimatehq.com) — and the edge (single label) is always fine because the wildcard legitimately covers it.
ERROR MESSAGES / EVIDENCE
- When broken:
$ curl -sS https://instantestimatehq.com/
curl: (60) SSL: no alternative certificate subject name matches target host name 'instantestimatehq.com'
$ echo | openssl s_client -servername instantestimatehq.com -connect instantestimatehq.com:443 \ | openssl x509 -noout -subject -ext subjectAltName subject=CN=*.instantestimatehq.com X509v3 Subject Alternative Name:
DNS:*.instantestimatehq.com <-- apex is NOT in the SAN
- When healthy (now):
subject=CN=instantestimatehq.com
X509v3 Subject Alternative Name:
DNS:instantestimatehq.com
DNS (context)
Both Apex and subdomains are CNAMEs to their *.up.railway.app targets. All records are gray cloud (DNS only).
REQUESTS
- What is the recommended configuration for this?
5 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 • 29 days ago
a month ago
Railway only supports CNAME records, so yes, you should be using a CNAME record regardless of whether the target is the apex domain or not. Not 100% sure about question 3 but I can tell you using something other than the CNAMEs provided may cause unexpected behavior.
0x5b62656e5d
Railway only supports CNAME records, so yes, you should be using a CNAME record regardless of whether the target is the apex domain or not. Not 100% sure about question 3 but I can tell you using something other than the CNAMEs provided may cause unexpected behavior.
a month ago
Mistake on our original ticket. Both Apex and subdomains are CNAMEs to their *.up.railway.app targets.
0x5b62656e5d
Railway only supports CNAME records, so yes, you should be using a CNAME record regardless of whether the target is the apex domain or not. Not 100% sure about question 3 but I can tell you using something other than the CNAMEs provided may cause unexpected behavior.
a month ago
The DNS record type does not affect wich certificate Railway binds to the apex SNI. DNS only decidedes where the client connects
a month ago
It seems this is a known issue https://station.railway.com/questions/custom-domain-serving-wrong-ssl-certific-243ef8a9#c1kt with a patch.
How exactly do we get our service on the patched edge build for this cert-selection bug?
okunp
It seems this is a known issue https://station.railway.com/questions/custom-domain-serving-wrong-ssl-certific-243ef8a9#c1kt with a patch. How exactly do we get our service on the patched edge build for this cert-selection bug?
a month ago
I think using Cloudflares proxy on the apex could work as a workaround so Cloudflare terminates the TLS instead.