When is SHA used? SHA is primarily being used for the following purposes:
How do I know if I am using SHA-1 in my IT systems or infrastructure?
As described in the migration page, it is essential to gather and create a comprehensive list or an inventory of every unique devices, OS or application in your infrastructure.
$openssl s_client -connect www.yoursite.com:443 < /dev/null 2>/dev/null \ | openssl x509 -text -in /dev/stdin | grep "Signature Algorithm"
OR$openssl s_client -connect \<host\>:\<port\> < /dev/null 2>/dev/null | openssl x509 -text -in /dev/stdin | grep "Signature Algorithm"One real-world example where SHA-1 may be used is when you're entering your password into a website's login page. Though it happens in the background without your knowledge, it may be the method a website uses to securely verify that your password is authentic.
In this example, imagine you're trying to login to a website you often visit. Each time you request to log on, you're required to enter in your username and password.
If the website uses the SHA-1 cryptographic hash function, it means your password is turned into a checksum after you enter it in. That checksum is then compared with the checksum that's stored on the website. If the two match, you're granted access; if they don't, you're told the password is incorrect.
Another example where the SHA-1 hash function may be used is for file verification. Some websites will provide the SHA-1 checksum of the file on the download page so that when you download the file, you can check the checksum for yourself to ensure that the downloaded file is the same as the one you intended to downloaded.
Protocols Used In:
When and Where is SHA-1 Ok? Checking the hash of an executable or file that we know is trusted (from trusted site). No known flaws in SHA-1 as a key derivation function which is how dh-group14-sha1 is being used. Similarly, HMAC-SHA1 is believed to be (still) safe as long as SHA1 is pseudorandom. The specific construct of HMAC-SHA1 is still considered safe to use (assuming a secret key) due to the security proof for HMAC which does not rely on collision resistance of the underlying PRF.
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.
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.
Administrators and website operators should identify all the SSL certificates used in their organizations and take action, as follows: