2

As mentioned in this post, I have exactly the same error in network logs (returned code=AlgorithmMismatch) except I use 

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12

to avoid POODLE vulnerability, the regkey has been set to 1 (..\Protocols\SSL 2.0\Client) but I still get this error. My production SSL certificate has been added to Firefox and the secure webservice is reachable and works fine. I precise this error occurs on two environments (Windows Server 2012 and Windows 7) and with a test SSL certificate everything works fine. Any ideas?

Community
  • 1
  • 1
Edd M
  • 31
  • 4

1 Answers1

1
   ..\Protocols\SSL 2.0\Client

That's the wrong key to enable TLS1.2 (SSL *4** was renamed to TLS1.0 while in development, SSL2 is much older, fundamentally broken, and should never be used).

The right keys are given in the MS KB page: https://support.microsoft.com/en-gb/kb/245030

But you'll need to set values in keys including:

…\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server

(And there are plenty of simplified guides to setting things up.)

Even if both client and server can agree on a TLS1.2 protocol suite there are still issues that will lead to failure to create the secure channel (eg. client does not trust the server's certificate). That will need more details (start with the exception type and message, and also for an inner exceptions recursively).

Richard
  • 106,783
  • 21
  • 203
  • 265
  • "...SSL *4** was renamed to TLS1.0" - no, TLS 1.0 is SSL 3.1, TLS 1.1 is SSL 3.2... – Steffen Ullrich May 19 '15 at 15:39
  • @SteffenUllrich OK, my recollection is incorrect, but the key point is "SSL 2.0" is nothing to do with TLS and the renaming happened before any of the RFCs were published. – Richard May 19 '15 at 16:38
  • I create the regkey (..\TLS 1.2\Client) you've mentionned, set the value to 0 and reboot the system but it still doesn't work. As I precised previously, with the test SSL certificate it works with TLS 1.2. Moreover, with the production certificate, it works with ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls but not with ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls1 | SecurityProtocolType.Tls2. – Edd M May 20 '15 at 14:59
  • It seems it's due to a problem between the production certificate and use of TLS1.1 and TLS1.2 inside schanell.dll, something prevents to create the channel/socket. Any ideas ? Any others ways to debug ? In the eventviewer, i get the following administration event error log (with the deeper error level which is 7) : Following fatal error has been generating : 70. The internal state error is 105. – Edd M May 20 '15 at 15:01
  • @EddM Temporarily allow your client to use TLS 1.1? If that works then you know there is a problem with the server using TLS 1.2. Otherwise you may need to understand enough of the low level details to use a picket sniffer and debug at that level. – Richard May 20 '15 at 19:20
  • I finally found and used an online ssl url analyser (https://www.ssllabs.com/ssltest/) and it revealed that TLS 1.2 was not activated on the production server ! – Edd M Jun 04 '15 at 13:56