Repository navigation
Description
Problem
Many MCP servers run inside private networks without publicly trusted TLS certificates.
Examples include:
- OPNsense / pfSense firewalls
- TrueNAS / Synology appliances
- Proxmox servers
- Kubernetes clusters
- Home Assistant
- Enterprise internal services
These services commonly use:
- Self-signed certificates
- Private certificate authorities
- Internal DNS names
- Private IP addresses
MCP clients reject these connections because the certificates are not signed by a public CA.
Current workarounds are not ideal:
- Disable TLS verification globally (
NODE_TLS_REJECT_UNAUTHORIZED=0) - Modify the operating system certificate store
- Use
NODE_EXTRA_CA_CERTS - Run a local proxy/bridge to terminate TLS
- Require users to replace appliance certificates
These approaches reduce security, add complexity, or defeat simple MCP setup.
Proposed Solution
Add per-MCP-server TLS trust configuration, scoped to one server only.
Option 1: Custom CA file
{
"type": "http",
"url": "https://192.168.1.1/mcp",
"tls": {
"caFile": "~/.config/mcp/opnsense-ca.pem"
}
}Option 2: Embedded CA certificate
{
"type": "http",
"url": "https://192.168.1.1/mcp",
"tls": {
"caPem": "-----BEGIN CERTIFICATE-----..."
}
}Option 3: Certificate fingerprint pinning
Similar to SSH host key verification.
{
"type": "http",
"url": "https://192.168.1.1/mcp",
"tls": {
"fingerprint": "SHA256:ABC123..."
}
}Useful for home labs, network appliances, private IP services, and devices without public DNS.
Why NODE_EXTRA_CA_CERTS is not sufficient
1. Process-wide, not MCP-server scoped
OpenCode process
|
+-- Homelab appliance MCP server (installed on the homelab appliance e.g opnsense, pfsense, docker host)
+-- GitHub API
+-- Other MCP servers
+-- Other HTTPS requests
Adding a private CA via NODE_EXTRA_CA_CERTS trusts that CA for all TLS connections in the process.
2. Requires runtime/environment configuration
Users must understand where to place cert files, how to set env vars, how the client launches Node, and whether it respects Node env vars. This breaks the expected workflow:
- Install MCP server
- Import MCP configuration
- Use MCP
3. Inconsistent across MCP clients
Different clients bundle their own Node runtime, use Electron, or different HTTP libraries.
4. No certificate pinning
Cannot express "trust this one specific certificate":
SHA256:AA:BB:CC:DD:...
Security Requirements
The implementation should:
- Keep TLS verification enabled by default
- Avoid global TLS bypasses
- Scope trust to one MCP server
- Show when custom trust is configured
The implementation should not require NODE_TLS_REJECT_UNAUTHORIZED=0 or --ignore-certificate-errors.
Expected User Experience
- Install MCP plugin on homelab appliance with self signed cert
- Download/generate MCP configuration
- Add MCP server to opencode project
- Start using the MCP
The user should not need to manually configure certificates, modify system trust stores, or install additional bridges.
Activity
github-actions commentedon Aug 2, 2026
This issue might be a duplicate of an existing issue. Please check:
Your proposal is more detailed (supporting CA files, embedded certs, and fingerprint pinning) while #23506 proposes a simpler
insecureflag, but they address the same underlying need. Please consider adding your input there, or a maintainer may merge these.karup commentedon Aug 2, 2026
I know this is a partial duplicate of a few others but I wanted to provide an alternative for home labs and cert workarounds without compromising security.
#23506
#14696
#26862
#1694
karup commentedon Aug 20, 2026
@nexxeln Any movement on this ?
karup commentedon Sep 12, 2026
Really need this merged for home labs
opencodejr commentedon Oct 28, 2026
Thanks for the detailed write-up, @karup. You're asking for per-server TLS trust settings for remote MCP servers (a custom CA file, an embedded CA, or a pinned certificate fingerprint), so that self-signed or private-CA servers on homelab and internal networks work without turning off TLS checks for the whole process.
In v2, remote MCP servers currently only accept
headers(plus OAuth). There's no TLS option yet, so this is a new feature rather than a bug. It can't be done as a plugin today either, because plugins can't change how the MCP connection is made. Maintainers will consider it.Related: