Skip to main content
Corporate networks often restrict outbound traffic in two ways: all egress must pass through an explicit proxy, and/or outbound TLS is intercepted and re-signed with an internal root certificate authority that Node.js does not trust. Either one breaks Rallly’s outbound HTTPS requests. License activation, which connects to licensing.rallly.co on port 443, is usually where you notice it first, but any outbound call is affected. Some networks require both fixes below together. If your server can reach the internet directly and your network does not intercept TLS, none of this applies and you can skip this page.

​
Routing traffic through a proxy

Rallly honours the standard HTTP_PROXY, HTTPS_PROXY, and NO_PROXY environment variables for outbound requests. Set them in .env:
Available from v4.12.3 and later. Earlier versions ignore these variables entirely, so if you’re on an older version, update first.
  • If your proxy requires basic authentication, include the credentials in the URL: http://user:password@proxy.internal.example.com:8080.
  • Loopback traffic is never sent through the proxy, and the container healthcheck bypasses proxy settings automatically.
  • The NO_PROXY entries above keep traffic to the stack’s bundled storage (garage) and database (db) services off the proxy.
  • The lowercase variants (http_proxy, https_proxy, no_proxy) are also recognised. If both no_proxy and NO_PROXY are set, the lowercase value wins.
Apply the change with ./rallly.sh restart.

​
Trusting a custom root CA

If your network intercepts TLS, the proxy terminates each HTTPS connection and re-signs it with your organisation’s internal root CA. Node.js only trusts its built-in certificate authorities, so these connections fail until you tell Rallly about the internal CA. Set CA_CERT_FILE in .env to the absolute path of a PEM certificate file on the host:
The file is mounted read-only into the web container and added to Node’s trust store. It is trusted in addition to the built-in certificate authorities, so certificates from public websites keep validating as before. When CA_CERT_FILE is unset, this feature is completely inert. Apply the change with ./rallly.sh restart. Node reads the file once at startup, so if you later replace the certificate on disk, restart again to pick it up.
If CA_CERT_FILE points to a path that doesn’t exist, the stack refuses to start with an error naming the path. This is deliberate: it catches typos that would otherwise fail silently.
To verify the certificate is mounted and readable inside the container:
Success prints the CA’s subject line. Unable to load certificate means the file at CA_CERT_FILE is missing or not valid PEM.

​
Obtaining the certificate

The file must be in PEM format: base64 text starting with -----BEGIN CERTIFICATE-----. Multiple certificates can be concatenated into one file. The best source is your IT department: ask for the organisation’s root CA certificate. The root stays valid as the proxy reissues per-host certificates, so this is the option that keeps working. If IT hands you a DER-encoded file (binary, often .crt or .cer), convert it:
As a fallback, you can export a certificate from the chain the proxy presents. Run this from the affected server:
Note that openssl does not read the proxy environment variables. On a network with no direct egress, add -proxy proxy.internal.example.com:8080 to the command so the connection goes through your proxy. Two caveats: this writes only the leaf certificate, so it stops working when the proxy reissues it — treat it as a stopgap until IT provides the root. It also doubles as a diagnostic — inspect the exported certificate’s subject:
If the subject names your organisation instead of licensing.rallly.co, TLS interception is confirmed.

​
Diagnosing failures

Watch the logs while triggering the failing request (for example, a license activation attempt):