For many website owners and network security admins 2013 was the final push to move older websites and servers off of 1024-bit RSA SSL certificates to 2048-bit RSA certificates. This was an industry wide effort and one that was essential to safeguard the future of SSL/TLS. For us here at Symantec it was a year of education, communication, and mobilization. Although many people were comfortable with SSL certificate administration and the base functions of the technology, many did not understand the core aspects of SSL encryption. Our webinars, blogs and other publications on the subjects of algorithms and encryption levels became highly popular; and still are.
Now that 2013 has come to a close and the migration from 1024-bit SSL certificates are becoming a distant memory it is time to switch your mind to hash algorithms (e.g. SHA-1) as we embark on another migration to higher cryptographic standards before 2017. Once again this is an industry wide push to ensure that we are at the forefront of technology to meet a multitude of future demands.
What is a Hash Algorithm?
A hash algorithm reduces and maps the entire contents of the SSL certificate into a small, fixed-size value. The Certification Authority’s (CA) private key is used to encrypt the hashed value, and that is included in the certificate as the signature. The main purpose is to reduce data of any size to a small fixed-size fingerprint that effectively represents the initial file which is signed by a CA.
The Issue
On 12 November 2013, Microsoft published a security advisory on “Deprecation of SHA-1 Hashing Algorithm for Microsoft Root Certificate Program”. In summary, Microsoft is requesting that Certificate Authorities stop issuing new SHA-1 SSL and code signing certificates by 1 January 2016. With regards to SSL certificates, Windows (Internet Explorer) will no longer recognize or accept SHA-1 certificates from 1 January 2017. All SHA-1 SSL certificates issued before or after this announcement must be replaced with a SHA-256 (SHA-2) equivalent by 1 January 2017 to continue working with Microsoft platforms. In regards to code-signing certificates, your code must be time stamped before 1 January 2016.
At the time of writing, the Certification Authority/Browser Forum (CA/BF) has not endorsed Microsoft’s schedule to depreciate the SHA-1 hash algorithm. It is also worth noting that certificates chained to a private root, such as Symantec Private Certification Authority (CA) or any self-signed CA are not affected by these migrations and other regulations associated with certificates chained to public roots.
What You Need To Do/Know
Much like the recent migration from 1024 to 2048-bit RSA or ECC certificates there will be a little bit of pain but the methodologies will thankfully be the same, which should be some comfort to those of you licensing SSL certificates to multiple servers. To simplify things let me give you a check list of actions to take:
- Locate all of your SHA-1 certificates. Tools such as Symantec Certificate Intelligence Center can discover all of the certificates on your network regardless of who issues them.
- Create a migration plan.
- SHA-1 SSL certificates expiring before 1 January 2017 will need to be replaced with a SHA-2 equivalent certificate.
- SHA-1 SSL certificates expiring after 1 January 2017 should be replaced with a SHA-2 certificate at your earliest convenience.
- Any SHA-2 certificate chained to a SHA-1 intermediate certificate should be replaced with another one chained to a SHA-2 intermediate.
- Execute. Plan to do this sooner rather than later. Although many people tend to wait until the deadline, the last thing you need to handle on a New Year’s Eve is SSL certificate installation and testing. Since any unused validity will be credited back to you, there are few benefits in waiting.
- Test. Upon installation please check your configuration using our set of SSL tools. Although SSL installation may like simple muscle memory after a while, there may be hardware or software conflicts you may not have caught and a belt and suspenders approach makes sense here.
SHA-2 Ubiquity and Hardware/Software Conflicts
One thing that some owners of webservers learned in 2013 is that some older servers are not configured to handle advanced SSL encryption. In our recent webcast on the subject only 18% of attendees who responded to the poll said they were confident that all of their servers can handle the SHA-2 hash algorithm. If a server can’t handle SHA-2 what will you do?
If retiring them is not an option (and we know that this is often not an option you can consider), the main course of action is to move it to the backend (intranet usage) and encrypt it with a SHA-1 SSL certificate chained to a private root. Symantec can provide an organization with a custom private SSL hierarchy to overcome hardware/software conflicts in legacy devices. Talk to us today to help complete your cost/benefit analysis when considering this option. It is also worth noting that in the event you encounter a hardware/software conflict please access our SSL Support Pages or contact Symantec Technical Support (available 24/7/365 days a year) using the contact information provided to you (based on region) or located in your SSL control center.
At Symantec we are committed to supporting you through this next transition in encryption standards. In summary please plan, prepare, execute and test your move to SHA-2 before 1 January 2017 for SSL and 1 January 2016 for code-signing certificates. If you would like to learn more view our aforementioned webinar How to Navigate the Future Changes in SSL Encryption (select “View” at the bottom of the text for the recording).