Google and Mozilla are Deprecating Existing Symantec Certificates

Ivan Ristic

Last updated on: October 21, 2021

Earlier this month, after roughly six months of deliberation and planning, Google finalised their plans for staged deprecation of Symantec certificates. The process began in March 2017 when Google had announced on the Blink mailing list that they had lost confidence about Symantec’s certificate issuance policies and practices of recent years. The initial deprecation proposal was very strict and looked like it would completely paralyse Symantec, ending with limiting their certificates to validity time of less than one year.

Over time, however, a different solution emerged and Symantec agreed to handle operations of their PKI to some other CA, selecting DigiCert for the role. In return, Google agreed to a deprecation plan that will still be difficult for Symantec, but allows them to resume issuance normally afterwards. Mozilla carried out their own investigation and decided to match Google’s actions and dates. In the final twist, Symantec decided to sell their certificate business to DigiCert.

From the end user perspective, the bottom line is that a fair share of Symantec certificates will expire early. There are two deprecation stages. First, certificates issued before June 2016 will stop working in March 2018, with Chrome 66. All remaining certificates will stop working in September 2018, with Chrome 70.

There are two deprecation phases because Symantec’s certificates issued from 1 June 2016 have been logged to public Certificate Transparency logs. It’s worth mentioning that, if you read the actual deprecation plans, you’ll find that there are many different dates and other milestones, because Chrome is released in stages, in alpha, beta, and stable channels. The dates we’ve adopted as milestones ensure that Chrome beta users won’t be affected. Overall, it’s always better to replace these certificates sooner rather than later.

The final important point is that, from December 1st, DigiCert will be issuing certificates on behalf of Symantec. These certificates will not be affected by either deprecation phase. Thus, if you want to stay with Symantec, you should only replace your current certificates from December onwards. If you decide to switch to another CA, you can replace your current certificates at any point before they are deprecated. According to Symantec, they are now working with DigiCert to replace all their existing certificates. If you’re a customer, you can contact Symantec (and their other brands, Thawte, RapidSSL and GeoTrust) for assistance.

To help our users with the transition, SSL Labs will start to warn whenever it encounters a leaf certificate issued from Symantec PKI that is affected by the deprecation. Starting with today, the warnings are on our development servers, and the production servers will follow soon.

Update February 2018:
Starting 1 March 2018, SSL Labs will give “T” grade for Symantec certificates issued before June 2016.
Starting 1 September 2018, SSL Labs will give “T” grade for all remaining Symantec certificates. 

Show Comments (15)

Comments

Your email address will not be published. Required fields are marked *

  1. There is a warning displayed for some sites but not others even though the have the same chain. Why is that? What is the criteria for the warning message?
    This server’s certificate will be distrusted by Google and Mozilla from September 2018.

  2. Evren,
    Sites are getting warned & blocked (chrome) and warned (firefox) today for those of us running recent builds of those browsers.
    Do you have any examples of sites using a deprecated certificate that is not detected here?

  3. So Chrome and Firefox are blocking/warning about Symantec certificates. What are the plans from Google and Apple from an Android and iOS perspective ?

  4. I don’t believe apple ever spoke on the subject, but i did notice i could not access some sites from my iphone when the first lot was untrusted, or i have to approve the website as it had a warning.
    If you have an SSL just get another brand like comodo https://www.ssltrust.com.au/comodo-ssl or reissue your symantec one as the root will be digicert now which is trusted.
    And if you are a frontend user, if it is a known website and it stops working the day after they untrusting… i am sure it would be okay to continue on as they owner of the website will know to fix it very soon.

  5. I have a wildcard issued by RapidSSL that has been re-issued on 4-Jun-2018 and I’m still getting this warning despite the chain being anchored to the DigiCert root. What’s the criteria for the warning that the cert will be distrusted in September 2018?

  6. Ironically, this very blog uses a Symantec SSL/TLS certificate that Chromium/Chrome 70 is blocking access to.

    When will this blog upgrade to a Google-trusted certificate?

  7. There looks to be a false positive if cross signing is used. See https://knowledge.digicert.com/generalinformation/digicert-root-compatibility.html and note the certificate chains that use DigiCert in addition to Verisign.

    Also note that Apple stopped supporting old Symantec brands issued certificates on August 1 in advance of Chrome 70 and Firefox’s release. See https://support.apple.com/en-ca/HT208860 titled “Information for website operators about distrusting Symantec certificate authorities” for details.

  8. hI,
    i do not see a problem loading SSL sites on Firefox 60 or latest Chrome even now as it is September 18th 2018 already, though these SSL sites if we do a SSLlabs cert test gives T grade. Strange it still works fine. We rushed and migrated most of our sites to Digicert, few of them which are not important still on Thawte and continous loading fine …Sigh!!

    1. This looks to be falsely identified by Qualys. I have the same issue reported but the certificate is:
      – Trusted and working
      – Never had anything to do with Symantec.

      Even Chrome explicitly says it’s trusted and secure.

  9. Hi, I have just upgraded to chrome build 70 and I can load a web site with ‘trust issues’ without an error. Can we get an update on how this ‘feature’ is being rolled out? Is it date dependent, or build dependent?