Incosistent Edge-IP certificates

tildoescode

PROOP

3 months ago

Hi,

it seems like there is some bug on the edge nodes with the ssl certificate propagation thats causing intermittent outages in my app.

The cert for the custom domain proxy.codecraft.internal.thecodecave.de seems to have an outdated wildcard on 69.46.46.* but a working one on 66.33.22.*. I seems like theres a drift between the nodes going on.

Thanks for the help!

$20 Bounty

1 Replies

Railway

BOT

3 months 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 • 3 months ago

ayalaa12

FREETop 5% Contributor

13 days ago

I tested the hostname again from a fresh resolver/TLS client. The stale-certificate condition is not reproducing now:

proxy.codecraft.internal.thecodecave.de CNAMEs to m4b3u690.up.railway.app
The current A answer is 69.46.46.117
With SNI set to the custom hostname, that edge returns a Let's Encrypt certificate whose subject/SAN is exactly proxy.codecraft.internal.thecodecave.de
Current validity: 2026-08-05T10:09:21Z through 2026-11-03T10:09:20Z

That indicates the edge certificate has since been reissued/propagated and the old wildcard is no longer being served by the currently resolved node.

For any recurrence, test every DNS answer independently while preserving SNI:

dig +short proxy.codecraft.internal.thecodecave.de

openssl s_client -connect <EDGE_IP>:443 \
  -servername proxy.codecraft.internal.thecodecave.de </dev/null 2>/dev/null |
openssl x509 -noout -subject -issuer -serial -dates -ext subjectAltName

If only one edge IP serves the wrong certificate, record that IP, certificate serial/SAN, and UTC timestamp and send those to Railway; certificate distribution across edge nodes is platform-side and cannot be repaired in the application.

Also keep the custom hostname as a CNAME to the Railway-provided target plus the Railway verification TXT record. Do not pin either observed edge IP with an A record—Railway explicitly says it does not publish static ingress IPs and A records are not supported for this setup:

https://docs.railway.com/integrations/api/manage-domains#dns-configuration

Railway's current SSL troubleshooting guide confirms that custom certificates are automatic, normally issue within an hour, and may take up to 72 hours in exceptional cases:

https://docs.railway.com/networking/troubleshooting/ssl

So the present state is healthy. If the intermittent split returns, the per-IP/SNI evidence above is the actionable proof Railway needs to identify the stale edge node.

Welcome!