Why all of the fuss?
SHA-1 was deprecated by NIST from 2011 through 2013 because of its security strength being susceptible to a collision attack. Due to ever increasing computational power, the risk of SHA-1 being broken via a collision attack in the next few years is very real. For that reason, most certificate authorities (CAs) only issue certificates using SHA-2 or above.
Google, Microsoft, and Mozilla have already started taking steps last year to aid end users in understanding the risks and have updated their policies. These policies state that sites with end-entity certificates expiring on or after 1 January 2017 that make use of SHA-1 will no longer be accepted as secure. These policies also require CAs to stop issuing new SHA-1 certificates after 1 January 2016.
What progress are we making with SHA-1 to SHA-2 migration?
It’s now well known that certificates signed with SHA-1 are not secure, but what progress are companies really making in transitioning to SHA-2? Using Venafi TrustNet certificate reputation services, I generated a report of all SHA-1 certificates that have been issued since 31 December 2013—this date is after NIST had deprecated SHA-1 usage—and filtered out any certificates that are set to expire before the 1 January 2017 deadline. The results speak for themselves as to the state of the industry!
There are over 1.5 million certificates that have been issued since 31 December 2013 with SHA-1 that are set to expire well beyond the 1 January 2017 deadline, when major browsers will stop trusting these certificates.
Although too small a percentage to show on the chart above, 330 certificates were found to be expiring in more than 100 years! I guess some security practitioners are looking out for future generations so that they don’t run into any outages related to certificate expirations, they obviously don’t believe SHA-1 will be fully exploitable by 2114—but this is at the cost of security.
What steps should you take to start your SHA-1 migration?
Certificate inventory assessment is the first step, establishing the scope and extent of your SHA-1 to SHA-2 migration. With a clear understanding of your certificate inventory and trust stores, you can determine which systems and applications may be impacted.
Revision of policies is needed to indicate that only SHA-2 certificates are generated moving forward and newly generated keys and certificates are in compliance with corporate and industry security standards.
Application and system testing is one of the very first things that needs to be performed before attempting to deploy any new certificates into the environment. You may have a legacy application that does not support SHA-2 and there is no migration plan from the vendor. If this is the case, you need to make a judgment call: migrate the application to a newer application that does support SHA-2 or live with the risk knowing full well that it’s a ticking time bomb.
Automated deployment of new certificates is recommended, especially when you consider that the average large enterprise has over 23,000 keys and certificates to manage. By automating the process you can validate the entire CA and certificate refresh process, including SHA-2 implementation.
Another recommendation is to deploy a new PKI hierarchy for SHA-2 and slowly migrate all systems and applications from the old one. In doing so, any system or application that does not support SHA-2 can be left using the old PKI hierarchy while all those that do support SHA-2 can use the new, more secure PKI environment.
Where are you in your SHA-1 to SHA-2 migration? Please share any roadblocks or successes you’re experiencing.