KB3172605 and internal Self-Signed SHA1 sites on Internet Explorer 11 RRS feed

  • Question

  • Since installing KB3172605 on our client machines, we can't access the Cisco CM User page for our phone services. The site uses a self-signed SHA-1 certificate.

    I found two workarounds.

    1. Add the following registry value to lower the bit length from 1024 to 512:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms\ClientMinKeyBitLength (value data 200)

    This is obviously undesirable, because it lowers the security potential for all accessed sites.

    2. Add the following registry value:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms\Enabled (value data and key type doesn't seem to matter)

    The above was referenced as a work around in Microsoft Security Bulletin MS15-055. A DWORD with the value of 0 should disable the Diffie-Hellman key exchange. A value of 1 should enable it.

    I've learned the value doesn't matter. What is going on here? Is this a bug? What are the adverse effects of this?


    Thursday, September 1, 2016 1:38 PM

All replies

  • Hi,


    Effective January 1, 2016, Windows (version 7 and higher) and Windows Server will no longer trust new code that is signed with a SHA-1 code signing certificate for Mark-of-the-Web related scenarios (e.g. files containing a digital signature) and that has been time-stamped with a value greater than January 1, 2016. This cut-off date applies to the code-signing certificate itself.


    This restriction will not apply to the time-stamp certificate used to time-stamp the code-signing certificate or the certificate’s signature hash (thumbprint) until January 1, 2017. After this time, Windows will treat any code with a SHA-1 time-stamp or SHA-1 signature hash (thumbprint) as if the code did not have a time-stamp signature.


    For more information, please refer to the link:


    Best Regards,


    Please remember to <b>mark the replies as an answers</b> if they help and <b> unmark</b> them if they provide no help.<br/> If you have feedback for TechNet Subscriber Support, contact <a href=""></a>.

    Saturday, September 3, 2016 9:28 AM
  • I read through the documentation on the change, but everything indicates the user should be able to continue on past the certificate trust alert - as with expired certificates. This isn't the case with the scenario I described. There is no way to continue beyond it.
    Tuesday, September 6, 2016 12:40 PM
  • Hi,

    We haven’t heard from you for a couple of days, have you solved the problem? We are looking forward to your good news.

    Best Regards,


    Please remember to <b>mark the replies as an answers</b> if they help and <b> unmark</b> them if they provide no help.<br/> If you have feedback for TechNet Subscriber Support, contact <a href=""></a>.

    Friday, September 9, 2016 6:08 AM
  • My question still isn't really answered. According to the documentation for phasing out SHA1, it just shows that the certificate will become untrusted. The user will still be able to continue on after the warning (as with expired certificates).

    This isn't happening after KB3172605. This hotfix prohibits access with no way beyond it.

    Why does the workaround (for a different issue) described in MS15-055 allow access? Why does the value of the Enabled key not make a difference (0 for disabled - 1 for enabled)?

    Friday, September 9, 2016 2:05 PM
  • I am seeing the same problem with our CallManager page. I used the enable reg key to get past it, but it would be really helpful if it at least told us WHAT wasn't working so we knew which rabbit hole to dig down. 

    IE, DH Key length? SHA-ness? Self-Signed-ness? Getting my server admin to play ball is hard enough without specific lists of THIS is wrong and we need a higher BLAH 

    Monday, September 19, 2016 4:12 PM
  • We have the same problem with several appliances that use self-signed certificates. Not all are SHA-1. The Microsoft notes for KB 3172605 are these generic statements:

    • Improved support in Microsoft Cryptographic Application Programming Interface (CryptoAPI) to help identify websites that use Secure Hash Algorithm 1 (SHA-1).
    • Addressed issue in Microsoft Secure Channel (SChannel) that sometime causes Transport Layer Security (TLS) 1.2 connections to fail depending on whether the root certificate is configured as part of the certificate chain for server authentication.

    We really need more information to determine how to resolve the issue that has arisen, short of not installing / uninstalling the update.

    • Edited by taimesca Tuesday, October 4, 2016 12:51 PM
    Tuesday, October 4, 2016 12:50 PM