You can retrieve the file via dashboard by opening your Postgres Service Console, and navigate to /var/lib/postgresql/data/certs in the Files tab, and you can download the cert file there

mayori's path is right, that's where the CA lives. But retrieving it isn't enough for verify-full, and it's worth knowing why before you build against it.

I checked the certs on a Railway Postgres service:

$ openssl x509 -in /var/lib/postgresql/data/certs/server.crt \

-noout -subject -issuer -ext subjectAltName -dates

subject=CN=localhost

issuer=CN=root-ca

X509v3 Subject Alternative Name:

DNS:localhost

notBefore=Jun 14 23:20:33 2026 GMT

notAfter=Sep 11 23:20:33 2028 GMT

$ openssl x509 -in /var/lib/postgresql/data/certs/root.crt \

-noout -subject -issuer -dates

subject=CN=root-ca

issuer=CN=root-ca

Three things follow.

The server cert is issued for localhost only. The SAN contains no Railway hostname, not the internal .railway.internal name, not the TCP proxy name. verify-full checks the connection hostname against the SAN, so it will fail on hostname verification whatever CA you install. verify-ca works (you get encryption plus proof the cert was signed by that root), but verify-full does not, and the gap between them is MITM resistance, which is presumably the reason you wanted it.

The CA is self-signed and per-service (root-ca issuing itself; note the root.key and root.srl sitting beside it in that directory, it was generated in the container). There's no shared Railway root CA to fetch from an HTTPS API, which I think is what your question was really reaching for. The Files tab is the retrieval mechanism.

Related: root.key is downloadable from that same panel. It's your own container so it isn't a vulnerability, but anyone holding it can mint certs your client would trust, worth not copying that directory around.

Validity runs to Sep 2028, so rotation isn't near-term, but a pinned root.crt will need replacing eventually, and I don't know whether a volume reset regenerates it.

Practical options: use verify-ca with sslrootcert pointed at root.crt and accept that the hostname isn't verified; or keep the connection on the private network, where the traffic doesn't leave Railway and verify-full buys you less; or terminate TLS at something you control with a cert issued for the name you actually connect to.

The open question for Railway: is there a supported way to get a server cert with the service's real hostname in the SAN, or is verify-full simply not achievable against Railway Postgres as shipped? That's the part only staff can answer.