Going from SHA-1 to SHA-2 in 8 steps

As deadlines go, Jan. 1, 2017, isn’t far away, yet many organizations still haven’t switched their digital certificates and signing infrastructure to use SHA-2, the set of cryptographic hash functions succeeding the weaker SHA-1 algorithm. SHA-1 deprecation must happen; otherwise, organizations will find their sites blocked by browsers and their devices unable to access HTTPS sites or run applications.

All digital certificates — to guarantee the website accepting payment card information is secure, software is authentic, and the message was sent by a person and not an impersonator — are signed by a hashing algorithm. The most common is currently SHA-1, despite significant cryptographic weaknesses that render the certificates vulnerable to collision attacks.

The current recommendation is to use the SHA-2 algorithm for all new certificates; existing SHA-1 certificates, meanwhile, will be replaced by newer versions signed with SHA-2. This isn’t as simple as it sounds, as the migration isn’t a two-step process where you flip off SHA-1 and flip on SHA-2. Instead, it requires intensive testing and analysis to ensure all devices, sites, and software are using SHA-2 correctly.

Time is running out. While Google, Mozilla, and Microsoft are sticking with Jan. 1, 2017, as the official cutoff date, Chrome and Firefox browsers already throw errors with websites using SHA-1 certificates. Microsoft Edge and Internet Explorer will follow suit this summer. Google and Mozilla will not likely follow through with previous hints to move up the deadlines to July 1, but nothing is keeping them from arbitrarily stopping support before the end of the year.

This is currently a race to complete the migration, which requires careful planning and execution to succeed. Here’s a checklist to help you keep on track.

1. Assemble the team

The biggest challenge facing the migration is logistical, not technical. Assemble a team that understands why SHA-2 is necessary and set them to work on the testing process. The team should involve IT directors, application managers, developers, and owners of public-facing websites, as well as network administrators and security professionals, not to mention those in charge of the organization’s SaaS apps, managed services, and online services.

Make sure the organization’s executive team understands that migrating can’t be treated as an optional task or one that can be deferred. Because a lot of dependencies and testing is involved, it’s better to spend the next six months on the migration instead of trying to cram it in alongside other big projects at the end of the year. Don’t forget to reach out — help desk and customer service staff should be aware of the road map so that they know what kind of calls to expect.

2. Know the schedule

The good news: About 7.6 percent of SSL-encrypted sites still use SHA-1, and that number is dropping steadily, according to SSL Pulse. Thus, most websites already use SHA-2 certificates. However, that simply means the vast majority of encrypted public websites will be safe from SHA-1 collision attacks. SSL Pulse doesn’t look at private certificates or internal applications, which still need to be migrated.

The timeline is a little hazy, but here are the key dates:

• Early 2016, Google started displaying a certificate error in Chrome browsers for SHA-1 certificates issued on or after Jan. 1, 2016, and chained to a public certificate authority. Other applications and devices to follow.
• Sometime in the summer of 2016, when Windows 10 Anniversary Update is released, Internet Explorer and Edge browsers will no longer treat SHA-1 signed TLS certificates as trusted. The sites will still be accessible, but the address bar lock icon will no longer be displayed.
• Starting Jan. 1, 2017, Microsoft will block code-signing certificates without Mark of the Web and time-stamped before Jan. 1, 2016. Google will completely stop supporting SHA-1 certificates in Chrome.
• Starting Feb. 14, 2017, Microsoft will block code-signing certificates without Mark of the Web and time-stamped after Jan. 1, 2016. Internet Explorer and Edge browsers will block SHA-1 signed TLS certificates completely. 

3. Know what you have 

Scan or inventory current certificates circulating within the organization and determine which ones use SHA-1. A number of online scanners can identify website certificates, such as the GlobalSign SSL Server Test and the DigiCert Sha-1 Sunset Tool. If the signature located under the Authentication section is listed as SHA-1, it needs to be replaced as soon as possible. The only exception is if the expiration date is before the end of the year; in that case, obtain a new SHA-2 certificate.

The OpenSSL client also supports the following command line on Linux systems:

openssl s_client -connect www.yoursite.com:443 /dev/null

    | openssl x509 -text -in /dev/stdin | grep "Signature Algorithm"

