Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Wednesday, April 16, 2014 3:47 PM
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.
All replies (8)
Sunday, April 20, 2014 8:56 AM ✅Answered
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/SHA1If 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
Wednesday, April 23, 2014 4:04 AM ✅Answered
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.
Thursday, November 13, 2014 1:50 AM ✅Answered | 1 vote
KB2973337 (http://support.microsoft.com/kb/2973337/en-us) finally solves this Problem!
Thank you Microsoft :)
Tuesday, April 22, 2014 2:43 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 12:54 PM
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 2:10 PM
Well that is interesting:
EMC RSA
"SHA-2 Algorithms: When SHA-512 Is More Secure and Faster"
Tuesday, April 22, 2014 2:47 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 4:26 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.