Please help! Customers cannot use our software because they are getting SSL network errors 12157 and 12029 on Windows 7, 8 and now 10?

Question

We have had numerous complaints from users who are running our software that they cannot use our software because they cannot login to our sever because they are getting network errors. The error codes (normally either 12157 or 12029) seem to be related to SSL. We first started hearing about this from Windows 7 users. Then we started getting reports from Windows 8 users. And now we have a Windows 10 user with the same problem.

We found that in some cases, the problem could be fixed by getting the user to check "Internet Options" in the Control panel, and to make sure that "Use TLS 1.2" was ticked. But now we're getting users who already have pretty well everything ticked (e.g. all of "SSL 3.0", "Use TLS 1.0", "Use TLS 1.1" and "Use TLS 1.2"), and they are still getting the same problem.

The problem first started with some Windows 7 users, and then it seemed like it spread to all Windows 7 users. Then some Windows 8 users started reporting the same problem. And now, for the first time, we have a Windows 10 user who has reported the same problem. This is a major concern for us. We actually dropped support for Windows 7 because of this problem, and we are now considering what to do about Windows 8. The vast majority of our users are Windows 10 and Windows 11 users, who, up till now, have not had this problem. But we're concerned that it seems to be spreading like a disease!

We are a Visual C++ MFC (Microsoft Foundation Classes) application. We use the MFC classes CInternetSession, CHttpConnection and CHttpFile etc, for networking access. We are pretty sure that we are using these APIs correctly to access the server using SSL, because in the vast majority of cases, everything has worked perfectly for a long time. It is only recently that problems started to occur in significant numbers - first on Windows 7, then 8 and now (in one case only) 10.

For interest, we also have a Windows 8 user who has reported a very similar problem with the secure channel, using the WinHttp com object - i.e. nothing to do with the MFC. We don't know the error code in that case, but we know that it was related to the secure channel (i.e. SSL again).

For interest, the Windows 10 user had been able to access our software with no problem. Then he had some kind of problem on his PC which required a reinstall of Windows 10, which was done "by a qualified service technician". Since then, he has not been able to access our software because of the networking problem. But he says that "TLS 1.2" is enabled. Also, he can log in to HTTPS sites using his web browser, with no problems.

Please help! Thank you.

Answer 1

Make sure that not only IE/Edge options allow TLS 1.2, but also at the OS level and .net if your application relies on it:
How to enable TLS 1.2 on clients

You might also want to use a GUI tool like IIS Crypto to compare the enabled Protocols and ciphers on the server and clients.

----------

If this or any other reply helped solve your question, please remember to upvote and/or "Accept Answer".
It helps others facing similar issues find the solution.

Answer 2

> Application side, no logs?

It's our software and our application log. As I say, the error code we get back (and log) is 12029 or 12157. In the "System" log in Event Viewer, the following error is reported twice:

Source = "Schannel"
Event ID = 36887
User = "SYSTEM"
Level = "Error"
Text = "A fatal alert was received from the remote endpoint. The TLS protocol defined fatal alert code is 70."

According to Stack Overflow, "It means communication with the server was attempted using a recognized but unsupported TLS version. If your server is set to accept only communications using TLS 1.2 or newer, for example, then anything that tries to communicate via TLS 1.1 or lower will throw this error." However, as I say, TLS 1.2 was enabled on the Windows 8 machine.

> Maybe there's no common secure method that can be negotiated between application host and clients, be it ciphers or protocols.

Yes but why not? Windows 8 had been working fine, and then largely stopped working. Windows 10 (apart from one user) works fine. So does Windows 11. What is the problem and how can I debug it?

Answer 3

Hi everyone - we have now worked out what the problem is, and I thought I'd pass it on in case anyone else has the same thing. It turns out that the problem was caused by our server's implementation of TLS1.2 which is crazily tightly locked down.

> you might also want to use a GUI tool like IIS Crypto to compare the enabled Protocols and ciphers on the server and clients.

It was the ciphers - thank you. TLS1.2 supports up to 37 cipher suites (something like that). But none of them are mandatory, and our server doesn't support most of them, and in particular, does not accept the ones offered by Windows 7 and Windows 8 in their implementations of TLS1.2. So it's a server issue, and we need to sort it out with them. In my view, the whole thing has been a total mess, very hard to track down and the tracking had to be done entirely by us using Wireshark(!) with no help from anyone else (RafaelDaRocha pointed us in the correct direction with his steer about ciphers, but we hadn't read that at that point), and it reflects very badly on the design of TLS1.2, and also on our server admins. We are application developers! This isn't what we do!
We weren't even giving helpful error messages pointing us in the right direction. I hope TLS1.3 is better.

Answer 4

Also to assist anyone that may encounter this issue, we had similar problems after an in-place upgrade from Windows Server 2012 to 2019. The problem was some custom code that used the MSXML6 DLL. After the upgrade we started getting 12029 errors on with MSxml2.XMLHTTP.6.0 object's Send() method.

After applying Windows servicing stack and other updates, the error changed to 12157. Some experimentation using IISCrypto led us to determine that the following cipher (which was enabled under Win 2012) had to be re-enabled after the in-place upgrade disabled it.

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

The version of MSXML6.DLL after the upgrade/updates was 6.30.17763.2989