Repository navigation
Conversation
Remote MCP servers can now carry a tls config with a CA file, inline CA PEM, or a pinned SHA256 certificate fingerprint, scoping trust to that server only. System verification is unchanged for everything else.
github-actions
Bot
added
the
needs:compliance
|
This PR doesn't fully meet our contributing guidelines and PR template. What needs to be fixed:
Please edit this PR description to address the above within 72 hours, or it will be automatically closed. If you believe this was flagged incorrectly, please let a maintainer know. |
![opencodejr[bot]](https://avatars.githubusercontent.com/in/5497873?s=60&v=4){kind=small}
There was a problem hiding this comment.
The ca_file / ca_pem part works, and the new tests pass against a real local TLS server. Fingerprint pinning does not yet do what the docs promise.
I pinned test certificates by their correct fingerprints through buildTlsCa and withTlsCa:
- A self-signed certificate with SAN
IP:127.0.0.1connects. - A self-signed appliance-style certificate (
CN=opnsense.local, no IP SAN, reached by IP) fails withERR_TLS_CERT_ALTNAME_INVALID. - A leaf certificate issued by a private CA fails with
UNABLE_TO_VERIFY_LEAF_SIGNATURE.
The test fixture is self-signed with CA:TRUE and the right SANs, so only the case that works is tested. Details are inline.
Public API: adds an optional tls object to remote MCP server config with ca_file, ca_pem and fingerprint (exported as ConfigMCP.Tls / Mcp.TlsConfig). It is backwards compatible: existing configs are unchanged.
The typecheck script could not run in my environment (bun check is missing); tsc --noEmit in packages/core reported no errors.
There was a problem hiding this comment.
The new commits only merge dev into the branch. None of the PR's own files changed, so both earlier threads (fingerprint pinning treats the presented certificate as a CA, and the docs don't mention that limit) are still open. The MCP TLS tests still pass at the new head.
Public API: unchanged since the last review. The PR adds an optional tls object (ca_file, ca_pem, fingerprint) to remote MCP server config, which is backwards compatible.
There was a problem hiding this comment.
The new commit only merges dev and changes none of the PR's files, so there is nothing new to review, and the MCP TLS tests still pass. The fingerprint-pinning behaviour from my first review is unchanged: pinning only works for self-signed certificates whose SAN matches the URL host.
Public API: unchanged since the last review. The PR adds an optional tls object (ca_file, ca_pem, fingerprint) to remote MCP server config, which is backwards compatible.
Issue for this PR
Part of #40111 — per-server TLS trust for remote MCP servers. This is the explicit
tlsconfig only; trust-on-first-use for private-network servers lands in a follow-up PR built on this one.What does this PR do?
Adds a
tlsconfig block to remote MCP servers:ca_file(CA certificate file path,~and workspace-relative),ca_pem(inline CA PEM), andfingerprint(SHA256 pinning of the presented certificate, like an SSH host key). Trust is scoped to that one server; system verification is unchanged everywhere else.Fingerprint pinning uses a one-time pre-flight TLS socket that reads the presented certificate, compares the fingerprint, and promotes the verified certificate to the trust anchor for the connection.
How did you verify your code works?
Checklist
Added by the opencode bot (AI-generated).
Related: #40111, #23506
Public API: adds optional
tls{ ca_file, ca_pem, fingerprint } to remote MCP server config (backwards compatible)