Symantec Certificates Are Not Being Dis-Trusted on August 8th
1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)

Symantec Certificates Are Not Being Dis-Trusted on August 8th

Don’t worry, your certificates are not days away from being invalid.

If you have been following the Symantec/Google (and Mozilla) saga you likely know two things: it has been very confusing, and if you use Symantec certificates (or any of its other brands – RapidSSL, Thawte, or GeoTrust) you are going to need to replace your certificates at some point.

Google announced its final plan last week – which will affect existing certificates starting April 2018. However, we have seen that some users are still confused if this is accurate. This post is here to set the record straight.

Google’s previous and now outdated proposal would have had a large number of Symantec certificates becoming invalid on August 8th, 2017 – as in, a few days from now. This is no longer applicable – it’s not happening.

Instead, Google opted to push back any action involving existing certificates until April 2018 (in the “Stable” version of Chrome – which most end users use. See our note below on pre-release versions). To learn about Google’s final proposal, which you should be planning your changes around, please read this dedicated post.

Some have been concerned that the lack of an official post on Google’s Security Blog means it is unclear what plan is being put into action.

We understand the value of a Professional & Official Post – especially when you are about to convince your organization that they don’t need to worry about certificate errors in 4 days.

But since that does not exist, we are hoping this post can be the next best thing. We are going to provide citations and everything to give you (and your coworkers) all the reassurance needed to enjoy your weekends.

  1. First, let’s look the proposal posted on July 27th. Darin Fisher, VP of Chrome Engineering, wrote:“Representing Google Chrome and the Chromium open source project, what follows is our final proposal on this matter….Chrome 66 will distrust Symantec-issued TLS certificates issued before June 1, 2016, which is tentatively scheduled [to release] on April 17, 2018.”

    This was the post that superseded previous plans and is Google’s final and current dates for removing trust for existing certificates.

    We will say it again: it starts April 2018.We will again plug our summary of Chrome’s final plan of action – read this if you want to see all the relevant dates and changes.

  2. A second post from a Googler, this one by Devon O’Brien, who works on Chrome’s Security team (see their by-line on this official blog post), reaffirms that the older plan is outdated:“The previously-stated August 2017 dates are no longer applicable.”
  3. Finally, Peter Bowen, who runs Amazon’s Certificate Authority and is an expert on how browser trust works, explained (in two different posts) that at this point it would be technically impossible for Symantec certificates to be affected on August 8th because no code has been added to Chrome to do that:“As of this morning [August 3rd], there is zero code landed in Chromium to implement any of the changes here, so August 8 is very much not happening”


Hopefully, this can set the record straight and clear up any confusion people may have had. It’s April 2018, not August 2017. Capisce?

A Note On “Beta” and “Canary”

Google distributes four versions of Chrome: “Stable,” “Beta,” “Dev,” and “Canary.” It refers to these as its ‘channels.’

The Stable channel is the version for the general public. This is the fully-tested, ‘standard’ version that is on hundreds of millions of computers.

The other three versions are all pre-release versions that allow you to test upcoming versions of Chrome before they are finalized. That does not mean these are some sort of unstable, crazy-looking alternatives. For the most part, the other three Chrome channels look and feel the same and are fairly usable.

Each channel is ‘rougher’ than the last – meaning it has been tested less and has more bugs. Each Chrome version passes through the channels – starting at Canary, usually months in advance – and makes its way to Stable when it is ready for prime time.

The majority of your website’s customers and visitors will be using Stable, however, some small percentage will be on one of the other channels and will see Symantec certificates become untrusted earlier.

So, if you can, you should try to replace affected certificates early in order to avoid inconveniencing this small portion of users.

Here is an approximate breakdown of when Chrome versions 66 and 70, the two versions which will have changes for Symantec certificates, release for each channel. The exact dates may change slightly due to delays or distribution:

Stable Beta Canary
Chrome 66


Certificates Affected:


Any Symantec certificates issued before June 1st, 2016

April 17, 2018 March 15, 2018 Jan 19, 2018
Chrome 70


Certificates Affected:


ALL Symantec certificates issued from their current roots (which will be everything issued before December 1st, 2017).

Oct 23, 2018 Sept 13, 2018 July 31, 2018

(These dates are calculated from Darin Fisher’s post and from this Chromium page. The Dev channel is not included because it does not have a strict release schedule.)

  • Vincent,

    Wondering if you can provide clarification on this: if a cert issued before June 2016 is reissued now will it have be reissued again after Dec 1, 2017 in order to be trusted in Chrome 70?


    • Hi Scott,

      Great question. Quick answer is yes. This is why:

      Reissuing a pre-June 2016 cert now will allow it to stay trusted in Chrome 66. But once Chrome 70 hits it would still be dis-trusted due to it being issued from Symantec’s current roots.

      There is a way to avoid this and re-issue the certificate only once: by waiting.

      Instead of re-issuing pre-June 2016 certs now, you can wait until December 1st 2017 when DigiCert begins issuing the certificates from their root. This will essentially fix both problems at once (both making them CT compliant and being issued from new roots).

      For most users, waiting should not be a problem. They would have between December 1st – April 17th 2018 (when Chrome 66 releases) to get those pre-June’16 certs replaced, which is a fairly healthy amount of time.

      However, some users may experience “holiday freezes” where they are unable to make any changes, or lose lots of time to vacation around Dec/Jan, which could mean they are cutting it close, depending on how many certs they need to replace, how experienced they are with SSL, and how they prioritize.

      There is one other, smaller (imo) consideration: for Canary, Chrome 66 hits as early as Jan 19th. That only gives you ~6 weeks (counting from Dec 1st) to get your certs replaced without any of your users seeing errors. I don’t know usage statistics, but I imagine a very small proportion of Chrome use is Canary. I also believe Canary users are aware of and expect breakage.

      But both those potential risks should be known when considering what to do.

      I know thats a lot of information, so to summarize:

      Option 1. Reissue pre-June 2016 certs now (between today and Dec 1st) and then reissue again (between December 1st and Oct 2018) to avoid both dis-trust periods.

      Option 2. Wait to reissue pre-June 2016 certs until Dec 1st. This will allow you to reissue once and stay trusted until the expiration date listed. The downside here is making sure this gets done BEFORE April 2018 and knowing that some Canary/Beta users could be affected the longer you wait.

      Hopefully that is all clear, but Im happy to clarify further if needed.

  • Vincent,

    Thanks for the detailed clarification and the suggested options. I was thinking exactly the same thing about waiting until after Dec 1, 2016 however I didn’t take the holiday freeze into consideration.

    Thanks again!

Leave a Reply

Your email address will not be published. We will only use your email address to respond to your comment and/or notify you of responses. Required fields are marked *

Captcha *