Blogs

    Publish
     
      • Transitioning from SHA-1 TLS Certificates

        Oct 20 2017, 9:02 PM

        by Unknown 4

        Since its founding, Symantec has been dedicated to security.  That is our raison d’etre. As such, we continually collaborate across the industry to update standards, making them more secure and harder to hack or fake. That is why the CA/Browser Forum determined that Certification Authorities must not issue public SHA-1 TLS certificates after December 31, 2015. While this directive is an important step in making the Internet safer and more secure, the transition process also needs to support companies with legacy systems and devices so they are not left behind or saddled with insurmountable IT costs.

        We liken this to when the US government determined that the use of lead paint was unsafe and should stop being used. That directive was absolutely the right thing to do moving forward, but to require that every house and building in the US remove all lead paint by a certain deadline would have created financial and logistical impossibilities for consumers and businesses.  While it is correct to strive for the perfect ideal, the real-world implications are often a bit messy.

        In the same vein, the shift to the SHA-256 standard severely impacts legacy systems and applications.  We heard from some of our customers that they could not switch out every certificate in every application and device, not only because of the time and cost involved, but also because many of the systems and some older browsers simply don’t support SHA-256.  While we fully support and encourage the transition to SHA-256 from a security purist standpoint, we also believe it is unreasonable to force our customers to absorb significant business and financial hardships that could severely impact their viability and operations, as well as that of their end users. 

        Therefore, we were left with a choice: either force customers to completely cease support of all those legacy systems, applications, devices and browsers that cannot support SHA-256, or try and identify ways to help ease the transition for customers to SHA-256 while minimizing the risk of continued SHA-1 support for those customers who still need it.

        In an effort to help these customers, Symantec, along with other CAs and Microsoft, proposed a CA/Browser Forum ballot to allow continued issuance of SHA-1 TLS certificates into 2016, as long as those certificates expired by the end of 2016 – providing additional transition time for those who needed it. During the ballot debate, researchers unveiled new attacks against SHA-1, revealing the algorithm to be weaker than originally thought. As a result, the ballot was withdrawn.

        Throughout 2015, Symantec and other CAs issued fewer and fewer SHA-1 TLS certificates as we transitioned to certificates signed with the newer, stronger SHA-256 hash algorithm. That was as expected, since the industry has been working for several years to manage this algorithm transition.

        We’re now beyond December 31, 2015 - the SHA-1 issuance deadline set by the CA/Browser Forum Baseline Requirements. And as we look back over the last three months of 2015, it’s clear that customers had planned around this deadline as we experienced a last-minute surge in customer orders for SHA-1 certificates in December:

        October

        November

        December

        7,076

        6,096

        19,278

        Many customers clearly chose to enroll for and to obtain SHA-1 certificates as close as possible to the end-of-2015 issuance deadline, something even recommended by one of the browser members of the CA/Browser Forum.

        But we have customers for whom even all of 2016 is not enough time to transition. For these customers, we have identified another way to help – to use our legacy public roots for specific use cases (such as with legacy feature phones) while instructing browsers, and all other clients that can, to stop trusting these roots for general applications.  Given the nature of the attacks on SHA-1 and other hashing algorithms, the best defense is really in the hands of the browsers and other clients to remove support for SHA-1 altogether.

        With that goal in mind, we reached out to browser vendors in November 2015 to formally advise them to remove or “un-trust” our legacy PCA3-G1 root if they had not already done so (some had removed the root earlier in 2015). With browsers discontinuing support for SHA-1 and our PCA3-G1 root specifically, the general risk of a SHA-1 attack is substantially reduced.  This multi-prong approach strikes the hard-sought balance between our intent for stronger security and our intent for a practical transition for all involved. Even this approach is proving more difficult than expected, as it created issues for some clients, such as those with older Android devices and for some code-signing customers on Windows. Given additional transition time potentially needed by these clients, we will continue to include our legacy PCA3-G1 root in our annual WebTrust for CAs Audit so anyone still supporting these roots can be confident that certificates issued from these roots are issued in line with our public Certificate Policy and Certificate Practices Statement.

        While moving to a private CA root can help those customers with incompatible systems, Symantec has repeatedly directed all of our customers who can to make the transition to SHA-256 as quickly as possible.  The guide we issued on moving from SHA-1 to SHA-256 certificates can be found in our Knowledge Base

        Symantec fully supports the deprecation of SHA-1, but we are also acutely aware of the difficulty this transition poses for many enterprise customers and technology providers across the ecosystem. We have put in place measures that we hope balances the very real business needs of our customers with the goal of creating a more secure web environment. As a founding member of the CA/Browser Forum, we wanted to be open and transparent about how we have tackled this transition and why we made the decisions we did to both advance adoption of the latest security standards while finding practical ways to support our customers who are struggling with very tangible issues.

        • Products
        • migration
        • Symantec Website Security
        • SHA-1
        • DigiCert Code Signing
        • DigiCert Complete Website Security
        • certificate
        • SHA-2
        • Products and Solutions
        • Root
      • Google’s SHA-1 Deprecation Plan for Chrome

        Oct 20 2017, 8:36 PM

        by Brook Chelmo 1

        The latest news in the SSL and web browser industries is Google’s plans to deprecate SHA-1 in a unique way on upcoming releases of Chrome starting with version 39. Considerably different from Microsoft’s plans that were announced in November 2013, Google plans on placing visual marks or placing a block within the browser; all based on the version of the browser, date of use and certificate’s expiration date.

        Here is what you need to know first:

        1. SHA-1 is still safe to use but critics say its long-term ability to stand up to collision attacks is questionable.
        2. SHA-2 is the next hashing algorithm to be used.  If your end-entity or intermediate certificates are SHA-1, it might be a good idea to exchange them now.
        3. This issue faces all Certification Authorities, not just Symantec.
        4. All SHA-1 end-entity certificates and SHA-2 end-entity certificates chaining up to a SHA-1 intermediate are affected. SHA-1 root certificates are not affected by either Microsoft’s or Google’s SHA-1 deprecation plan.
        5. Google is using three terms that you may want to familiarize yourself with:
          1. secure, but with minor errors,
          2. neutral, lacking security, and
          3. affirmatively insecure.
        6. Symantec offers free replacements for affected Symantec SSL certificates.

        What we expect to see with future Chrome releases:

        Chrome 39 (Beta release: 26 September 2014, tentative production release: November 2014):

        1. Any SHA-1 SSL certificate, on a page, that expires on or after 1 January 2017 will be treated as “secure, but with minor errors”.  The lock within the address bar of the browser will have a yellow arrow over the lock as in this example provided by Google:

        google-blog-1.png

        Chrome 40 (Beta release: 7 November 2014, tentative production release: post-holiday season):

        1. Pages secured with a SHA-1 certificate expiring between 1 June 2016 and 31 December 2016 inclusive will experience the same treatment as described above.
        2. Additionally, pages secured with a SHA-1 certificate expiring after 1 January 2017 will be treated as “neutral, lacking security”.  The lock in the address bar will be replaced by a blank page icon as in this example provided by Google:

        google-blog-2.png

        Chrome 41 (Q1-Q2 2015):

        1. Sites secured with a SHA-1 certificate with validity dates terminating between 1 January 2016 and 31 December 2016 inclusive will be treated as “Secure, but with minor errors.”
        2. Sites secured with a SHA-1 certificate expiring on or after 1 January 2017 will be treated as “affirmatively insecure”.  The lock will have a red “X” over it with the letters “HTTPS” crossed out with a red font as in this example provided by Google.

        google-blog-3.png

        Here is a matrix to help you understand the dates:

        Sample Expiration Dates

        Chrome Version (Beta dates)

        SHA-1

        (Dec 31 2015)

        SHA-1

        (Jan 1 – May 31  2016)

        SHA-1

        (Jun 1 – Dec 31 2016)

        SHA-1

        (Jan 1 2017 and beyond )

        Recommended:

        SHA-2

        Chrome 39

        (Sept. 2014)

        google-blog-4.png

        google-blog-4.png

        google-blog-4.png

        google-blog-5.png

        google-blog-4.png

        Chrome 40

        (Nov. 2014)

        google-blog-4.png

        google-blog-4.png

        google-blog-5.png

        google-blog-6.png

        google-blog-4.png

        Chrome 41

        (Q1 2015)

        google-blog-4.png

        google-blog-5.png

        google-blog-5.png

        google-blog-7.png

        google-blog-4.png

        Moral of the story: Move to SHA-2, especially if your SSL certificate expires after December 2015.

        What you need to do.

        1. Use our SSL Toolbox to see if your certificates are affected.  SHA-1 SSL certificates expiring before 2016 are NOT affected and can be replaced with a SHA-2 certificate at renewal time if you wish.
        2. If your Symantec certificates are affected you can replace them at no additional charge for a SHA-2 certificate, or a SHA-1 certificate with a validity that does not go past 2015.  Check with your vendor if they have a free replacement program like Symantec.
        3. Install your new certificates.
        4. Test your installation using the SSL Toolbox.
        5. Security Best Practice:  Revoke any certificates that were replaced in step #2.

        For more in-depth information, instructions, and assistance please refer to our knowledge center article on this subject.  For a list of SHA-2 supported and unsupported applications review this list from the CA Security Council.

        Read our SHA-2 webpage for the tools, steps to take, and a list of FAQs that can be generally applicable across all browsers.

        • Products
        • Google Chrome
        • website security solutions
        • Symantec Website Security
        • SHA
        • SHA-1
        • chrome
        • DigiCert Complete Website Security
        • Products and Solutions
        • Google