Repository navigation
Allow a custom CA certificate per custom HTTP MCP server #68033
Description
Summary
Allow a workflow to configure a custom CA certificate for an individual custom HTTP MCP server, so the gateway/engine trusts that server's TLS when it is served with a private CA. The CA would be set by the workflow author in the mcp-servers entry (alongside url and headers), scoped to that one server, and applied only to the outbound connection to it.
Motivation
A custom HTTP MCP server that enforces TLS with a private or self-signed CA cannot be used today without trusting that CA, and gh-aw exposes no per-server option for it. The workarounds are broad: mutate the whole runner's trust store (mkcert -install), or run a socat bridge that drops TLS on a hop.
A scoped, author-set CA is narrower and safer: it trusts one named upstream instead of the entire store, and it is set at compile time in the reviewed workflow file, so it gives the agent no new runtime capability. It is the direct counterpart to the existing OIDC auth for custom HTTP MCP servers (gh-aw-mcpg#2878): another connection property of the same server, configured the same way.
Activity
Copilot commentedon Oct 13, 2026
The agent encountered an error and was unable to start working on this issue: This may be caused by a repository ruleset violation. See granting bypass permissions for the agent, or please contact support if the issue persists. (Request id: EBF1:39E394:2679C:35F24:6ACE4536)
pelikhan commentedon Oct 16, 2026
Current-state refresher (2026-10-16): Still relevant; implementation is pending.
Current main's MCP configuration schema uses an explicit property set with
additionalProperties: false. The custom MCP configuration/rendering implementation carries connection fields such as URL, headers and authentication, but does not expose the requested per-server CA trust configuration. Existing OIDC support addresses authentication, not which CA signs an upstream TLS certificate.There is now an open draft, #69436, specifically for this request. At inspection it had no changed files, so it is tracking work rather than evidence that the capability has landed. The earlier agent-start failure in this issue likewise did not implement anything.
Remaining gap: an author-controlled CA option wired through validation, gateway/engine configuration and certificate provisioning, with tests demonstrating trust is scoped to the selected server. Static inspection only; no private-CA MCP connection was attempted.
pelikhan commentedon Oct 22, 2026
Rechecked 2026-10-22: partially addressed upstream; keep open for gh-aw integration. Remote
main:ffdd9c9efe6acef74b5529d63d7dc6103d6a0889.There is concrete progress since the previous refresher: github/gh-aw-mcpg#15067 merged on October 16. Its per-server HTTP transport and configuration contract support
caCertFile/ca_cert_filewithout disabling hostname verification or changing global trust.However, the current gh-aw MCP schema still has no per-server CA field, and the HTTP property renderer does not emit one. #69436 was closed unmerged, so it is not a shipped gh-aw fix. The API-proxy
sandbox.agent.ca-certsetting is a different connection scope.Next: expose and validate an author-set field, provision/mount the PEM for the gateway, emit its scoped setting, and ensure the pinned gateway includes the upstream implementation. Cover two HTTP servers trusting different CAs, invalid/missing PEMs, and unchanged default TLS. No private-CA runtime connection was attempted here.
Support per-server custom CA trust for HTTP MCP servers (github#71229)