Update: We have made some modifications to our policy to accommodate code signing certificates targeting Vista/Server 2008.
Today Microsoft has announced a new policy for Certificate Authorities (CAs) that deprecates the use of the SHA1 algorithm in SSL and code signing certificates, in favor of SHA2. The policy affects CAs who are members of the Windows Root Certificate Program who issue publicly trusted certificates. It will allow CAs to continue to issue SSL and code signing certificates until January 1 2016, and thereafter issue SHA2 certificates only.
SHA1 has been in use among CAs since the late 1990s, and today accounts for the overwhelming majority of SSL and code signing certificates in use today. US NIST Guidance has counseled that SHA1 should not be trusted past January 2014 for the higher level of assurance communications over the US Federal Bridge PKI. Common practice however has been to continue to issue SHA1-based certificates, and today SHA1 certificates account for over 98% of certificates issued worldwide. Recent advances in cryptographic attacks upon SHA1 lead us to the observation that industry cannot abide continued issuance of SHA1, but must instead transition to SHA2 certificates.
The deadlines in this SHA1 deprecation policy reflect Microsoft’s estimation of the seriousness of the threat from SHA1 attacks. Our primary goal is to protect the integrity of the Windows platform and Windows customers. We want to avoid a situation where customers are caught unprepared because of a sudden advance in hash collision attacks. Without any other motivator for CAs to transition their customers to SHA2, when SHA1 becomes exploitable a sizable number of customers may be dependent on an insecure hash algorithm.
SHA1 Deprecation Policy
The policy applies to Windows Vista and later, and Windows Server 2008 and later.
There will be separate timelines for discontinuing SHA1-based SSL and code signing end-entity certificates.
CAs must stop issuing new SHA1 SSL and Code Signing end-entity certificates by 1 January 2016. Update: For code signing certificates, CAs may continue issuing new SHA1 code signing certificates to ensure that developers targeting Windows Vista and Windows Server 2008 are properly supported.
For SSL certificates, Windows will stop accepting SHA1 end-entity certificates by 1 January 2017. This means any time valid SHA1 SSL certificates must be replaced with a SHA2 equivalent by 1 January 2017.
Code Signing Certificates
For code signing certificates, Windows will stop accepting SHA1 code signing certificates without time stamps after 1 January 2016. SHA1 code signing certificates that are time stamped before 1 January 2016 will be accepted until such time when Microsoft decides SHA1 is vulnerable to pre-image attack.
Update: For code signing certificates, Windows 7 and later versions will stop accepting code signed with SHA-1 certificates without timestamps that were made prior to January 1, 2016. This enforcement will be performed only in user mode using the framework that Windows has for blocking weak cryptographic algorithms. Code signed with SHA-1 certificates that are time stamped before 1 January, 2016 will be accepted until 14 January 2020 (when Server 2008 extended support ends), at latest. This date may be moved earlier if Microsoft decides SHA1 is vulnerable to pre-image attack.
Windows 7 now has additional support for SHA-2 that brings it to parity with Windows 8.
[We will Re-examine the impact of this Policy at mid-term]
With every algorithm or key length transition there have been unforeseen impacts on legacy systems. Windows users will not be affected by the transition to SHA2, however Microsoft, CAs and their affected customers must assess the impact on legacy systems and devices now and not later on the timeline. Microsoft will give new consideration to the SHA deprecation deadlines in July 2015. We will consider these among other conditions that may be prevalent at the time:
What this Policy Means for Windows Users
Windows users do not need to do anything in response to this new technical requirement – Windows XP Service Pack 3 supports SHA2 SSL certificates, and Windows Server 2003 Service Pack 2 or later add SHA2 functionality to SSL certificate by application of hotfixes (KB968730 and KB938397).
Website operators must request new certificates to replace SHA1 SSL and code signing certificates that expire after 1 January 2017. CAs will be integral to this transition as they begin to promote SHA2 certificates as replacements. CAs must also work with web site operators to replace already issued SHA1 code signing certificates before 1 January 2016. This deadline applies to code signing certificates intended for use on Windows only. CAs may continue to issue SHA1 certificates for non-Windows platforms.
Microsoft has examined the SHA1 issue, and consulted with affected CAs. We are committed to this SHA1 deprecation policy and its timeline. We believe that this provides the best assurance of security for Windows customers and the broader PKI-based ecosystem of users. The quicker we can make such a transition, the fewer SHA1 certificates there will be when collisions attacks occur and the sooner we can disable SHA1 certificates.
Note: Windows has not set any dates for blocking other types of certificates (e.g., S/MIME) but SSL and code signing; CAs, however, should expect SHA1 certificates issued after 1/1/2017 may stop working at any time.
When you said the SHA1 deprecation policy does not impact SHA1 root certificates, do you mean that CAs who are already in the root certificate program do not need to re-submit a SHA2 root certificate for replacement in the program?
Regarding Windows will stop accepting SHA1 end-entity certificates by 1 January 2017 for SSL certificates, there seem to be conflict of policy with CABForum saying that the maximum validity period of SSL certificates should be 39 months. The deadline implies that CAs must stop issuing SHA1 end-entity certificates with 3 years validity period now. I don't think many CAs is able to switch to issuing SHA2 end-entity certificates immediately. Is it possible to reconsider the deadline?
Another question came to my mind: What about revocation status?
Do certificates signing CRLs and OCSP responses have to be SHA-2 certificates?
Do the CRLs and OCSP responses themself have to be signed with SHA-2?
Yes, they have to be SHA2
We have some customer using certificate that is issued from un-trusted root CA.
My questions are,
1. The SHA1 certificates are used with the applications develop with CAPI or CNG. Does SHA1 deprecation policy also affect to the certificates used in those applications?
2. What will happen if the SHA1 certificate displayed in the Windows certificate viewer?
3. Does the SHA1 deprecation policy will also affect to the end entity certificate which is issued from root CA which is not the Windows trusted root CA? (The root certificate was mannualy import to Windows root certificate store, not distributed via Root update.)
When will Microsoft themselves remove MD5 Signatures from their E-Mail Encryption Certificates ? These are even worse then SHA-1...
And for SHA-1 signed roots, yes they will need to be re-signed with a SHA-2 Hash, as it makes no sense to issue a SHA-2 signed certificate from a SHA-1 signed CA. It is about time that someone starts a depreciation program. Even this year new Root CA's have been signed with SHA-1, to prevent issues with old OS versions like Windows XP or Server 2003.. It's financial benefits versus best security.
I have some question about SHA1 deprecation,
1. What if user still use SHA1 EE certificate in the applications that were develop using CAPI and CNG?
2. After the policy effected, how about the SHA1 certificate in Windows/IE certificate looks like?
3. Is this policy also affect to EE certificate which is not issued by Root Program member CA?
4. Does Windows Phone SSL also support SHA2?
In our organisation we have an internal PKI deployed using a third party CA Management software. We are not involved in the Windows Root Certificate Program. All our certificates (Root, Intermediate, end-entity) currently use SHA-1.
Are we going to be impacted by this?
The certifiates are being used in many different environments: Windows, zOS, Unix. Will we still be able to use our certificates in Windows enviroment after 1 january 2017? Thank you.
Answer to your first question: The SHA1 deprecation policy will apply to any applications that calls the CertGetCertificateChain API to build and validate a certificate chain. The policy do not apply to using SHA1 from the low level crypto primitive APIs, such as CryptHashData or BCryptHashData.
Answer to your second question: SHA1 certificates will be treated as if the signature is invalid (e.g. CERT_TRUST_IS_NOT_SIGNATURE_VALID). Please see the Remarks section of the CertGetCertificateChain API documentation for details.
Answer to your third question: No. This policy do not affect certificates that chain up to privately deployed root CAs. Administrators will have the option to enable the no SHA1 policy from Group Policy.
Answer to your fourth question: IE on Windows Phone 7 and higher supports SHA2.
Will the revocation information for codesigning certificates (CRL signature and the certificate signing the CRL, OCSP response signature and the certificate signing it) have to bei in SHA-2 by 2016, too?
You mentioned, that codesigning signatures done with a SHA-1 certificate are still OK by 2016, if they contain a Timestamp. Does this timestamp (and its signing certificate) have to be SHA-2?
1. If root certificates are also to be updated, then that will create huge issue for those who want to be installed on un-updated windows machines who do not have this roots installed.
2. I know have a support case opened with MS cause i followed your advice on signing driver by sha2 certificate and Windows refused to recognise it. Way to go.
Yes, revocation information will be affected.
Timestamps can use SHA1 up to 1/1/2016. SHA1 timestamps that are generated before 1/1/2016 will be allowed by Windows after 1/1/2016.
Root certificates do not have to be updated. To meet the policy, the root CA will have to switch to use SHA2 by 1/1/2016 when signing new certificates and CRLs. However, the hash algorithm used on the root certificate is excluded from this policy.
Microsoft is working on an update that will enable SHA2 code signing on Windows Vista and higher. The release date has not been finalized, but we will post that information as soon as we can.
Some of my Issuing CA certificates have the "Signature Algorithm" set to SHA1RSA. After some investigation I found that this most likely means SHA1 for Digest and RSA Algorithm for encryption. RSA doesn't appear to be mentioned in the NIST Special publication you linked. Should I assume that the SHA1RSA certificates will also need to be depricated, or only certificates that sepecifically say 'Sha1'
Hi I have a question on CA - I have 4 DC installed in my client environment with no CA server manage, 2 DC is in Datacenter 1 and other 2 DC is in Datacenter 2, now the problem is in my client has local computer certificate which will be expire in less than 30 days.
I have no idea whether it will renew automatically or i have to renew it manually.
the certificate is on local server like is the machine name is "aaa" then the certificate name is aaa.domain.com with intended purpose is server authentication and this will be expire soon
I appreciate if you reply ASAP
On another MS publication [ http://msdn.microsoft.com/en-us/library/cc433493(v=exchg.80).aspx ] you are depending upon something called "son-of-sha-1". Will this version of sha-1 be around for a while or will it be changed soon as well?