Following a recommendation by the National Institute of Standards and Technology (NIST), Microsoft will block Windows from accepting SSL certificates encrypted with the Secure Hash Algorithm-1 (SHA-1) algorithm after 2016. Given the number of mission-critical SSL certificates that are allowed to expire from inattention, administrators have their work cut out for them. By knowing what will happen, why it’s happening, and what you need to do, you won’t be surprised by these important policy changes.

What’s Happening?

On November 12, 2013, Microsoft announced that it’s deprecating the use of the SHA-1 algorithm in SSL and code signing certificates. The Windows PKI blog post “SHA1 Deprecation Policy” states that Windows will stop accepting SHA-1 end-entity certificates by January 1, 2017, and will stop accepting SHA-1 code signing certificates without timestamps after January 1, 2016. This policy officially applies to Windows Vista and later, and Windows Server 2008 and later, but it will also affect Windows XP and Windows Server 2003.

SHA-1 is currently the most widely used digest algorithm. In total, more than 98 percent of all SSL certificates in use on the Web are still using the SHA-1 algorithm and more than 92 percent of the certificates issued in the past year were issued using SHA-1.

Website operators should be aware that Google Chrome has started warning end users when they connect to a secure website using SSL certificates encrypted with the SHA-1 algorithm. Beginning in November 2014 with Chrome 39, end users will see visual indicators in the HTTP Secure (HTTPS) address bar when the site to which they’re connecting doesn’t meet the SHA-2 requirement. Figure 1 shows those indicators.

Google is doing this to raise end users’ awareness and to help guide other members of the Internet community to replace their SHA-1 certificates with SHA-2 certificates.

Why Is Microsoft Deprecating SHA-1?

SHA-1 has been in use among Certificate Authorities (CAs) since the U.S. National Security Agency (NSA) and NIST first published the specification in 1995. In January 2011, NIST released Special Publication 800-131A, “Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths.” This publication noted that SHA-1 shouldn’t be trusted past January 2016 because of the increasing practicality that a well-funded attacker or government could find a SHA-1 hash collision, allowing them to impersonate any SSL website.

Realizing that it’s highly unlikely that CAs and the industry at large will adopt more powerful encryption algorithms on their own, Microsoft is leading the charge by making Windows reject certificates using SHA-1 after January 1, 2017. Doing this will lead website operators to upgrade to stronger SHA-2 certificates for the betterment of all Windows users and the broader public key infrastructure (PKI) community. The Windows PKI blog post “SHA1 Deprecation Policy” noted that, “The quicker we can make such a transition, the fewer SHA-1 certificates there will be when collisions attacks occur and the sooner we can disable SHA1 certificates.”

In the end, the issue isn’t if SHA-1 encryption will be cracked but rather when it will be cracked.

What Do I Need to Do?

January 1, 2017, might seem like a long way away, but now is the time to understand the problem and how to mitigate it.

As per Microsoft’s SHA-1 deprecation policy, Windows users don’t need to do anything in response to this new technical requirement. XP Service Pack 3 (SP3) and later versions support SHA-2 SSL certificates. Server 2003 SP2 and later versions add SHA-2 functionality to SSL certificates by applying hotfixes (KB968730 and KB938397).

Web administrators must request new certificates to replace SHA-1 SSL and code-signing certificates that expire after January 1, 2017. As of this writing, that would probably affect only public SHA-1 certificates that were purchased with a long expiration date (three years or more) or long-duration certificates issued by internal SHA-1 CAs. Most third-party CAs will rekey their certificates for free, so you simply need to contact the CA to request a rekeyed certificate that uses the SHA-2 algorithm.

When ordering new SSL certificates, you should confirm with the CA that they’re being issued with the SHA-2 algorithm. New certificates with expiration dates after January 1, 2017, can only use SHA-2. Code-signing certificates with expiration dates after December 31, 2015, must also use SHA-2.

Note that the algorithm used in SHA-2 certificates is actually encoded to use SHA-256, SHA-384, or SHA-512. All of these are SHA-2 algorithms; the SHA number (e.g., 256) specifies the number of bits in the hash. The larger the hash, the more secure the certificate but possibly with less compatibility.