The Windows equivalent would be:

openssl.exe s_client -connect yoursitename.com:443 > CertInfo.txt && openssl x509 -text -in CertInfo.txt | find "Signature Algorithm" && del CertInfo.txt /F 

Microsoft also has its Certutil tool, which lets administrators log SHA-1 certificates in use.

Certutil -setreg chainWeakSignatureLogDir %LogDir% Certutil -setreg chainWeakSha1ThirdPartyFlags 0x80900008

A SHA-1 certificate would return Signature Algorithm: sha1WithRSAEncryption, and SHA-2 would return Signature Algorithm: sha256WithRSAEncryption.

While most organizations typically focus on certificates for public-facing sites and applications, those with an internal public-key infrastructure will also need to upgrade internal-facing applications. This is a good time to track down certificates used to access third-party services such as Amazon Web Services and Rackspace, as well. Check the signature and the expiration date for all certificates to formulate a comprehensive inventory. Though time-consuming, it’s an essential step in the migration plan.

4. Decide which certificates to replace first

All SHA-1 certificates should be migrated to SHA-2, but in reality, it can’t happen at once. Some certificates will need to be handled before others. This is where expiration dates come in.

Most public certificate authorities have already stopped issuing SHA-1-based certificates with expiration dates after Jan. 1, 2017. But if your company’s compiled inventory reveals existing SHA-1 certificates with a 2017 expiration data or later, they become the first priority. Public certificates that do not expire in 2016 should take the highest priority, followed by third-party and internal certificates.

Not everyone operates on the same schedule or the same security model, which further complicates the process. Some vendors are focused on Transport Layer Security certificates, others care about about TLS and code-signing, and yet others eyeball any type of digital certificate. For example, the Jan. 1, 2017, deadline for Microsoft applies only to code-signing certificates, and the company will give organizations another month to get their TLS certificates in order before blocking them.

Certificates for external sites should be replaced before those covering internal applications. Without a certificate, users won’t be able to access the site. The fact is, it’s possible to run two CAs in parallel if the certificates are used both internally and externally. Organizations can run a SHA-1 CA for internal applications alongside the SHA-2 infrastructure for external sites. The two-track effort can give organizations some leeway if they can’t finish before the deadline, so long as they use SHA-1 on internal sites only.

5. Figure out a centralized management system

Cataloging all the certificates and prioritizing the replacement process can be time-consuming. Most enterprises tend to have a lot of certificates, many of them hidden in unexpected applications, so several administrators have to coordinate with each other.

By implementing a centralized certificate management system, you can simplify future decisions. With a centralized system, it’s possible to know when certificates need to be renewed, and you can monitor different certificate types. Armed with such information, you can more easily find problematic certificates and revoke them if necessary.

6. Upgrade and test applications and devices

Before you do anything with your certificates, make sure every device, operating system, and application in use within the organization can handle SHA-2. For web applications, the process is straightforward, as Windows Server 2008, Vista (and later versions of Windows), Internet Explorer, Microsoft Edge, Mac OS X, Firefox, Chrome, Opera, Java, and Adobe Acrobat/Reader all support SHA-2. This is a good argument for placing web applications and public-facing websites as the top priority in SHA-2 migration — the pieces are already in place.

However, devices and applications running older versions of OpenSSL don’t support SHA-2. Though you should’ve updated after Heartbleed, any device or application not on the latest version needs your attention first. Use a demo site or a known site with SHA-2 certification to run your tests. Don’t rely on vendor claims on what is and isn’t supported.

Windows Server 2003 and Windows XP are capable of supporting SHA-2 with the latest service packs and patches applied. Windows XP SP3 gives XP the ability to consume SHA-2 certificates, but Windows Server 2003 SP2 will need an additional patch (KB968730). Both Windows Server 2003 SP2 and Windows XP SP3 need KB968730 to request SHA-2 signed certificates from Windows Server 2008 ADCS and later versions. Windows 7 and Windows Server 2008 R2 need a patch to support SHA-2 code signing and code-signing verification. Bake in the time to update those machines.

