none
TLS 1.2 and SHA512

    Question

  • Hello

    Recently with all the news about Windows Server 2012 R2 and Windows 8.1 Update KB 2919355 and WSUS problems I discovered that TLS 1.2 in general does not work if just one certificate in the whole certificate chain is signed with SHA512.

    The problem is described here: http://www.michaelm.info/blog/?p=1273

    Our company internal Root-CA certificate could now be a big problem as it is RSA 4096 / SHA512

    Does Microsoft intend to support SHA512 with TLS 1.2 in near future?

    Editing registry and adding RSA/SHA512 ECDSA/SHA512 on all servers and client computers is not an option.

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010003]
    "Functions"
    RSA/SHA256
    RSA/SHA384
    RSA/SHA1
    ECDSA/SHA256
    ECDSA/SHA384
    ECDSA/SHA1
    DSA/SHA1

    If this is not going to be fixed we will need a new root certificate.

    Wednesday, April 16, 2014 3:47 PM

Answers

  • On Wed, 16 Apr 2014 15:47:20 +0000, st.he.ag wrote:

    Recently with all the news about Windows Server 2012 R2 and Windows 8.1 Update KB 2919355 and WSUS problems I discovered that TLS 1.2 in general does not work if just one certificate in the whole certificate chain is signed with SHA512.

    The problem is described here: http://www.michaelm.info/blog/?p=1273

    Our company internal Root-CA certificate could now be a big problem as it is RSA 4096 / SHA512

    Does Microsoft intend to support SHA512 with TLS 1.2 in near future?

    Editing registry and adding RSA/SHA512 ECDSA/SHA512 on all servers and client computers is not an option.

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010003]
    "Functions"
    RSA/SHA256
    RSA/SHA384
    RSA/SHA1
    ECDSA/SHA256
    ECDSA/SHA384
    ECDSA/SHA1
    DSA/SHA1

    If this is not going to be fixed we will need a new root certificate.

    This by design and the feeling was that SHA512 was overkill and would
    simply waste CPU cycles so it is not enabled by default. The only way this
    is going to change is if enough customers request it to be changed. The
    best way to request such a change is getting your TAM, if you have an
    Premier Support Agreement, to file a Design Change Request (DCR) bug.

    You have two choices here:

    1. Update the registry on all clients and servers. This can be done quite
    simply via Group Policy.
    2. Reissue all certificates in the chain such that they don't use SHA512.


    Paul Adare - FIM CM MVP
    "I can type faster than I can point. And my mother told me that pointing
    is impolite." -- Andrew S. Tanenbaum dislikes WYSIWYG

    • Proposed as answer by OlaJ Sunday, April 20, 2014 9:00 PM
    • Marked as answer by Amy Wang_Moderator Tuesday, April 29, 2014 4:58 AM
    Sunday, April 20, 2014 8:56 AM
  • On Tue, 22 Apr 2014 16:26:02 +0000, st.he.ag wrote:

    Still pragmatic I would prefer to enable SHA512. But it is not my decision. I have to convince others in good conscience that this is the way we should do it.

    Microsoft simply does not comment on, nor attempt to justify, design
    decisions in public forums.

    As I stated in a previous post, the only way this behaviour will possibly
    get changed is enough customers file DCR bugs requesting this change and
    even then, it isn't going to happen over night.

    So currently your only 2 choices are to update the registry or install a
    new PKI that doesn't use SHA512. Regardless of what others want/need to
    hear, that is the current bottom line.


    Paul Adare - FIM CM MVP
    You know you're a Unix guy when your dreams start with #!/bin/sh.

    • Marked as answer by st.he.ag Thursday, April 24, 2014 9:32 AM
    Wednesday, April 23, 2014 4:04 AM