It’s important that the certificate chain be encrypted with SHA-2 certificates. (A certificate chain consists of all the certificates needed to certify the end certificate.) This means that any intermediate certificates must also use SHA-2 after January 1, 2017. Typically, your CA will provide the intermediate and root CA certificates when they provide the SHA-2 certificate. Sometimes they provide a link for you to download the certificate chain. It’s important that you update this chain with SHA-2 certificates. Otherwise, Windows might not trust your new SHA-2 certificate.

Root certificates are a different story. These can actually be SHA-1 certificates because Windows implicitly trusts these certificates since the OS trusts the root certificate public key directly. A root certificate is self-signed and isn’t signed by another entity that has been given authority.

For the same reason, any self-signed certificate can use the SHA-1 algorithm. For example, Microsoft Exchange Server generates self-signed SHA-1 certificates during installation. These certificates are exempt from the new SHA-2 policy since they aren’t chained to a CA. I expect, however, that future releases of Exchange will use SHA-2 in self-signed certificates.

What About My Enterprise CAs?

If your organization has its own internal CA PKI, you’ll want to ensure that it’s generating SHA-2 certificates. How this is done depends on whether the CA is running Windows Server 2008 R2 or later and if your CA has subordinate CAs.

If you have a Server 2008 R2 or later single-root CA without subordinates, you should update the CA to use SHA-2. Doing so will ensure that subsequent certificates generated will use the SHA-2 algorithm. To check which hash algorithm is being used, you can right-click the CA and go to the General tab. If SHA-1 is listed, you can run the following certutil command to configure the CA to use the SHA-256 algorithm:

You must restart the CertSvc service to apply the change. Now when you view the CA properties, you’ll see that the hash algorithm is SHA-256. All future certificates issued by this CA will use SHA-256, but keep in mind that existing certificates will still be using SHA-1. You need to renew any SHA-1 certificates issued by this CA to upgrade them to SHA-2 certificates.

If your CA is older than Server 2008 R2, you can’t upgrade the CA to use SHA-2. You’ll need to rebuild it with a newer version.

If your organization’s internal CA is multi-tiered with one or more subordinate CAs, you’ll need to reconfigure them to use SHA-2. This is done using the same certutil command just given on each subordinate or issuing CA. Keep in mind that if you use subordinate CAs, you’re not required to update the root CA to SHA-2 since that certificate is at the top of the certificate chain, but it won’t cause any problems if you do. You still need to renew any SHA-1 certificates issued by the subordinate CAs to upgrade them to SHA-2 certificates.

Take Action Now

Administrators and website operators should identify all the SSL certificates used in their organizations and take action, as follows:

• SHA-1 SSL certificates expiring before January 1, 2017, will need to be replaced with a SHA-2 equivalent certificate.
• SHA-1 SSL certificates expiring after January 1, 2017, should be replaced with a SHA-2 certificate at the earliest convenience.
• Any SHA-2 certificate chained to an SHA-1 intermediate certificate should be replaced with another one chained to an SHA-2 intermediate certificate.

The following tools and websites are useful for testing and for further information about SHA-1 remediation:

• Microsoft Security Advisory 2880823. This website discusses the deprecation policy for the SHA-1 hashing algorithm for the Microsoft Root Certificate Program.
• Migrating a Certification Authority Key from a Cryptographic Service Provider (CSP) to a Key Storage Provider (KSP). The section “How to migrate a CA from a CSP to a KSP and optionally, from SHA-1 to SHA-2” in this TechNet web page provides detailed instructions for upgrading a CA to use SHA-2.
• “Gradually sunsetting SHA-1.” This Google Online Security Blog post explains how the transition to SHA-2 affects Chrome and details Google’s rollout schedule.
• SHA-256 Compatibility. This GlobalSign web page lists OS, browser, server, and signing support for SHA-256 certificates.
• DigiCert SHA-1 Sunset Tool. This free web application tests public websites for SHA-1 certificates that expire after January 1, 2016.
• DigiCert Certificate Inspector. This tool discovers and analyzes all certificates in an enterprise. It’s free, even if you don’t have a DigiCert account.
• Qualys SSL Labs’ SSL Server Test. This free online service analyzes the configuration of any SSL web server on the public Internet.