Another application to check is Outlook. Outlook 2003, 2007, and 2010 running on Windows XP Service Pack 3 can sign and validate certificates when the certificate itself is SHA-2 signed. Outlook 2003, 2007, and 2010 running on Windows XP Service Pack 3 cannot validate email messages when the message itself is SHA-2 signed. Windows Vista with Outlook 2003 (or newer) can validate SHA-2 messages, but Windows Vista or 7 with Outlook 2007 or 2010 (or newer) is needed to both sign and validate SHA-2 messages.

Windows versions earlier than Windows Server 2003 and Windows XP do not natively support SHA-2. Android 2.2 and earlier do not support SHA-2 certificates either. If any users fall in these bucket, as is the case in many developing nations, they will see error messages after the migration. If a user with a non-SHA-2-compliant device or application tries to access the SHA-2 server, that user will likely see messages such as, “Certificate not recognized,” “Connection not sure,” “Connection can’t be established,” “Bad certificate,” or “Untrusted certificate.”

Not all platforms can handle both SHA-1 usage with SHA-2 on a single server. Apache has an option with dual certificate deployment, but that’s a different set of management. An alternative is to split up applications and certificates; those that can be migrated can run on a SHA-2 server, and legacy applications that require SHA-1 can be kept on a different server.

For non-web applications, make sure every element in the process flow is compatible with SHA-2. Earlier this year, Mozilla began rejecting SHA-1 certificates outright, only to find that some security scanners and antivirus applications still use SHA-1. Thus, they could not connect to the update servers over HTTPS. Check every process in the application to identify areas that need to be updated.

If the legacy application — say, a database or a firewall (to name two) — can’t support SHA-2, then the server switch will have to wait until the app has been updated.

7. Get the new certificate

Once the infrastructure is ready to handle the SHA-2 certificates, the next step is to get the certificates themselves. Symantec, DigiCert, GeoTrust, RapidSSL, and Comodo already offer SHA-2 certificates, as do GoDaddy and a number of hosting providers. Each certificate authority is slightly different, but in general, the process involves asking the CA to reissue the current certificate, signing it with the SHA-2 algorithm, uninstalling the original certificate, then installing the new certificate. Instead of reissuing, you can also buy a brand-new certificate or renew it with the stronger algorithm.

Generate new Certificate Signing Requests (CSR) for any certificates still using SHA-1 on the server where they are installed. Make sure to keep the matching private key for the new/reissued certificate in a safe place, such as the certificate management system.

With many CAs, the process is traightforward. For example, DigiCert encourages customers to use its SHA-1 sunset tool to kick off the step-by-step process for purchasing a new certificate and provides information on how to install it.

If the CA says it is necessary to specify SHA-2 in the CSR, the command line for OpenSSL handles the task:

openssl req -new -sha256 -key your-private.key -out your-domain.csr" )

Organizations that took the time to put in a certificate management system can work within that interface instead of contacting each CA individually.

8. Install and test the certificates

Once the CA has issued or renewed the certificates signed with the SHA-2 algorithm, install them onto the network along with any necessary intermediate certificates. The CA typically will have instructions on how to install the certificates. A Microsoft white paper goes into detail on how to set up the certificates in Active Directory Certificate Services.

For internal public key infrastructure, there is the option to upgrade the CA, get new CA certs, or start over and install a new one. For internal PKI, working from scratch means past mistakes won’t get migrated and the new setup can fit current needs, instead of trying to retrofit a previous infrastructure.

The last step is to test the application to make sure the certificates are installed and working properly. Like the initial testing step, the test process will take up more time and effort than the actual installation.

Don’t get caught looking

“The time to move is now with urgency ahead of the proposed January 1 deadline,” says Kevin Bocek, vice-president of security strategy and threat intelligence at Venafi. After the deadline, browsers and applications using SHA-1 will stop working. Application failure is a real operational risk.

Migrating from SHA-1 to SHA-2 isn’t a technical challenge, but a massive logistical effort with tons of components to track and manage. Start your SHA-2 and SSL migration projects now — that way, it won’t become a haphazard task to muddle through at the end of the year. Once you’ve migrated public-facing sites, shift attention to internal PKI — even if it takes a little more time, it won’t be severely impacted by the deadline.

It’s a whole lot easier to spend the next six months on this project than to try to shoehorn it into a few weeks. It begins here.