Blog de l'équipe support IIS/Azure France -- French IIS/Azure Support Team Blog

Blog for the French IIS/Azure/ Support Team dealing with various toppics related to IIS, web development and Azure (Web Sites, Web Roles)

TLS 1.2 handshake failure

TLS 1.2 handshake failure

  • Comments 5

Last month, I worked on an incident where a customer couldn't access a web site from Internet Explorer 9 using TLS 1.2. Accessing the same web site was working fine using TLS 1.0. I first thought the issue was similar to the one described in this blog:

However, after gathering a network trace, I couldn't see any RESET coming from the server so we were hitting another scenario than the one from above blog.

Activating SCHANNEL ETL tracing and SCHANNEL event logging (as shown here: was showing a cryptic SSL fatal alert event 36888 "The following fatal alert was generated: 40. The internal error state is 252":

Since the issue could easily be reproduces, I debugged it and found out that the TLS 1.2 handshake failure was caused by extra security checks made on signature algorithms used in the server certificate chain. Specifically, the following certificate chain was sent in the server's HELLO and the use of MD5 algorithm was causing the handshake failure:

TLS 1.2 allows the ability to specify the signature algorithms that an end point is willing to accept ( ). This is specified in the client/server hello extension.
Here's the client hello for our IE9/TLS 1.2 scenario:

Unfortunately, neither Netmon nor Wireshark provides parsing for the signature_algorithms field but you can do "manual parsing" using the RFC:

Type: signature_algorithms (0x000d)
Data (16 bytes)
04:01 sha256(4) rsa(1)
05:01 sha384(5) rsa(1)
02:01 sha1(2)   rsa(1)
04:03 sha256(4) ecdsa(3)
05:03 sha384(5) ecdsa(3)
02:03 sha1(2)    ecdsa(3)
02:02 sha1(2)   dsa(2)

As you can see md5 is not listed. This is due to the fact that schannel.dll restricts the use of md5 for security reasons:

[abstract of]


      MD5 [MD5] is a hashing function that converts an arbitrarily long
      data stream into a hash of fixed size (16 bytes).  Due to
      significant progress in cryptanalysis, at the time of publication
      of this document, MD5 no longer can be considered a 'secure'
      hashing function.

Currently, TLS 1.1 & 1.2 are not enabled by default in Internet Explorer but this may likely change in future versions.
So, be aware that MD5 is no longer considered secure and it's probably time to get rid of your certificates with MD5 signature to avoid problems in the future!


Leave a Comment
  • Please add 5 and 7 and type the answer here:
  • Post
  • Hello Emmanuel,

    i am experiencing the issue you are describing with IE 11 (TLS 1.2 enabled by default now). But my problem is slightly different since i have CLIENT certificates with an MD5 signature algorithm.

    My question: would this problem also apply when MD5 is used as a signature algorithm for client certificates?

    Thanks in advance.


  • Emmanuel - very helpful, thanks!

    Marius - yes! We this problem with SHA512RSA hashed client certificates. See also

  • Apparently, using the new Microsoft Message Analyzer does automatic parsing.

    See talks about this exact issue using the same Windows event log IDs.

  • Beautiful blog, I faced similar issue. It was helpful.

    Thank you :)

  • Hi Emmanuel,

    Thank you for the very helpful blog post; it helped me get to the bottom of an issue I was having negotiating with a server over TLS 1.2, which I've documented in more detail here:

    I'm curious if you have any information on the apparent Schannel changes as described in my post between older versions of Windows and Windows 10 that allow Windows 10 to successfully ignore the superfluous MD5-signed cert in the chain. Is there any way to get previous versions of Windows to behave the same?

Page 1 of 1 (5 items)