Tick-tock: Time is running out to move from SHA-1 to SHA-2

Are you ready for the coming SHA-1 deprecation deadline?

I suspect most companies aren’t. They don’t know about the issue — and the pending January 1, 2017 deadline. Others are probably aware that there is something called “SHA-1 deprecation” and have gotten some browser certificate errors, but don’t fully appreciate the need to be substantially migrated to SHA-2 by the end of the year.

To recap, the SHA-1 cryptographic signing algorithm has significant mathematical weaknesses. The powers that be have decided that the digital certificate world needs to migrate or replace some (or all) SHA-1 signed digital certificates with SHA-2 digital certificates by the start of 2017 at the latest. Certificates affected by SHA-1 deprecation policies but still signed by SHA-1 algorithms will be treated as untrusted once the deadline comes.

So what’s the impact?

When SHA-1 deprecation is enforced, it should apply to the presented endpoint certificate and all involved CA (certification authority) certificates in the same PKI chain, with the exception of the root CA’s own CA certificate. The root CA certificate can be SHA-1 or SHA-2 without impacting enforcement.

Although December 31, 2016 was agreed upon as the “final” date that SHA-1 will be accepted for affected certificates, many vendors don’t agree on what certificate types will be affected. Some have different intermediate dates (for different certificates types) and different treatments over time.

I wish all certificate types were slated to be deprecated on the same day. A single cutover date would be less confusing and less work. Right now, what we have is similar to an extended Y2K problem, where instead of everything going haywire on January 1, 2000, the Y2K crash dates fall all over the calendar.

When SHA-1 enforcement arrives, in some cases this means a browser will produce a warning or temporary operational block until the user acknowledges that warning and bypasses it. In other cases, it means the “lock icon” normally present on a HTTPS-protected website will not be presented (even if the original level of protection is still enabled). On some products and dates, it means the certificate will be completely untrusted and the user will be prevented from going to the desired site or service. On others, nothing will be affected until a much later date.

Microsoft’s deprecation policy applies only to certificates originating from CAs in its Microsoft Trusted Root Certificate Program, or what most people call “public CAs.” This means that Windows and Microsoft software will not apply SHA-1 depreciation enforcement to any certificate originating from a company’s private CA. Unfortunately, most other vendors and programs do not make the distinction between public and private certificates, which means most people have to worry about both types of certificates, unless they only have Microsoft software (pretty unlikely).

Currently, Microsoft SHA-1 depreciation enforcement applies only to code-signing certificates with Mark of the Web, which took effect on January 1 of this year. Treatment varies depending on whether or not the involved certificate was timestamped by January 1, 2016.

Microsoft moves its SHA-1 deprecation deadline

The major vendors have tended to update their SHA-1 deprecation policies, especially deadlines and certificate treatments, every few months. This month, Microsoft has moved its ultimate January 1, 2017 deadline to February 14, 2017. I know a ton of my customers will appreciate the additional month and half to get prepared.

Regarding code signing certificates without the Mark of the Web: Microsoft will block them on January 1, 2017 if they were time stamped before January 1, 2016 — and if time stamped after that date, on February 14, 2017. When Windows 7 through 10 users apply the forthcoming, summer-released, Windows 10 Anniversary Update, Internet Explorer and Edge browsers will no longer treat SHA-1 signed TLS certificates as trusted. The lock icon will not be displayed, but users will be able to continue onto the site. Once February 14, 2017 arrives, the certificates will be blocked completely.

Luckily, Microsoft’s SHA-1 enforcement can be disabled by a few registry edits. Unfortunately, this defangs Microsoft software only. Regardless, you really need to get rid of SHA-1 anyway, so don’t delay even if you can.

Moving Active Directory Certificate Services to SHA-2

One of the most popular installed server roles on Microsoft Windows server is ADCS (Active Directory Certificate Services), Microsoft’s PKI software. If you have one or more Microsoft CAs, the CAs below the root CA may need to be migrated from SHA-1 to SHA-2 due to non-Microsoft software SHA-1 deprecation treatment.

If the SHA-1 enabled ADCS servers are already running a KSP (key storage provider) instead of the legacy CSP (cryptographic storage provider), in most cases you can switch them to SHA-2 with a single registry edit. Just change HKLMSYSTEMCurrentControlSetServicesCertSvcConfigurationCSPCNGHashAlgorithm registry key value from SHA1 to SHA256 (or one of the other supported and desired SHA-2 key sizes) and restart Certificate Services. It’s really that easy to convert a KSP SHA1 CA to a SHA2 CA.

That single registry edit is enough to make the modified CA begin issuing new SHA-2 signed certificates and CRLs (certificate revocation lists), but if the issuing CAs currently have SHA-1 signed certificates, you will have to renew the CA certificates and get them signed by a SHA-2 signing parent CA and install them.

Moving CSP to KSP

If the involved ADCS CA is currently running a legacy CSP rather than a newer KSP, the conversion requires a lot more than a single registry edit.

You have to extract the CSP-protected CA key pair (including private key), re-wrap it with the intended KSP, and reimport. Then you have to uninstall and re-install ADCS, choosing the newly-wrapped key pair. Unfortunately, this wipes out all the related registry keys and previous CA database (which logs all the issued certificates and CRLs). This mean you must back up your previous registry keys and database before doing the uninstall. The previous database can be easily re-installed after the ADCS reinstall is complete, but the critical registry keys and other settings should be manually re-created. That’s a lot of precise steps.

Luckily, I have documented every mouse click and command prompt command in the most recent version of my SHA-2 migration paper. If you follow my guide step-by-step, you’ll have a great, working, migrated SHA-2 KSP CA.

The whitepaper includes all the detailed information behind why you need to do SHA-2 migration and includes project planning steps. You can use the related SHA-2 migration PPT slide deck for educational and project implementation purposes.

So do yourself a favor and upgrade your SHA-1 CAs to SHA-2 before the deadline hits. You’re probably already seeing warnings and issues. Upgrade before operational interruption strikes!