About Me

My photo
TsooRad is a blog for John Weber. John is a Skype for Business MVP (2015-2016) - before that, a Lync Server MVP (2010-2014). My day job is titled "Technical Lead, MS UC" - I work with an awesome group of people at CDW, LLC. I’ve been at this gig in one fashion or another since 1988 - starting with desktops (remember Z-248’s?) and now I am in Portland, Oregon. I focus on collaboration and infrastructure. This means Exchange of all flavors, Skype, LCS/OCS/Lync, Windows, business process, and learning new stuff. I have a variety of interests - some of which may rear their ugly head in this forum. I have a variety of certifications dating back to Novell CNE and working up through the Microsoft MCP stack to MCITP multiple times. FWIW, I am on my third career - ex-USMC, retired US Army. I have a fancy MBA. One of these days, I intend to start teaching. The opinions expressed on this blog are mine and mine alone.


Windows PKI SHA-1 to SHA-2

(How do you hear me now?)

Thanks go to fellow CDW co-workers Dean Sesko, Russell Despain, and Keith Crosby


What is the issue here?

Basically, the issue is that SHA-1 for PKI is going away in favor of SHA-2, and you WILL have customers that need help with this.





Any Microsoft supported operating system, properly patched/upgraded, and any Microsoft supported application, again properly patched/upgraded, will support SHA-2 PKI certificates.



…there are some caveats: notably around XP and Server 2003, and oddly, Server 2008.


So, there is not an issue with Microsoft supported products; the issue is with BYOD and Microsoft making a HUGE effort to support alternative browsers and operating systems. And those browsers and operating systems are fixing on deprecating their support of SHA-1.



However, there are going to be numerous AD internal CA’s out there that are issuing SHA-1 certificates, and depending on how the environment is configured, the customer will need to renew their application certificates for internal use. Logically, it makes sense that the desirable outcome of renewing the application certificates is that the issuing PKI be SHA-2.

CDW AD resident experts advise instantiating a new Root CA, and if needed, a new subordinate CA for issuing SHA-2 certificates. But, you know those pesky customers, they may not want to do this. Which would call for modifying the existing structure to hand out SHA-2 vice SHA-1.



Experimentation over the last several hours has revealed the following:

  • Migrating the existing SHA-1 CA went just fine.
  • The new SHA-2 Root Certificates updated almost immediately into the Trusted Root


  • I was able to request new SfB certificates and they were issued by the CA based on the new 3DES/SHA-2 root
    • However, the host server was not able to chain them up into the Trusted Root.
    • I rebooted.
    • I ran GPUpdate –force
    • I rebooted.
  • After waiting overnight, THEN the new certs chained up properly. Why this delay in chaining to the new Root I have no idea. I suggest that if you do this for real, that you do the work on one day and then plan on waiting for at least 8 hours before attempting to get new certificates and expecting them to chain up to the new root.



After updating the internal certificates on my SfBSE to a new SHA-2 I successfully tested

  • using Win8.1 and Win7sp1
    • IE 11
    • Chrome Version 43.0.2357.134
  • Surface Pro 2 (8.1) IE
  • iPad (iOS 8.0.2) Safari

Firefox 39 fails – due to it not liking the root cert – why is FF so blinking difficult? Why does it have to have its’ own key chain? The O/S has the root cert! It does this same shit when installed on *nix. After manually importing my new root cert, it worked just fine.



  • SIP Phones.  I had to restart services (stop-cswindowsservice start-cswindowsservice) AFTER I changed the certificate to the new SHA-2 certificate before my AudioCodes 420HD and Polycom VVX-600 would log in.  Why, I do not know.


The SfB/Lync Connection!

You may have been wondering why *I* am worried about this.  Well, on literally every project with which I have been involved over the last few years, they all had *nix and Mac workstations, along with loads of iPhones, iPads, *nix tablets, droids, surface tablets, and here and there the odd Windows phone.  And, you have to know that, in most cases, all of these were attached to an internal corporate wireless.  And in some cases, the internal wireless was dropping these devices into the production network, which put them in a position to being able to directly contact Lync/SfB resources on internal servers, that, for the most part, had a PKI certificate from an internal CA.  With SHA-1.  You knew it had to be simple, right?

Any input to solving/addressing the observed delay would be most welcome. I, for one, totally expected to have the new certificate chain immediately – the appropriate root cert was in place!



GW999 said...

Hi John,
Thanks for this. I've been looking into the whole SHA-1 deprecation thing recently to see if there will be any impact on Lync Server/SfB Server environments. It's clear that publically-signed certs signed using SHA-1 will be impacted on January 1st 2017 (Chrome/Firefox) and Feb 14th 2017 (IE/Edge). However, my understanding is that internal CAs will not be affected as they are not in the Microsoft Trusted Root Program (ref: "Will the policy impact certificates that chain up to an internal root that is not part of the Microsoft Trusted Root Program?" http://social.technet.microsoft.com/wiki/contents/articles/32288.windows-enforcement-of-authenticode-code-signing-and-timestamping.aspx#Y). Also: "In summary, as of now (May 2015), Microsoft's SHA-1 deprecation only impacts SSL and code-signing certs issued by CAs in the Windows Root Certification Program. Any CA not in that program will be treated as a private/enterprise CA and Microsoft's current (as of 5/15/2015) SHA-1 deprecation policies does not apply." http://social.technet.microsoft.com/wiki/contents/articles/31296.implementing-sha-2-in-active-directory-certificate-services.aspx.


tsoorad said...

@Gw999 - I agree. My point in all of this is the support of the non-msft clients. those browsers and operating systems are deprecating support for the SHA-1, and we need to respond to the requirements of supporting what is becoming a larger slice of the client-world.