Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

schannel: CertGetCertificateChain trust error CERT_TRUST_REVOCATION_STATUS_UNKNOWN #12239

Closed
niracler opened this issue Nov 1, 2023 · 7 comments
Labels
TLS Windows Windows-specific

Comments

@niracler
Copy link

niracler commented Nov 1, 2023

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.

@bagder bagder added TLS Windows Windows-specific labels Nov 1, 2023
jay added a commit to jay/curl that referenced this issue Nov 1, 2023
- Add these revocation errors to sspi error list:
  CRYPT_E_NO_REVOCATION_DLL, CRYPT_E_NO_REVOCATION_CHECK,
  CRYPT_E_REVOCATION_OFFLINE and CRYPT_E_NOT_IN_REVOCATION_DATABASE.

Prior to this change those error codes were not matched to their macro
name and instead shown as "unknown error".

Before:

schannel: next InitializeSecurityContext failed:
Unknown error (0x80092013) - The revocation function was
unable to check revocation because the revocation server was offline.

After:

schannel: next InitializeSecurityContext failed:
CRYPT_E_REVOCATION_OFFLINE (0x80092013) - The revocation function was
unable to check revocation because the revocation server was offline.

Bug: curl#12239
Reported-by: Niracler Li

Closes #xxxx
@jay
Copy link
Member

jay commented Nov 1, 2023

* 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.

@jay jay closed this as not planned Won't fix, can't repro, duplicate, stale Nov 1, 2023
@niracler
Copy link
Author

niracler commented Nov 1, 2023

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.

jay added a commit that referenced this issue Nov 3, 2023
- Add these revocation errors to sspi error list:
  CRYPT_E_NO_REVOCATION_DLL, CRYPT_E_NO_REVOCATION_CHECK,
  CRYPT_E_REVOCATION_OFFLINE and CRYPT_E_NOT_IN_REVOCATION_DATABASE.

Prior to this change those error codes were not matched to their macro
name and instead shown as "unknown error".

Before:

schannel: next InitializeSecurityContext failed:
Unknown error (0x80092013) - The revocation function was
unable to check revocation because the revocation server was offline.

After:

schannel: next InitializeSecurityContext failed:
CRYPT_E_REVOCATION_OFFLINE (0x80092013) - The revocation function was
unable to check revocation because the revocation server was offline.

Bug: #12239
Reported-by: Niracler Li

Closes #12241
@yolichek
Copy link

Same problem. Deactivating of net defence solved it

@piotrp
Copy link

piotrp commented May 31, 2024

@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
Copy link
Member

jay commented May 31, 2024

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
Copy link

piotrp commented May 31, 2024

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
Copy link
Member

jay commented May 31, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
TLS Windows Windows-specific
Development

No branches or pull requests

5 participants