All replies

  • On Wed, 16 Apr 2014 15:47:20 +0000, st.he.ag wrote:

    Recently with all the news about Windows Server 2012 R2 and Windows 8.1 Update KB 2919355 and WSUS problems I discovered that TLS 1.2 in general does not work if just one certificate in the whole certificate chain is signed with SHA512.

    The problem is described here: http://www.michaelm.info/blog/?p=1273

    Our company internal Root-CA certificate could now be a big problem as it is RSA 4096 / SHA512

    Does Microsoft intend to support SHA512 with TLS 1.2 in near future?

    Editing registry and adding RSA/SHA512 ECDSA/SHA512 on all servers and client computers is not an option.

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010003]
    "Functions"
    RSA/SHA256
    RSA/SHA384
    RSA/SHA1
    ECDSA/SHA256
    ECDSA/SHA384
    ECDSA/SHA1
    DSA/SHA1

    If this is not going to be fixed we will need a new root certificate.

    This by design and the feeling was that SHA512 was overkill and would
    simply waste CPU cycles so it is not enabled by default. The only way this
    is going to change is if enough customers request it to be changed. The
    best way to request such a change is getting your TAM, if you have an
    Premier Support Agreement, to file a Design Change Request (DCR) bug.

    You have two choices here:

    1. Update the registry on all clients and servers. This can be done quite
    simply via Group Policy.
    2. Reissue all certificates in the chain such that they don't use SHA512.


    Paul Adare - FIM CM MVP
    "I can type faster than I can point. And my mother told me that pointing
    is impolite." -- Andrew S. Tanenbaum dislikes WYSIWYG

    • Proposed as answer by OlaJ Sunday, April 20, 2014 9:00 PM
    • Marked as answer by Amy Wang_Moderator Tuesday, April 29, 2014 4:58 AM
    Sunday, April 20, 2014 8:56 AM
  • Hi,

    Do you need further assistances on this issue by now?

    If yes, please feel free to let us know.

    Have a nice day!

    Amy
    Tuesday, April 22, 2014 2:43 AM
    Moderator
  • Thank you for your answer.

    Maybe I am wrong but as far as I know if the Root-CA uses SHA512 as signature algorithm this would only require more CPU power at the time a certificate is signed.

    I would understand the argument of CPU requirement if SChannel is forced to use SHA512 in SSL/TLS communication. But as far as I know a SHA512 signed certificate in comparison to SHA256 does not imply a change in cipher suites.

    In addition a SHA512 certificate only breaks SChannel communication with TLS 1.2. SSL 3.0, TLS 1.0 and TLS 1.1 work without any problems.

    Well RFC 5246 is quite complicated. If I understand it right a RFC compliant TLS 1.2 implementation should not prevent communication if a certificate in chain is signed by SHA512.

    Well to convince some people to set those registry keys by GPO I need as much information and arguments as I can.

    Stefan

    Tuesday, April 22, 2014 12:54 PM
  • Tuesday, April 22, 2014 2:10 PM
  • On Tue, 22 Apr 2014 12:54:44 +0000, st.he.ag wrote:

    Well to convince some people to set those registry keys by GPO I need as much information and arguments as I can.

    The reason why Microsoft did this really isn't important. The fact of the
    matter is that without the registry being changed, you're going to have to
    redeploy your PKI.


    Paul Adare - FIM CM MVP
    "Quoted-Printable: a standard for mangling Internet messages
    Quoted-Unreadable: the result of applying said standard
    Unquoted-Unprintable: the comments from the recipients of the above" -- bf8

    Tuesday, April 22, 2014 2:47 PM
  • In my personal opinion I see this as pragmatic as you do.

    But what are you going to say to people that think: I am sure there is a good reason why Microsoft did this. If there is a good reason, well then let’s build a new PKI.

    I think in near future there will be more people having the same problem and asking the same question.

    Built a new PKI with the idea - let's be safe for the next years, use RSA4096 and SHA512 – some time later you start deploying Windows Server 2012 (R2)…

    Lync 2013 is an example:

    Microsoft TechNet: Lync 2013 Certificate Infrastructure Requirements SHA512 support is on the list.

    Real world examples with SHA512:

    SChannel Errors on Lync Server Preventing Client Logon
    Lync Front End Server not starting because of certificate issue

    Well and this one I just discovered:

    Lync 2013 client cannot connect to the lync pool!

    I received the following solution to the problem by a Senior Escalation Engineer at Microsoft:

    Disable TLS 1.2by following the below steps:
    - On the Lync 2013 server open the registry and browse to the following location: HKLM\System\CurrentControlSet\Control\SecurityProviders\SChannel\Protocols
    - Create the following Key under Protocol: TLS 1.2
    - Create the following two Keys under TLS 1.2: Client and Server
    - Create the following DWORDs under both the Client and Server Key: DisabledByDefault and Enabled
    - Under both Client and Server set the following: DisabledByDefault=1 and Enabled =0
    - Reboot the server.

    Now what should I do? Enable SHA512, disable TLS 1.2 or rebuild our PKI?

    Still pragmatic I would prefer to enable SHA512. But it is not my decision. I have to convince others in good conscience that this is the way we should do it.


    • Edited by st.he.ag Tuesday, April 22, 2014 4:27 PM
    Tuesday, April 22, 2014 4:26 PM
  • On Tue, 22 Apr 2014 16:26:02 +0000, st.he.ag wrote:

    Still pragmatic I would prefer to enable SHA512. But it is not my decision. I have to convince others in good conscience that this is the way we should do it.

    Microsoft simply does not comment on, nor attempt to justify, design
    decisions in public forums.

    As I stated in a previous post, the only way this behaviour will possibly
    get changed is enough customers file DCR bugs requesting this change and
    even then, it isn't going to happen over night.

    So currently your only 2 choices are to update the registry or install a
    new PKI that doesn't use SHA512. Regardless of what others want/need to
    hear, that is the current bottom line.


    Paul Adare - FIM CM MVP
    You know you're a Unix guy when your dreams start with #!/bin/sh.

    • Marked as answer by st.he.ag Thursday, April 24, 2014 9:32 AM
    Wednesday, April 23, 2014 4:04 AM