Think of your mission to determine what will or won't work as a kind of mini-Y2K project. Start by trying to inventory every unique device, OS and application that will need to understand SHA-2. Then put together a team of people to test whether SHA-2 works. You can tentatively rely on vendor attestations, but until you test using a SHA-2 certificate, you won’t know for sure.
Upgrading your applications and devices is usually not trivial and often takes longer than you think. Even now, I see a ton of devices and applications running older versions of OpenSSL, which should have been patched following Heartbleed, but were not. Remember, too, that upgrading requires formal user testing and acceptance.
If you have an internal PKI (public key infrastructure), you’ll need to prepare it for SHA-2 as well. Sometimes that means upgrading your CAs, getting new CA certs, or installing entirely new PKIs. I recommend the last for a lot of reasons, mostly because a new PKI gives you a chance to start again, free of past mistakes.
PKI migration models
Here are the following PKI component scenarios for implementing SHA-2 (for these examples, I am assuming a 2-tier PKI — offline root, online enterprise issuing CAs — each of which can be a new PKI component or migrated:
- Two PKI trees, one all SHA-1, one all SHA-2
The rest of the options assume a single PKI tree
- Entire PKI tree, from root to endpoints, are all SHA-1
- Entire PKI tree, from root to endpoints, are all SHA-2
- SHA-1 root, SHA-2 issuing CAs, SHA-2 endpoint certificates
- SHA-1 root, SHA-2 issuing CAs, SHA-1 endpoint certificates
- SHA-1 root, both SHA-1 and SHA-2 issuing CAs, with SHA-1 and SHA-2 endpoint certificates
- SHA-2 root, SHA-1 issuing CAs, SHA-1 endpoint certificates
- SHA-2 root, SHA-2 issuing CAs, SHA-1 endpoint certificates
- SHA-2 root, both SHA-1 and SHA-2 issuing CAs, with SHA-1 and SHA-2 endpoint certificates
It is also possible to have an issuing CA that switches back and forth between SHA-1 and SHA-2 as needed, but this will more than likely cause a confusion in PKI services (and is not particularly recommended). If possible, for the easiest migration, you can run parallel PKIs, one with SHA-1 and the other SHA-2, then move consuming devices and applications over as testing allows.
Note: The root CA’s own CA certificate does not have to be migrated to SHA-2 even if it is still SHA-1. All SHA-1 deprecation checking programs only care about everything after the root CA’s own certificate (at least for the foreseeable future). Still, if it was me, I’d probably move everything, including the root CA’s own CA certificate to SHA-2 just so I could say that my PKI was all SHA-2 and avoid any further needed SHA-1 changes down the road.
Sign up for CIO Asia eNewsletters.