vcpkg install fails behind proxy with schannel error 0x80092012

[sdn9002]

I am behind corporate Trend Micro proxy (TMWS) on Windows 11 24H2.
HTTP_PROXY, HTTPS_PROXY and NO_PROXY environment variables are configured correctly.
With the latest version of vcpkg, I get an error when running vcpkg install command.

C:\vcpkg>vcpkg install fmt
Computing installation plan...
A suitable version of cmake was not found (required v3.31.10).
Downloading https://github.com/Kitware/CMake/releases/download/v3.31.10/cmake-3.31.10-windows-x86_64.zip -> cmake-3.31.10-windows-x86_64.zip
error: curl operation failed with error code 35 (SSL connect error).
error: Not a transient network error, won't retry download from https://github.com/Kitware/CMake/releases/download/v3.31.10/cmake-3.31.10-windows-x86_64.zip
note: If you are using a proxy, please ensure your proxy settings are correct.

In the OS event log I have error from schannel - The certificate received from the remote server has not validated correctly. The error code is 0x80092012. The TLS connection request has failed. The attached data contains the server certificate.
The SSPI client process is vcpkg-2026-03-04 (PID: 27172).

Trend Micro proxy (TMWS) is generating "on-the-fly" certificates for GitHub that contain no revocation information at all.
Because there is no CRL (Certificate Revocation List) or OCSP URL inside the certificate, Windows schannel library fails.

vcpkg must ignore missing
---------------- Certificate CDP ----------------
No URLs "None" Time: 0 (null)

and not "hard fail". It should continue as the OpenSSL backend for curl does.
The version of vcpkg.exe from a few weeks ago does not have this problem, and install command works correctly.
The 5.21 MB version of vcpkg.exe works correctly, but the latest 6.27 MB version does not.

[BillyONeal]

We can't use the OpenSSL backend because it doesn't obey a system's certificate configuration. If schannel won't validate the certificate, then browsers on this system should be broken too. How is that working?

[sdn9002]

Most browsers use Chromium, which does not use Schannel.
Even if Schannel is used for certain functions, I assume the necessary flags have been set so that the absence of a Certificate Revocation List does not cause a hard failure.
My suggestion is to add CURLSSLOPT_REVOKE_BEST_EFFORT and/or CURLSSLOPT_NO_REVOKE to the set_common_curl_easy_options function in src/vcpkg/base/downloads.cpp

vcpkg_curl_easy_setopt(curl, CURLOPT_SSL_OPTIONS,
CURLSSLOPT_REVOKE_BEST_EFFORT | CURLSSLOPT_NO_REVOKE);

CURLSSLOPT_REVOKE_BEST_EFFORT
Tells libcurl to ignore certificate revocation checks in case of missing or offline distribution points for those SSL backends where such behavior is present.
This option is only supported for Schannel (the native Windows SSL library). If combined with CURLSSLOPT_NO_REVOKE, the latter takes precedence. (Added in 7.70.0)

CURLSSLOPT_NO_REVOKE
Tells libcurl to disable certificate revocation checks for those SSL backends where such behavior is present.
This option is only supported for Schannel (the native Windows SSL library), with an exception in the case of Windows' Untrusted Publishers block list which it seems cannot be bypassed.

[sdn9002]

Update: I tried adding CURLSSLOPT_REVOKE_BEST_EFFORT or CURLSSLOPT_NO_REVOKE to my own code, which uses curl + schannel. Both CURLSSLOPT_REVOKE_BEST_EFFORT and CURLSSLOPT_NO_REVOKE work without SSL errors with the proxy server.

[BillyONeal]

Most browsers use Chromium, which does not use Schannel.

To the best of my understanding, that is incorrect. Chromium browsers still query schannel for which certificates are trusted on the system. See https://chromium.googlesource.com/playground/chromium-org-site/+/refs/heads/main/Home/chromium-security/root-ca-policy/index.md which says they use the operating system's certificate stores + a denylist.

https://curl.se/docs/manpage.html#--ssl-revoke-best-effort seems to be associated with insecure in curl's documentation... that they do not use it by default means that previously we were not doing that (when we invoked the curl command line tool).

What does the C:\Windows\System32\curl.exe do on this system with that configuration?

[sdn9002]

I'm getting the same revocation error from the system's curl.exe, as well as an error in the event log.
The certificate received from the remote server has not validated correctly. The error code is 0x80092012. The TLS connection request has failed. The attached data contains the server certificate.
The SSPI client process is curl (PID: 28812).
All vcpkg users behind a corporate proxy that inspects TLS traffic will encounter this issue.
Without a solution to this problem, vcpkg is unusable, and it looks like we'll have to switch to another dependency management system, which I believe will also be necessary for other large companies like ours.
Our security department refuses to bypass the inspection of traffic to GitHub from vcpkg.

C:\Windows\System32>curl -v #1939

• Uses proxy env variable no_proxy == 'xxx'
• Uses proxy env variable https_proxy == 'xxx'
• Host xxx:80 was resolved.
• IPv6: (none)
• IPv4: 10.28.28.28
• Trying 10.28.28.28:80...
• CONNECT: no ALPN negotiated
• allocate connect buffer
• Establish HTTP proxy tunnel to github.com:443

CONNECT github.com:443 HTTP/1.1
Host: github.com:443
User-Agent: curl/8.18.0
Proxy-Connection: Keep-Alive

< HTTP/1.1 200 Connection Established (TMWS)
< Proxy-Agent: TMWS
< Date: Mon, 23 Mar 2026 10:07:54 GMT
< Proxy-Connection: keep-alive
<

• CONNECT phase completed
• CONNECT tunnel established, response 200
• schannel: disabled automatic use of client certificate
• ALPN: curl offers http/1.1
• schannel: next InitializeSecurityContext failed: CRYPT_E_NO_REVOCATION_CHECK (0x80092012) - The revocation function was unable to check revocation for the certificate.
• closing connection #0
  curl: (35) schannel: next InitializeSecurityContext failed: CRYPT_E_NO_REVOCATION_CHECK (0x80092012) - The revocation function was unable to check revocation for the certificate.

C:\Windows\System32>

[TVanderpoel]

I'm also getting this error, which makes vcpkg unusable in our company's environment. A fix would be appreciated.

[BillyONeal]

I'm also getting this error, which makes vcpkg unusable in our company's environment. A fix would be appreciated.

@TVanderpoel As I mentioned in the PR trying to do this, we already used curl a lot of the time, and curl is broken too in the original report. We could probably add some sort of opt in mechanism to lower security here but just effectively disabling revocation checking for everyone like in the submission we have so far we can't take as is.

[TVanderpoel]

just effectively disabling revocation checking for everyone like in the submission we have so far we can't take as is.

@BillyONeal - I agree with not wanting to reduce security across the board and making it opt-in.

[elcombs]

+1 on the number of people experiencing this issue. FWIW, I've gotten around the issue by copying an older vcpkg.exe from a few months ago to my current vcpkg root. However, this is not really sustainable. Also, if it matters, I am using manifest mode and building using a command similar to the following,

D:\Repos\myapp\vcpkg\vcpkg.exe install --x-wait-for-lock --triplet="x86-windows-myapp" `
    --vcpkg-root="D:\Repos\myapp\vcpkg" --x-manifest-root="D:\Repos\myapp" `
    --x-install-root="D:\Repos\myapp\build\vcpkg_installed"