GitHub Actions self-hosted runner and GitHub.com: can custom CA trust remain workflow-scoped?

Integration boundary

The goal is to define the supported trust boundary for a GitHub Actions self-hosted runner that must reach GitHub.com while a workflow step also connects to an internal service using a privately issued TLS certificate. The runner’s control traffic and job-step traffic may share the host or container trust store, but the documented behavior needs to be confirmed for the runner release in use.

For a containerized self-hosted runner, does the image’s CA bundle govern both GitHub registration and workflow-step HTTPS requests? Is there a supported, workflow-scoped mechanism for trusting a private CA without modifying the host, image, or runner package? DNS resolution also needs an explicit boundary: which resolver is used by the runner process versus containerized steps, and can resolver selection be separated from TLS trust configuration?

Assume GitHub.com and api.github.com remain publicly trusted, and distinguish certificate-validation failures from name-resolution failures. Before relying on this design, verify the applicable runner release notes and test the same job against the intended runner image and network path.

• Can a workflow step install CA trust only for its own process, or is host/image-level trust the only supported path?
• Which documented configuration separates DNS resolver behavior from TLS certificate validation?