Windows PKI blog

News and information for public key infrastructure (PKI) and Active Directory Certificate Services (AD CS) professionals

SHA1 Deprecation Policy

SHA1 Deprecation Policy

  • Comments 67
  • Likes

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.

SSL Certificates

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.

[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:

  • whether SHA1 is still considered resistant to pre-image attacks by the security community, and
  • whether a significant portion of the ecosystem is not capable of switching to SHA2. Third party legacy systems and embedded devices that cannot be upgraded to SHA2 may be particularly susceptible.  We will continue to gather data on this portion of the ecosystem.

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.

 

Comments
  • And note that the SHA256 hotfix for Server 2003 is included in MS13-095 also released today because they removed the GDR branch from all new XP/Server 2003 updates 6 months ago.

  • SSL Certificate section references 2017, this appears to be a typo and inconsistent with the rest of the depreciation policy.

  • Curious Observer,

    The text is correct. The policy is a bit confusing but necessary. We want to protect both scenarios as soon as possible but the SSL ecosystem will take longer to transition. That’s why we have the split schedule.

  • Now Office 2010 SP2 and 2013 support SHA2 certificates for VBA digital signatures, but what about 2007?

  • How will this affect Root CAs that are self signed with SHA1? Most roots are signed with this algorithm.

  • Hi!

    Do Windows XP and 2003 Server support SSL client certificates as well? Am I able to connect to an SHA2 cert web server with my SHA2 SSL client cert? ... With XP SP3 of course.  

    Thanks!

  • Does this mean that SHA1 support will eventually be dropped on client computers ? We use sha1 as hash algorithm for certificates deployed on radius servers and some web servers in our organisation. Does that mean that starting 2016 ( or 2017 ) clients will not be able to authentificate to radius servers or access https ressources that have sha1 certificates ?

    regards

  • A few thing in here are unclear to me, could you please elaborate on them:

    1. By "Windows will stop accepting SHA1 code signing certificates without time stamps " do you actually mean "Windows will stop accepting code signed by a SHA1 certificate where the signature does not include a timestamp"? I am asking, because I am not aware of a way to add a timestamp to a certificate.

    2. At one point you write "CAs must stop issuing new SHA1 [...] Code Signing end-entity certificates by 1 January 2016" and below "Windows will stop accepting SHA1 code signing certificates [...] after 1 January 2016". What is true here. Is every SHA1 certificate going to be rejected after that date or only newly issued ones?

    3. Does this really only affect end-entitiy certificates and not root- and intermediate-certificates?

    4. What about other certificate uses not mentioned here, like document signatures on a PDF or S/Mime singned e-mails. Will Windows still consider SHA1 certifcates valid for those usages afte January 2016/2017?

    regards

  • What does this mean for CA certificates - root (as mentioned by Ramo), intermediate and issuing?   Will they be able to continue with SHA1 certificates or will they need to be replaced with SHA2 certificates?

  • This is a good decision. Better to go to SHA-2 at least, because SHA-1 can be even reverse-engineered due to SHA-1 have no drops in algorithm of valued hash information in every cycle. That was funny because this algorithm was designed by US NSA, and has such a security hole. :)

  • @Ramo

    The SHA1 deprecation policy does not impact SHA1 root certificates, because Windows relies on other means to validate root certificates besides the signature.  But all root CAs are expected to switch to use SHA2 to sign any subordinate CA certificates, CRLs, etc.

  • @ Toki,

    I recommend some excellent Windows PKI blog posts for your questions about Windows and SHA2 support. Please see blogs.technet.com/.../sha2-and-windows.aspx and blogs.technet.com/.../common-questions-about-sha2-and-windows.aspx.

  • @ User,

    As I understand your questions, they apply to enterprise managed PKIs.  This policy does not apply to enterprise PKIs where the root CA is managed by the enterprise.  Enterprise admins can enable the strict SHA2 policy via group policy on their enterprise PKI.

    However, in the case where the CA is a subordinate under a CA distributed in the Microsoft Root Cert Program, the policy will apply.  If your questions is whether Radius sever supports SHA2, I don’t know the answer.  SHA2 certificates should be supported on Windows Server 2008 or later, but you might contact your Radius server vendor.

  • @ Matt

    A few thing in here are unclear to me, could you please elaborate on them:

    1. By "Windows will stop accepting SHA1 code signing certificates without time stamps " do you actually mean "Windows will stop accepting code signed by a SHA1 certificate where the signature does not include a timestamp"? I am asking, because I am not aware of a way to add a timestamp to a certificate.

    Answer: Yes, we mean what you say. Apologies for the imprecise language.

    2. At one point you write "CAs must stop issuing new SHA1 [...] Code Signing end-entity certificates by 1 January 2016" and below "Windows will stop accepting SHA1 code signing certificates [...] after 1 January 2016". What is true here. Is every SHA1 certificate going to be rejected after that date or only newly issued ones?

    Answer: You should read “For code signing certificates, Windows will stop accepting SHA1 code signing certificates without time stamps after 1 January 2016” as “For code signing certificates, Windows will stop accepting SHA1 code signing certificates without time stamps *by* 1 January 2016.  We make no warranties on the exact date that Microsoft will stop accepting SHA1 code signing certs, only that we expect it on or after 1 Jan 2016.  Sorry for the inconsistency.

    3. Does this really only affect end-entitiy certificates and not root- and intermediate-certificates?

    Answer: The policy affects intermediate and end-entity certificates - both intermediates and end-entity certs should transition to SHA2 before the deadlines.  Root certs aren’t validated by the SHA1 signature so they are unaffected by this policy at this time.

    4. What about other certificate uses not mentioned here, like document signatures on a PDF or S/Mime signed e-mails. Will Windows still consider SHA1 certifcates valid for those usages afte January 2016/2017?

    Answer: SHA1 SMIME and SHA1 document signing may be vulnerable at the same time as code signing and SSL, however they are smaller targets than code signing and SSL. This SHA1 deprecation policy focuses on SSL and code signing certs, but the policy will apply to all certificates issued under the root hierarchy including S/MIME. We expect all certificate types excluding code signing and time stamping to follow the SSL deprecation schedule.

  • The SHA-3 is on the way. Why? We need fast and efficient hardware-accelerated solution to calculate secure hashes due to all future IT secure solutions will use hash check routinely for even big files and streams like DRM-video. In the year 2016 SHA-2 expected to be obsolete as inefficient in terms of "green energy saving".

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment