Better support custom TLS situations when using a Docker

[byjrack]

Describe the feature or problem you’d like to solve

Currently there is no way (outside of forking i think) to support custom CA trust. Our enterprise controls are blocking the connections and outside of patching the server code or Dockerfile to include our custom cert and rehash the upstream image

Proposed solution

The easiest and least secure option would be a env we can pass in to use a custom transport w TLS verification disabled available via a env var flag.

https://github.com/github/github-mcp-server/blob/main/cmd/github-mcp-server/main.go#L141

And alternative would be to include a bootstrap model to use a volume mount to pull in a trusted cert at runtime. Possibly as part of the mcp settings schema or maybe it can use some of the CA trust support in the core of vscode.

Additional context

[SamMorrowDrums]

One option is just using the built binaries shared in the releases, as then they will use system and not docker trust chain.

https://github.com/github/github-mcp-server/releases/tag/v0.1.1

One comment suggested this had already been added to homebrew, so that could also be worth investigating to manage the binary.

[byjrack]

Good call didn't notice the binary release outside of the image release. 😵‍💫

 "github": {
          "command": "github-mcp-server",
          "args": [ "stdio" ],
          "env": {
            "GITHUB_PERSONAL_ACCESS_TOKEN": "${input:github_token}"
          }
        }

Easy tweak to the server ref just to test things out and couple quick tests seem to be fine. See it pushed to Homebrew as well so no path issues. Gatekeeper was being a bit picky for all those mac users, but easy to allow it when its blocked so that vscode can call it.

Still like to see the upstream team include TLS management in the Docker release so won't close the request just yet, but agreed a solid workaround.

[abatkin]

For now, you can also mount your local certificates into the container at path /etc/ssl/certs/ca-certificates.crt

[byjrack]

And with http endpoint support coming to most of the clients there are more options to avoid this.

And simple volume mount worked great in the mcp element args

...
"-v",
"~/mycacerts/cacert.pem:/etc/ssl/certs/ca-certificates.crt",
"ghcr.io/github/github-mcp-server"

[KevinEdry]

waiting on this too, I would like to just disable TLS checks, that would be the best option for my use-case.

[SamMorrowDrums]

I would like to just disable TLS

That will never be something we can officially support, as it comes with inherent risks.

You can fork the repo and allow that if you need it, but it's not something we can do.

[abatkin]

Back to mounting an enterprise certificate store into the container: It would be nice if GitHub specified an "official" path for where certificates can be mounted. For now, /etc/ssl/certs/ca-certificates.crt works, but I only know that because I worked backwards from the current container Dockerfile.

So my request is: Either bless that path, or pick some other other agreed-upon/stable path, symlink from there to what the actual image wants, and publish that path as part of the docs.

[SamMorrowDrums]

Cc @D1M1TR10S we can certainly document this. @omgitsads and I were discussing specific enterprise docs page in /docs with more details and examples, this sort of advice would have a good home there.

I think the reason we have delayed providing a blessed path explicitly is because you can just use the binaries we provide in the builds, and then your system certificate store will be used.

No harm in documenting all of this though. You're experimentation above is helpful, but I don't know how generic the advice is, as there's presumably a few ways to configure this on different platforms so the Docker mount point can be established, but the exact stuff to put there could vary.

Open to PRs in /docs/ghes.md

[byjrack]

Yeah the CA store is more driven by the base image and how the app manages it's trust. Likely would need to be metadata added to the MCP server definition if encapsulation gets an official call out.

I know the XCode client has it's own disable trust (whether it works is a different item). While I agree that disabling trust is a bad move if getting CA trust can be a pain in high control envs than maybe its something to put in the hands of the devs. Simple envvar for the image they could set in the definition and passed onto the fetch implementation being used.

And this situation I am sure is most common in enterprises, but it's not necessarily related to GHES specifically. We use GHEC so Github is an internet resource and hits a proxy in the middle so what's where we trip up on the TLS. GHES would have it's own CA trust issues, but you can hit GitHub API trust issues because of a couple of scenarios.

[SamMorrowDrums]

docs/enterprise-usage.md could work. The enterprise proxy scenario makes a lot of sense, I've encountered it myself over the years plenty of times.

Please feel free to start putting something together.

[github-actions[bot]]

This issue is stale because it has been open for 60 days with no activity. Leave a comment to avoid closing this issue in 120 days.

[killers10]

days with no activity. Leave a comment to avoid closing this issue in 120 days.

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity. Leave a comment to avoid closing this issue in 60 days.

[SamMorrowDrums]

👋 We're actively looking at improving GHES support for the MCP server! If you have thoughts on GHES-specific needs, please share your feedback in this discussion. 🙏