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.

 

Reference:

• https://www.networking4all.com/en/ssl+certificates/ssl+news/transitioning+from+sha1+to+sha2/
• http://blogs.technet.com/b/askds/archive/2015/04/01/migrating-your-certification-authority-hashing-algorithm-from-sha1-to-sha2.aspx
• https://technet.microsoft.com/en-us/library/cc751157.aspx
• http://www.entrust.com/sha-1-deprecation-on-to-sha-2/
• http://security.stackexchange.com/questions/73491/how-will-sha1-deprecation-affect-sha1-roots-in-os-browser-trust-stores
• https://support.globalsign.com/customer/portal/articles/1499561-sha-256-compatibility
• https://www.digicert.com/sha-2-ssl-certificates.htm

 

AND…?

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

 

Reference:

• http://blogs.technet.com/b/pki/archive/2013/11/12/sha1-deprecation-policy.aspx

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

Reference:

• https://support.microsoft.com/en-us/kb/968730
• https://support.microsoft.com/en-us/kb/938397

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.

 

Reference:

• https://blog.mozilla.org/security/2014/09/23/phasing-out-certificates-with-sha-1-based-signature-algorithms/
• http://googleonlinesecurity.blogspot.com/2014/09/gradually-sunsetting-sha-1.html
• http://blog.chromium.org/2014/09/gradually-sunsetting-sha-1.html

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.

 

Reference:

• https://technet.microsoft.com/en-us/library/dn771627.aspx

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.

Testing:

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!

YMMV