Copilot plugin marketplace refresh fails with a Schannel revocation error

まず、バンドルされた Git 子プロセスを起動する marketplace の更新パスを特定し、次に、文書化されているコマンドと環境変数を使って Windows Schannel の失敗を再現します。Copilot の子プロセス設定を通常のターミナルからの呼び出しと比較します。信頼された TLS インスペクション証明書で marketplace の更新が動作し、Git 設定の動作が文書化または修正されれば完了です。

The problem

Trying to pull for the first time or refresh a plugin marketplace fails in the GitHub Copilot desktop app with:

Refresh failed: Failed to fetch GitHub marketplace microsoft/aspire-skills: Command failed: git clone --depth 1 --progress https://github.com/microsoft/aspire-skills.git C:\Users\alexanderc\AppData\Local\copilot\marketplaces\microsoft-aspire-skills
Cloning into 'C:\Users\alexanderc\AppData\Local\copilot\marketplaces\microsoft-aspire-skills'...
fatal: unable to access 'https://github.com/microsoft/aspire-skills.git/': schannel: the revocation status is unknown

Running the same command in a terminal works without error:

git clone --depth 1 --progress https://github.com/microsoft/aspire-skills.git C:\Users\alexanderc\AppData\Local\copilot\marketplaces\microsoft-aspire-skills

The failure is therefore not caused by the repository, URL, credentials, or marketplace availability. The important difference is the Git configuration and environment used by Copilot when it launches its bundled Git.

Procmon captured Copilot starting Git with:

git.exe -c core.askPass= -c credential.interactive=never -c core.fsmonitor=false clone --depth 1 --progress https://github.com/microsoft/aspire-skills.git C:\Users\alexanderc\AppData\Local\copilot\marketplaces\microsoft-aspire-skills

The child process also has:

GIT_CONFIG_NOSYSTEM=1
GIT_CONFIG_GLOBAL=/dev/null

These variables prevent the child Git process from reading the normal system Git configuration and the user's global ~/.gitconfig.

This creates a confusing situation where the complete command copied from Copilot's error works in the user's terminal, while Copilot continues to fail because the command is executed with a different Git configuration environment.

TLS inspection

The affected network uses HTTPS/TLS inspection. Instead of allowing Git to receive GitHub's original certificate directly, the inspection device terminates the TLS connection and creates a new certificate for github.com or another GitHub hostname. That replacement certificate is signed by the organization's private inspection CA.

The inspection CA is trusted on the machine, so this is not a normal certificate trust failure. The certificate chain validates as trusted, and ordinary Git operations outside Copilot work successfully.

However, the proxy-issued leaf certificate does not contain the normal revocation-location extensions:

• No CRL Distribution Point URL
• No Authority Information Access/OCSP URL

When Git uses the Windows Schannel TLS backend, Schannel attempts to determine whether the certificate has been revoked. Because the replacement certificate publishes no CRL or OCSP endpoint, Schannel cannot obtain a revocation status and reports:

schannel: the revocation status is unknown

Git for Windows supports http.schannelCheckRevoke=best-effort, which is intended for situations where revocation checking cannot be completed. With the regular terminal Git invocation, explicitly using best-effort allows the clone to complete. Copilot's child process nevertheless continues to fail, despite attempts to provide the same setting through its environment.[1]

The issue can be forced from a regular terminal by enabling strict Schannel revocation checking:

git -c http.schannelCheckRevoke=true -c http.schannelUseSSLCAInfo=true clone --depth 1 --progress https://github.com/microsoft/aspire-skills.git "$env:TEMP\copilot-schannel-repro"

This produces the same schannel: the revocation status is unknown failure. The temporary directory is only used to avoid affecting the marketplace checkout.

Workaround attempts

I first tried to force Schannel's revocation behavior to best-effort through Git's environment configuration:

$env:GIT_CONFIG_COUNT = '1'
$env:GIT_CONFIG_KEY_0 = 'http.schannelCheckRevoke'
$env:GIT_CONFIG_VALUE_0 = 'best-effort'

This works when running Git directly from a terminal, but it does not fix marketplace refreshes when Git is launched by Copilot.

Changing only the TLS backend to OpenSSL does fix the problem. Before starting Copilot, setting these environment variables causes marketplace refresh to succeed:

$env:GIT_CONFIG_COUNT = '1'
$env:GIT_CONFIG_KEY_0 = 'http.sslBackend'
$env:GIT_CONFIG_VALUE_0 = 'openssl'
$env:GIT_SSL_CAINFO = 'C:\path\to\ca\file.pem'

GIT_SSL_CAINFO should point to the organization's trusted CA bundle. The OpenSSL workaround changes the TLS backend; it does not change the repository, URL, credentials, or marketplace operation.

To fix

1. Copilot should not completely replace the normal system and global Git configuration for marketplace operations. Having the exact same git command line work outside Copilot but fail inside Copilot is highly confusing and makes the error message misleading.
2. If Copilot needs to configure http.schannelCheckRevoke, it should use best-effort rather than true.
3. Copilot should avoid combining its configuration overrides with GIT_CONFIG_NOSYSTEM=1 and GIT_CONFIG_GLOBAL=/dev/null unless that behavior is required and documented.
4. The bundled Git/Schannel path should handle trusted TLS-inspection certificates without CRL/OCSP endpoints without making marketplace refresh fail.
5. Alternatively, Copilot could use OpenSSL for marketplace Git operations on Windows, or provide a supported way to select the TLS backend.

Environment details

• Windows
• GitHub Copilot desktop app
• Copilot-bundled Git for Windows 2.53.0.windows.4
• Corporate HTTPS/TLS inspection
• Corporate CA bundle configured for Git/cURL

References

1. https://github.com/libgit2/libgit2/issues/6724