schannel: CertGetCertificateChain trust error CERT_TRUST_REVOCATION_STATUS_UNKNOWN

[niracler]

I did this

First Error

$ curl -v https://hub.x-cmd.com
*   Trying 47.113.155.92:443...
* Connected to hub.x-cmd.com (47.113.155.92) port 443 (#0)
* schannel: disabled automatic use of client certificate
* schannel: next InitializeSecurityContext failed: Unknown error (0x80092013) - 由于吊销服务器已脱机，吊销功能无法检查吊销。
* Closing connection 0
* schannel: shutting down SSL/TLS connection with hub.x-cmd.com port 443
curl: (35) schannel: next InitializeSecurityContext failed: Unknown error (0x80092013) -

More information

1. In the same environment, curl https://github.com/ is correct.
2. I can access the website using Microsoft Edge. On the same windows system.

I tried to specify certificate, but it still didn't work.

$ curl -v --cacert curl-ca-bundle.crt https://hub.x-cmd.com
*   Trying 47.113.155.92:443...
* Connected to hub.x-cmd.com (47.113.155.92) port 443 (#0)
* schannel: disabled automatic use of client certificate
* schannel: added 141 certificate(s) from CA file 'curl-ca-bundle.crt'
* schannel: CertGetCertificateChain trust error CERT_TRUST_REVOCATION_STATUS_UNKNOWN
* Closing connection 0
* schannel: shutting down SSL/TLS connection with hub.x-cmd.com port 443
curl: (60) schannel: CertGetCertificateChain trust error CERT_TRUST_REVOCATION_STATUS_UNKNOWN
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

Using the OpenSSL version of curl with the same certificate works.

$ ./curl.exe -V
curl 8.4.0 (x86_64-w64-mingw32) libcurl/8.4.0 OpenSSL/3.1.3 (Schannel) zlib/1.3 brotli/1.1.0 zstd/1.5.5 WinIDN libssh2/1.11.0 nghttp2/1.57.0 ngtcp2/1.0.0 nghttp3/1.0.0
Release-Date: 2023-10-11
Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp ws wss
Features: alt-svc AsynchDNS brotli HSTS HTTP2 HTTP3 HTTPS-proxy IDN IPv6 Kerberos Largefile libz MultiSSL NTLM SPNEGO SSL SSPI threadsafe UnixSockets zstd

$ ./curl.exe -v --cacert curl-ca-bundle.crt https://hub.x-cmd.com
*   Trying 47.113.155.92:443...
* Connected to hub.x-cmd.com (47.113.155.92) port 443
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: curl-ca-bundle.crt
*  CApath: none
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
...

I expected the following

I want to know exactly which part of TLS has failed. Is there more log or any tools that can help me pinpoint this issue?

curl/libcurl version

curl 8.1.2 (x86_64-w64-mingw32) libcurl/8.1.2 Schannel zlib/1.2.13 brotli/1.0.9 zstd/1.5.5 libidn2/2.3.4 libpsl/0.21.2 (+libidn2/2.3.3) libssh2/1.11.0
Release-Date: 2023-05-30
Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS brotli HSTS HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM PSL SPNEGO SSL SSPI threadsafe UnixSockets zstd

operating system

MINGW64_NT-10.0-19045 DESKTOP-SOFJ13C 3.4.7-ea781829.x86_64 2023-07-05 12:05 UTC x86_64 Msys

I found this issue on a newly installed Windows 10 system, using Git for Windows.

PS. English is not my native language, so please forgive any mistakes in my question.

[jay]

* schannel: next InitializeSecurityContext failed: Unknown error (0x80092013)

0x80092013 is CRYPT_E_REVOCATION_OFFLINE. I will add it to the known error list, see #12241.

I want to know exactly which part of TLS has failed.

It's the revocation check that is failing. If the server is offline then usually that's a temporary issue. Try again.

Certificate revocation up to the root is the default for Schannel. The curl tool has --ssl-no-revoke and git has http.schannelCheckRevoke (which sets CURLSSLOPT_NO_REVOKE in libcurl).

Is there more log or any tools that can help me pinpoint this issue?

If the issue is not temporary then something on your network is blocking it. You could try wireshark. I am not able to reproduce.

[niracler]

If the issue is not temporary then something on your network is blocking it. You could try wireshark. I am not able to reproduce.

It seems this situation should be related to my local environment. I will try to use Wireshark to pinpoint the issue. Thank you for your help.

[yolichek]

Same problem. Deactivating of net defence solved it

[piotrp]

@jay The actual issue is different behavior of curl when used with OpenSSL vs Schannel - shouldn't both cases behave the same?

In another words: if OpenSSL ignores CRL checks by default, then shouldn't the same default behavior also apply to Schannel when used with curl?

CRYPT_E_REVOCATION_OFFLINE (0x80092013) error is easy to get in corporate environments, where you usually get access to servers you need, but CRL URL tends to be forgotten, because the only place it may appear is in server's certificate.

[jay]

The actual issue is different behavior of curl when used with OpenSSL vs Schannel - shouldn't both cases behave the same?

No it depends on the SSL library. https://curl.se/docs/ssl-compared.html

CRYPT_E_REVOCATION_OFFLINE (0x80092013) error is easy to get in corporate environments

It's "easy to get" if your corporate network is not configured properly.

There are options in curl to disable revocation checking:

--ssl-no-revoke (maps to CURLOPT_SSL_OPTIONS option CURLSSLOPT_NO_REVOKE)
--ssl-revoke-best-effort (maps to CURLOPT_SSL_OPTIONS option CURLSSLOPT_REVOKE_BEST_EFFORT)

[piotrp]

I don't know the full history behind this behavior, but from a user's point of view the fact that the same feature is enabled/disabled by default, depending on a technical detail, is a bug: why does curl available in Git for Windows fail, while the same version installed in WSL works correctly? Windows itself seems to (silently?) ignore invalid revocation checks.

I know that the setup I'm working with, namely missing access to CRL via VPN, is broken, but this works in many other cases (browsers, Java applications, on MacOS, on Linux etc.). And causes a lot of unnecessary work when it doesn't.

Thanks for detailed explanation on associated settings. Here's an error message from current curl version, pasted in hopes that this discussion will help somebody in the future:

curl: (35) schannel: next InitializeSecurityContext failed: CRYPT_E_REVOCATION_OFFLINE (0x80092013)

[jay]

Some behavior will always vary depending on the SSL library and version. In the case of Schannel it matched the behavior of our Windows systems at the time, however it is more strict in that we check all the way to the root and do not allow silent fail or the "best effort" bypass by default. IMO a revocation check must be completely successful or it has failed.