github / github/copilot-cli

trust/skip TLS verification for MCP HTTP servers

Ouverte
#4,801 0 commentaires 1 réaction 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

triage
Langage dominant
Shell
Étoiles
11.2k
Forks
1.9k
Merge moyen
14 h 16 min
PR mergées (30 j)
6

Description

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

  1. device that presents a self-signed certificate whose Subject/SAN is not a valid match for the IP address (e.g., CN/SAN =  * )
  2. Export and trust the CA:  export NODE_EXTRA_CA_CERTS=~/ctrlx.pem 
  3. 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.

Guide de contribution

Ouvrir le guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Piste de recherche

Lisez l’issue connexe #4364, puis suivez la couche réseau MCP basée sur Rust utilisée lorsque /mcp se connecte à un serveur HTTP. Reproduisez l’échec avec le certificat comportant un SAN non valide et déterminez où s’appliquerait une option non sécurisée propre à chaque serveur ou une variable d’environnement documentée ; le travail sera terminé lorsque la CLI pourra se connecter à ce serveur via la configuration prise en charge.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Évaluation

Stack technique
rust
Domaine
networking, security
Type d'issue
Fonctionnalité
Difficulté
4/5
Temps estimé
3-5 jours
Activité
Active
Clarté
À clarifier
Accessibilité débutants
38/100

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.