Enterprise MCP registry unreachable on macOS: rustls rejects private CA cert (Apple -67901), fail-closed blocks all MCP

Describe the bug

On macOS, Copilot CLI 1.0.78 fails to validate MCP servers against an enterprise custom MCP registry because TLS verification rejects the registry's private-CA certificate with Apple error -67901 (certificate is not standards compliant).

The CLI then treats the registry as unreachable and fail-closes: all non-default / custom MCP servers are reported as blocked by policy, even though:

• the registry is reachable over HTTPS from the same machine (curl / Node fetch return HTTP 200)
• Chrome trusts and displays the certificate without issue
• the same servers are listed in the enterprise registry and were usable with an earlier CLI version (allowlist check previously went through the Node/JS path)

This looks like a regression from moving the MCP registry allowlist HTTP client into the Rust runtime (reqwest + rustls-platform-verifier / Apple Security.framework), which applies stricter Apple TLS rules than Node/Chrome.

Affected version

• GitHub Copilot CLI 1.0.78 (auto-updated ~2026-08-03 / 2026-08-04)
• macOS 26.x (Apple Silicon)
• Enterprise / org Copilot policy: custom MCP Registry URL + Registry only allowlist

Previously worked on an earlier 1.x CLI where registry allowlist verification still lived in the JS/app.js path (Node TLS). After 1.0.78, the same check appears in the native runtime (rustls_platform_verifier::verification::apple) and fails.

Steps to reproduce

1. Configure an org/enterprise Copilot MCP registry URL pointing at an internal HTTPS registry (private PKI), with Restrict MCP access to registry servers = Registry only.
2. Add one or more registry-listed MCP servers to ~/.copilot/mcp-config.json (or via /mcp add).
3. Start Copilot CLI with --log-level debug (or run /mcp reload).
4. Observe custom MCP servers blocked by policy.

Expected behavior

• Registry HTTPS fetch should succeed for a certificate that the OS / Chrome / Node already trust for that host, or
• If Apple TLS policy rejects the leaf (e.g. validity period), the CLI should surface a clear TLS/certificate error (not a generic “blocked by policy”), and ideally provide a documented enterprise path (fail-open option, private-CA guidance, or less strict verification for admin-configured registry URLs).

Actual behavior

User-facing:

! 3 MCP servers were blocked by policy: '<server-a>', '<server-b>', '<server-c>'

Debug log (redacted host):

[DEBUG] Registry https://<REDACTED-INTERNAL-REGISTRY>/: servers will be verified against this registry
[DEBUG] starting new connection 'Some("<REDACTED-INTERNAL-REGISTRY>")'
[ERROR] failed to verify TLS certificate: invalid peer certificate: Other(OtherError("“*.<REDACTED-INTERNAL-DOMAIN>” certificate is not standards compliant: -67901"))
        log.target=rustls_platform_verifier::verification::apple
[DEBUG] Registry https://<REDACTED-INTERNAL-REGISTRY>/ unreachable when checking server "<server-id>" after 3 attempts:
        error sending request for url (https://<REDACTED-INTERNAL-REGISTRY>/v0.1/servers/<server-id>/versions/latest)
[ERROR] MCP server "<server-id>" filtered: Registry https://<REDACTED-INTERNAL-REGISTRY>/ was unreachable

Telemetry kinds observed: mcp_policy_check, mcp_allowlist_policy_check.

Same host from the same machine:

• curl → TLS OK, HTTP 200 on /v0/servers and /v0.1/servers
• Node fetch → OK
• Chrome certificate viewer → trusts leaf issued by internal CA

Certificate details (redacted)

• Subject CN / SAN: *.<REDACTED-INTERNAL-DOMAIN>
• Issuer: internal enterprise PKI (private CA)
• Validity window: ~1095 days (issued Jan 2026 → expires Jan 2029)
• Apple trusted-certificate guidance requires leaf validity ≤ 825 days for certs issued after 2019 — this is the likely trigger for -67901 / “not standards compliant”
• Fingerprint available privately if needed; hostnames intentionally redacted

Additional context / analysis

Local package comparison on disk:

CLI package	Allowlist / registry verify strings	TLS stack for that check
1.0.58 / 1.0.59 / 1.0.61	Present in app.js	Node
1.0.78	Present in runtime.node, removed from app.js	Rust + rustls_platform_verifier (Apple)

So this is not “registry down” and not (yet) an identity fingerprint mismatch (does not match the registered server identity). The allowlist never reaches a successful registry HTTP response.

Related but distinct issues: #2481 / #2498 (policy fetch 404), #3934 (identity mismatch), #4346 (403 in CI). This report is specifically TLS verification of the enterprise registry URL on macOS after the Rust migration.

Asks

1. Confirm whether enterprise MCP registry fetches are intentionally pinned to rustls-platform-verifier on macOS.
2. Improve error UX: distinguish TLS/cert rejection from policy deny / true unreachability.
3. Consider enterprise-friendly options: honor OS trust more like Chrome for admin-configured registry URLs, document Apple 825-day constraint for private PKI, or provide a supported workaround short of reissuing certs / switching policy to Allow all.
4. Optionally fail-open (or cache last-good registry allowlist) when the configured registry URL fails TLS, similar to other managed-settings fail-open work in 1.0.78 — today MCP custom servers are hard-blocked.

Happy to provide more info if needed!

比较 app.js 和 runtime.node 中的 registry 验证路径，然后通过 rustls_platform_verifier::verification::apple 追踪 macOS 故障。使用调试日志重现私有 CA 案例，并区分证书拒绝与策略拒绝；当故障得到准确呈现，且任何受支持的企业处理方式都已记录，或由 issue 选定的设计覆盖时，即视为完成。