Prepare for the big digital cert swap — or else

Those of us of a certain age remember the megaglitch known as Y2K. As you may recall, the date field in older software and systems was limited to a two-digit designation for the year, so when Jan. 1, 2000, rolled around, a ton of systems and programs would read “01-01-00” as “01-01-1900.”

When the scope of the problem became apparent, it set off a panic — and not only in IT. It was a big deal. Multiple disaster movies showed the world falling apart, complete with crashing airliners, crumbling skyscrapers, and busted dams.

Y2K came and went with a whimper. Though the damage was minimal, it could have been much worse. The entire industry pulled together to tackle a single problem, to the point where planning and remediation stomped out the biggest bugs. Y2K stands as one of the few “khumbaya” moments when we all came together instead of reacting like sheep after the damage was done (which describes most of what we do in the computer security world today).

If you lived through Y2K, your project management and mitigation skills will be needed again, albeit for a much smaller task. In the next year or two, many vendors will force customers who use digital certificates to move from SHA-1 to SHA-2. If you don’t apply the appropriate mitigations, this change is going to break some applications.

What you need to know about SHA-2

SHA (secure hashing algorithm) is the U.S. national standard for digital signatures, which are used throughout computer encryption, signing, and integrity validation. Most computers and digital certificates use SHA-1, first promoted as a standard by NIST and NSA in 1995. A second version of SHA, slightly changed and with longer key sizes, was released in 2001. There’s even a third version, SHA-3, now under formal review, but it will be many years before it becomes the new standard.

Over the last few years, moderate, theoretical, cryptographic weaknesses were found in SHA-1. The thinking goes that someone with a million dollars of computers might be able to “crack” a targeted SHA-1 hash or cause a “collision.” Some experts even believe the NSA and other nation-state crypto-experts might be breaking SHA-1 at will. All this has encouraged vendors to get together and strongly encourage digital certificate users to move from SHA-1 to SHA-2 in the next year or so.

Certificate-consuming OSes, applications, and devices will start rejecting SHA-1 certificates in 2016 or 2017. Vendors’ SHA-1 deprecation policy statements vary. Google has said it will start showing browser warnings for SHA-1-signed SSL certificates if their useful lives exceed Dec. 31, 2015; eventually, Google Chrome will reject SHA-1 signed certificates. Microsoft will start rejecting SHA-1-signed SSL and code signing certificates issued by CAs in the Microsoft Windows Root Certificate Program. You can find out more details about Microsoft PKI and software support here.

Damned if you do, damned if you don’t

Unfortunately, today, many components don’t understand SHA-2 signed certificates. Converting from SHA-1 to SHA-2 usually requires that you upgrade the SHA-1-consuming (or generating) OS, application, or device to SHA-2, while disabling or removing SHA-1 support. No websites I know of can offer SHA-1 certificates to SHA-1-consuming clients and at the same time offer SHA-2 certificates to SHA-2-consuming clients.

Upgrading a website to SHA-2 requires replacing the site’s existing SHA-1-signed SSL/TLS certificate with a SHA-2-signed certificate. Once you’ve made the move, every connected computer must understand SHA-2. Those that don’t likely will not be able to load the website.

Isn’t this great? It’s up to you and your company what you move to SHA-2 and what stays behind. Let critical application compatibility drive your migration decisions.

Your plan of attack

Start by bringing awareness to management and other team members about the issue. Then you (or someone else) needs to start leading an SHA-1 deprecation project. Here’s the step-by-step plan:

1. Educate team members about what SHA-2 is and why its use is mandated (this post is a good start).
2. Take inventory of all applications and devices consuming or using critical hash/digital certificates.
3. Determine which critical consuming applications or devices can use SHA-2, which cannot, and what the operational concerns may be (this often means contacting vendors and testing).
4. Determine which applications and components can or will be migrated to SHA-2.
5. Create a migration plan to convert SHA-1 components to SHA-2, including consuming clients and PKI components, plus a fallback plan in case of critical failure.
6. Perform proof-of-concept testing.
7. Involve management in risk acceptance and the go/no-go decision.
8. Implement your migration plan in a production environment.
9. Perform ongoing tests of your SHA-2 implementation and gather feedback.

There’s only option you need to avoid: Doing nothing. I haven’t seen many mission-critical applications reject SHA-1 certificates yet — in fact, I’ve noticed only one — they will grow in number as time marches on. Sometime in 2016 or 2017, the rising tide will flow over everyone.

Last year, I was involved in a single SHA-2 migration project. Now I have a dozen more planned in the next few months. Every PKI consultant I know is fully booked for the foreseeable future — and SHA-2 migration is at least partly responsible. Many companies are using this time to update their older PKIs and move to SHA-2 as part of the process.

The sky isn’t falling — neither will airliners, buildings, or dams, for that matter. But right now you have the opportunity to get ahead of the problem, rather than feeling backed into a panic situation. SHA-2 is not quite as big or pervasive as Y2K, but it’s similar, and the lessons learned in that era can be applied here.