trust/skip TLS verification for MCP HTTP servers
維護者通常 1 天內回覆
還沒有人認領這個 Issue。
評估
- 難度
- 4/5
- 預估耗時
- 3-5 天
- 新手友好度
- 38/100
- Issue 類型
- 功能
- 描述清晰度
- 需要釐清
- 活躍度
- 活躍
- 技術堆疊
- rust
- 領域
- networking, security
研究方向
閱讀相關 issue #4364，然後追蹤 /mcp 連線至 HTTP 伺服器時所使用的以 Rust 為基礎的 MCP 網路層。使用 SAN 無效的憑證重現該失敗，並確定應在哪裡套用每個伺服器的非安全選項或有文件說明的環境變數；當 CLI 能夠透過受支援的設定連線至該伺服器時，即表示完成。
由索引模型根據 Issue 內容生成。
描述
Describe the feature or problem you'd like to solve
trust/skip TLS verification for MCP HTTP servers with invalid SAN certs (rustls hard-fails, no insecure option)
Proposed solution
Copilot CLI cannot connect to a remote HTTP MCP server whose TLS certificate has an invalid Subject Alternative Name (e.g., a literal * instead of a proper wildcard/IP SAN), even after the cert's issuing CA is explicitly trusted. There is no config option or environment variable to bypass hostname/certificate verification for a specific MCP server, which blocks use cases like connecting to on-prem/IoT devices with embedded mcp server and self-managed certificates addressed by IP Address.
Steps to reproduce
- device that presents a self-signed certificate whose Subject/SAN is not a valid match for the IP address (e.g., CN/SAN = * )
- Export and trust the CA: export NODE_EXTRA_CA_CERTS=~/ctrlx.pem
- Run copilot , then /mcp — the server still fails to connect.
Requested behavior
The CLI offers a supported way to relax verification for a specific MCP server (e.g., a per-server tls.insecureSkipVerify or honoring a documented env var), similar to how curl -k or Node's NODE_TLS_REJECT_UNAUTHORIZED=0 work for other tools.
Example prompts or workflows
NA
Additional context
• Related: #4364 documents a similar underlying issue (rustls/rustls-platform-verifier being stricter than curl/Node/Chrome for enterprise MCP registry TLS), suggesting this is a broader gap in the Rust-based MCP networking layer, not specific to one code path.
• For comparison, Claude Code and Gemini CLI's MCP clients run on Node.js, so NODE_TLS_REJECT_UNAUTHORIZED=0 works as an (insecure) escape hatch there; Copilot CLI has no equivalent because of the runtime split.
• Use case: connecting to on-prem/IoT devices reachable only via IP address with vendor-managed self-signed certificates that can't easily be reissued with a proper SAN.
- 主要語言
- Shell
- 星號
- 11.2k
- 分支
- 1.9k
- 平均合併
- 17 小時 6 分鐘
- 30 天內合併 PR
- 5
環境準備
- 沒有 Dockerfile 或 Docker Compose 檔案
- 沒有 Pull Request 範本
- 閱讀貢獻指南
從這裡開始
- 先讀完整個 Issue，再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫，在一個分支上完成修改。
- 送出 Pull Request，並在描述裡引用這個 Issue 編號。
github/copilot-cli 的其他 Issue
-
area:sessions
難度 2/5 1-3 小時 新手友好度 72/100
github/copilot-cli#4996 ·
維護者通常 1 天內回覆
-
triage
難度 1/5 1 小時以內 新手友好度 88/100
github/copilot-cli#4963 · 1 則留言 ·
維護者通常 1 天內回覆
-
triage
難度 2/5 1-3 小時 新手友好度 75/100
github/copilot-cli#4932 ·
維護者通常 1 天內回覆
-
triage
難度 2/5 1-3 小時 新手友好度 78/100
github/copilot-cli#4909 ·
維護者通常 1 天內回覆
-
triage
難度 2/5 1-3 小時 新手友好度 76/100
github/copilot-cli#4906 ·
維護者通常 1 天內回覆
查看 github/copilot-cli 的全部 Issue
相似的 Issue
-
難度 1/5 1 小時以內 新手友好度 92/100
維護者通常 2 天內回覆
-
難度 2/5 1-3 小時 新手友好度 72/100
obra/superpowers#2445 ·
維護者通常 5 天內回覆
-
package-update
難度 2/5 1-3 小時 新手友好度 78/100
oSoWoSo/vOid_Community_repOsitory#240 · 1 則留言 ·
維護者通常 1 天內回覆
-
ai-inspected
難度 2/5 1-3 小時 新手友好度 88/100
維護者通常 1 天內回覆
-
[Bug]: atuin doctor reports "Hub (authenticated)" while the client syncs with a self-hosted server未關閉
難度 2/5 1-3 小時 新手友好度 76/100
維護者通常 1 天內回覆