SHA-1 deprecation handling
All major web browser vendors (e.g. Microsoft, Google, Mozilla, Apple) and other relying parties have requested (and have been doing so for years) that all customers, services and products currently using SHA-1 move to SHA-2, although what has to be moved by when is different depending on the vendor. For example, most vendors only care about TLS (i.e., web server) certificates, and one, Microsoft Corporation, only currently cares if SHA-1 is used on a digital certificate from a “public” CA. But expect all vendors to require moving to SHA-2 for all applications and devices for all cryptographic hash functions, if they haven’t already. Today most browsers will display an error message if a public SHA-1 digital certificate is encountered on a web site, but some will let you bypass the error and go onto the SHA-1 protected web site if you wish. Coming soon, all major browser vendors will probably prevent their browsers from going to SHA-1 protected web sites, and prevent end-user bypasses.
Unfortunately, the move from SHA-1 to SHA-2 is a one-way operation in most server scenarios. For example, once you move your web server’s certificate from SHA-1 to SHA-2, clients that don’t understand SHA-2 certificates may see warnings or errors — or fail. SHA-2 migration will be a risky jump for unsupported applications and devices.
PKI SHA-1 to SHA-2 migration plan
Every company with an internal PKI not already using SHA-2 will need to create a SHA-2 PKI or migrate their existing SHA-1 PKI to SHA-2 (at some point in time). A SHA-2 migration plan includes:
1. Educating involved team members about what SHA-2 is and why it's use is being mandated (this document is a good start)
2. Inventory of all critical hash/digital certificate consuming or using applications and devices
3. Determination of which critical consuming applications or devices can use SHA-2 and what key sizes, which cannot, and what the operational concerns may be (this often includes contacting the vendor and testing)
4. Determination of which PKI components can or will be migrated to SHA-2
5. Create migration plan to convert SHA-1 components to SHA-2, including consuming clients and PKI components, plus fallback plan in case of critical failure
6. Proof of concept testing
7. Management risk acceptance and go/no-go decision
8. Implementation of migration plan in production environment
9. Testing and feedback
The hardest part of most SHA-2 migration projects is determining which devices and applications work with SHA-2. If the consuming devices don’t understand SHA-2, expect failure or an error message — which probably won't be as enlightening as “SHA-2 unrecognized.” Instead, brace yourself for: “Certificate not recognized,” “Connection not sure,” “Connection can’t be established,” “Bad certificate,” or “Untrusted certificate.”
Sign up for CIO Asia eNewsletters.