Jump to content

curl: (35) schannel: next InitializeSecurityContext failed: CRYPT_E_NO_REVOCATION_CHECK (0x80092012) - The revocation function was unable to check revocation for the certificate.


Go to solution Solved by harlan4096,

Recommended Posts

Posted

Dear Kaspersky Community,

Thank you for the marvel you do!

 

May I ask what is the reason that might cause Kaspersky affect most of the host TLS connections?

The dear cURL, as always, one of the most magnificent tools for networking... It's the only one that stated an actual error, and today, with more time available, I checked more about it in the context of the Windows OS, since this OS is not my main but Linux, since at least 2006.

That is, if Kaspersky is enabled, eventually, TLS connections result in certificate revocation checking issues. For example, the following cURL command:

$ curl -sL -- 'https://example.com/';
# curl: (35) schannel: next InitializeSecurityContext failed: CRYPT_E_NO_REVOCATION_CHECK (0x80092012) - The revocation function was unable to check revocation for the certificate.

 

Sure, I checked all the CLR endpoints in the certificate chain the Discord returns, and it all worked, on both the common CLR port 80 and not - 443.
I also tried requesting the same exact URL on both the phone Wi-Fi and cell-network, and a VirtualBox Guest, it all worked, yet it didn't in this Window host.

As above, non TLS or CLR version worked, too:

$ curl -sL --ssl-no-revoke -- 'https://example.com/' | head -c 100;
# <!doctype html><html lang="en"><head><title>Example Domain</title><meta name="viewport" content="wid

 

Once I found out Windows stores these lists and CA in its own cache, I tried searching for the purge command, and it was:

$ certutil -urlcache * delete

 

Yet still, it did not resolve the issue.
Only when I disabled Kaspersky, and cleared the CLR cache once again, it worked.
After that, both the cURL received a safe response, and various programs, including Office and VSCode instantly received updates notifications and, well, started to work normally.

 

What causes Kaspersky to degrade the TLS connections that way, considering that connection to CLR servers succeed regardless?
It seems like this case must be related to the Kaspersky's TLS MITM technique that reissues certificates locally.

 

Best and kind regards

harlan4096
Posted

Welcome to Kaspersky Community,

 

Please provide version of K. product and operating system.

Posted
1 hour ago, harlan4096 said:

Please provide version of K. product and operating system.

Thank you for the response!
The solution is a subscribed Kaspersky Total Security of version `21.3.10.391 (m)`.

The operating system is:

OS:     Windows 10 Pro (22H2) x86_64
Kernel: WIN32_NT 10.0.19045.6466
WM:     Desktop Window Manager 10.0.19041.4355

 

  • Like 1
  • 2 months later...
Posted
On 4/4/2026 at 6:40 PM, harlan4096 said:

Your 1st step should be to migrate Your KTS (almost obsolete product), to Kaspersky Plus...

Dear @harlan4096,
I am sorry for the dated response. I've updated to the latest version, and the issue disappeared.
Thank you very much for the response, your effort, and support!
May you have more success, stability, and peace.
Please stay safe!

  • Like 1

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now


×
×
  • Create New...