Gitpod self-hosted behind an internal CA: cluster-level CA bundle vs per-workspace trust configuration

On a Gitpod self-hosted installation fronted by an internal CA, the dashboard loads and workspaces start, but HTTPS operations inside workspace terminals (git operations against internal repos, Node.js tooling, Java builds) fail certificate validation. The installer supports supplying a custom CA at the installation level, yet several runtimes inside the workspace image do not read the system trust store by default.

There appear to be two documented directions: rely on the installation-level custom CA configuration and expect it to propagate into workspace images, or explicitly configure workspace-side trust (for example NODE_EXTRA_CA_CERTS for Node.js, a Java keystore import, or an image that bundles the CA). Each has different maintenance implications when the CA rotates or when many teams use different base images.

Assume a recent self-hosted release; exact configuration keys vary between versions, so answers should note version assumptions.

Which parts of the certificate chain does the installation-level custom CA setting actually cover—ingress only, or also the workspace image's system trust store?

Is setting per-runtime variables like NODE_EXTRA_CA_CERTS the supported approach for workspace tooling, or is rebuilding the workspace image with the CA preferred?

How can one verify, from inside a fresh workspace, which CA bundle is actually in effect?