Chrome Is Distrusting Symantec Certificates: Your Replacement Timeline

If your site uses a certificate from Symantec, or from one of the brands it has run over the years (VeriSign, Thawte, GeoTrust, RapidSSL), you have a deadline coming. Possibly two.

Earlier this year, after a long public discussion, Google's Chrome team settled on a plan to gradually remove trust in certificates issued by Symantec's existing certificate authority infrastructure. Mozilla has announced a broadly similar schedule for Firefox. In the meantime, Symantec agreed to sell its website certificate business to DigiCert, and that deal closed at the end of October. New certificates for these brands are supposed to be issued from new infrastructure going forward.

None of this changes anything in your browser today. But there are two dates in 2018 when certificates that currently work perfectly will start producing full-page security errors in Chrome, and the first one is only about five months away.

Why this is happening

The short version: browsers trust a certificate authority on the understanding that it follows the industry's rules for validation and issuance, and that it's audited on that basis. Over the past couple of years, researchers and browser teams documented a series of problems with certificates issued under Symantec's roots, including certificates issued without proper validation and weak oversight of partner organisations allowed to issue under those roots. The browser teams concluded they could no longer rely on the existing infrastructure.

Because Symantec's brands are among the largest CAs on the web, an immediate distrust would have broken a large fraction of HTTPS sites overnight. The plan that was agreed spreads it out so site owners have time to replace certificates.

The timeline

Chrome's plan, as published, has two distrust steps. Release dates for Chrome versions are approximate and occasionally move, so treat the months as guidance:

Beta and developer channels will get each change several weeks earlier, so some of your more technical users will see errors before the stable release.

The June 2016 cutoff matters because it catches long-lived certificates. A three-year certificate bought in early 2016 is still valid well into 2019, but Chrome 66 will reject it anyway. Expiry date doesn't protect you here; issuance date and issuer are what matter.

Are you affected?

Check what your server actually presents. The issuer is the thing to look at:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -issuer -dates

If the issuer names Symantec, VeriSign, Thawte, GeoTrust or RapidSSL, you're in scope. Then look at notBefore:

• Issued before June 1, 2016: replace before Chrome 66, meaning by early spring 2018 at the latest.
• Issued on or after June 1, 2016: replace before Chrome 70. You can wait until next summer, but there's no benefit to waiting and plenty of risk in forgetting.

Some details to be careful about:

1. Check every hostname. It's common for the main site to have moved to a new CA years ago while an API endpoint, a customer portal or a payment page still runs an old GeoTrust certificate bought by someone who has since left.
2. Check what third parties present for you. CDNs, hosted shops and SaaS tools running on your subdomains may have their own certificates. Their deadline is your problem if it's your hostname in the address bar.
3. Not every certificate under these brands is affected. Certificates issued from the new DigiCert-operated infrastructure will stay trusted. The difference is in the chain, not the brand name, so look at the full chain if you're not sure, and ask your CA.
4. Resellers muddy the picture. Many certificates were bought through hosting companies and resellers that didn't make the underlying CA obvious. The issuer field is the ground truth.

Replacing a certificate

DigiCert has said it will replace affected certificates at no charge for the remaining term. That's usually the simplest path if you're happy to stay with them. Moving to another CA entirely is also a reasonable option, including Let's Encrypt for sites where short-lived automated certificates suit how you work.

Either way, the mechanics are the same as any renewal: generate a new key and CSR, get the certificate issued, install it with the correct intermediate chain, reload, and check from outside. Two extra steps worth doing this time:

• Update your CAA records if you publish them. If you added CAA records this year listing symantec.com, and you're moving to a different CA, add the new CA before you request the certificate, or issuance will be refused.
• Check any certificate pinning. If you use HTTP Public Key Pinning, or pin certificates in a mobile app, a change of CA can lock users out. Update pins well ahead of the switch and leave overlap.

Don't leave it until the Chrome release

The failure mode we worry about isn't the flagship website. Someone will notice that, because it's in front of everyone. It's the secondary hostnames: the login page on a separate domain, the reporting tool that customers log into once a quarter, the embedded widget on a partner's site. Those are the ones that produce a support queue full of screenshots of red warning pages.

We saw a smaller version of this in October, when Chrome 62 started warning on HTTP forms and people discovered pages they'd forgotten they had. The Symantec deadlines are a harder break: a certificate error is a wall, not a label.

So make a list now. Every hostname you serve over HTTPS, its issuer and its issue date. Replace the pre-June-2016 ones this year, the rest by early summer, and keep checking afterwards, because certificates have a way of coming back from old config backups. External certificate monitoring, the kind CompleteStatus runs, is one easy way to keep that list honest over the next twelve months.