Avoid SSL certificate errors in Google Chrome and Mozilla Firefox -- The long version
Introduction
If you have an SSL/TLS certificate issued before December 2017 from Symantec or their sub-CAs Thawte, RapidSSL, or GeoTrust, you are now caught up in a "war" with Google Chrome.
This is our attempt to condense a lengthy saga into "one" page.
To get the full picture requires many hours of reading the forums where communication has taken place at Google and Mozilla.
We can see that Google, Mozilla, and Symantec have all made mistakes.
We have followed this case closely since March 2017, when we first heard about it. We have both monitored forums and communicated directly with Symantec.
We have continuously ensured that no customers would be affected and that they would have at least 2 months to, for example, reissue certificates before being impacted.
When we mention Symantec, it also applies to their other CAs: GeoTrust, Thawte, and RapidSSL.
Rules take priority over customers
According to Google and Mozilla, Symantec as a CA has had too many errors and has shown a tendency to break rules, while Symantec says they do not want to harm their customers.
Symantec inherited a complex environment that was essentially 4 separate systems when they acquired the VeriSign CA business on 19 May 2010.
VeriSign built its business by being the largest and buying up its closest competitors GeoTrust, Thawte, and RapidSSL.
Since acquiring VeriSign, Symantec has not carried out any major restructuring or changes to their CA business.
They therefore simply continued with the many systems and various agreements for validators and companies with special contracts.
We can see that all major certificate authorities make mistakes from time to time, and it appears that the more certificates issued, the greater the risk of an error.
There are established rules from both root certificate owners (e.g. Microsoft and Google) and the CAB Forum, which is the common body for certificate industry parties (e.g. Symantec, GlobalSign, Microsoft, Google) that issues shared rules for the industry.
There is a process for reporting a rule violation by a CA.
In short, the CA must investigate the scope of the violation as quickly as possible, find a solution, and document both the error and the solution that will prevent recurrence.
Where a certificate is or is suspected of being issued based on missing or incorrect information, the certificate must be revoked, i.e. cancelled via CRL lists and OCSP.
Errors are expected to occur, and it is primarily how they are responded to and whether they compromise security that matters.
Symantec's responses usually look like something that has been through a legal review, 4 different technical departments, and a financial officer ensuring they do not lose money on the answer.
There are no quick, straight-from-the-hip answers from the technician handling the problem.
The error that triggers Google's distrust is that Symantec has a Registration Authority program allowing 5 other companies to perform full certificate validation. For example, the company CrossCert in Korea.
It is then discovered that CrossCert has issued a total of 127 test certificates from the "Live" environment to domains they do not control, which is a rule violation, test or not.
The certificates are issued to the domains: example.com, test.com, test1.com, test2.com, test3... and so on.
There is no doubt that these are test certificates, or that the certificates are for domains that are not used or can be abused, and they have not been seen "in the wild".
Google believes Symantec should revoke all certificates for which CrossCert performed the validation, which is around 30,000-40,000 active certificates.
Symantec chooses to revoke only the 127 certificates and instead performs a new full validation of all 30,000-40,000 certificates themselves.
They believe this has less impact on customers who purchased certificates through CrossCert's validation.
The attention also reveals that the RA program is not being run correctly, and Symantec therefore chooses to shut down the program and removes all remaining RAs.
You can find the full list of all Symantec CA issues here.
Google Chrome's reaction to the problem
Clearly, Symantec's response is not sufficient for the Google Chrome team.
During a break at a CAB Forum meeting (the body that creates shared rules for all CAs and browsers), Ryan Sleevi from the Google Chrome team, who is attending the meeting himself, publishes a forum post on Google Chrome's development forum, presenting proposals for a gradual distrust of Symantec.
The proposal is very aggressive, and where it gets particularly ugly from Google's side is that in addition to rejecting all current Symantec certificates, causing millions of certificates to suddenly become invalid, Symantec alone would going forward need to comply with unreasonable restrictions on lifetime and EV status that Google had previously tried, without success, to impose on all CAs.
The first proposal (see the proposal here) primarily includes:
- A reduction of all Symantec certificate lifetimes to a maximum of 9 months.
- A gradual rejection of all existing certificates, requiring them to be reissued or replaced.
- Removal of EV status from all certificates, i.e. the display of the company the certificate is issued to and the green address bar.
We agree with Google that Symantec must prioritize rules above customers, and that they should clean up their environments so they are not so complex that one person cannot grasp the whole picture.
This would be good for Symantec in general and for the customers who buy their products.
However, we get the impression that Google Chrome is trying to push its own agenda through Symantec as an alternative route.
They even write at one point that they want to be the example for other CAs to follow, for the rules of the future (so they are confident they will get their rather aggressive requirements through later).
Google Chrome had previously tried to change the maximum certificate lifetime to just 1 year, but their vote was strongly rejected.
They subsequently got a compromise through that reduces the current 3 years to 2 years, from 1 March 2018.
At the same time, they say they would like all certificates to last only a few months and be automatically renewed and installed.
Something that surely works easily for their own fully automated environments and as a CA themselves.
They have also announced a desire to remove EV status for all certificates, as they do not believe it is more secure to display which company you are communicating with.
The certificate only contributes encryption. Something we strongly disagree with; we definitely believe that being able to see that it is SKAT's website makes a difference.
At the same time, they have moved the ability to view a certificate's contents from clicking the padlock to requiring you to open developer tools and the security tab.
Symantec is trying to negotiate a solution that does not hit existing and new certificates as drastically.
Negotiations last just over 4 months, during which Symantec tries to propose alternative solutions that achieve the result Google and Mozilla are after, but without so many customers being so heavily impacted.
A proposal is developed for Symantec to move its certificate business into another existing CA.
It later becomes known that the other company is DigiCert, which buys Symantec's entire web security division and makes it part of DigiCert. (Symantec receives shares in DigiCert, however.)
The requirement is that from 1 December 2017, all validation and issuance of SSL certificates must be done from the new CA, DigiCert.
This requires new streamlined systems to be set up and the many old Symantec systems to be shut down. DigiCert manages it, and on 1 December 2017, they issue all certificates from Symantec's products.
The solution
The key points from the new proposal (view):
| Date | Action |
| 1 December 2017 | Symantec must issue new certificates from the new infrastructure |
| Around 15 March 2018 | Chrome version 66 released in the Beta channel. This version removes trust in Symantec SSL certificates issued before 1 June 2016 |
| Around 17 April 2018 | Chrome version 66 released in the Stable channel. |
| Around 13 September 2018 | Chrome version 70 released in the Beta channel. This version removes trust in Symantec SSL certificates issued from old infrastructure (before 1 December 2017) |
| Around 23 October 2018 | Chrome version 70 released in the Stable channel |
Dates are approximate, and release dates may vary.
Our recommendation
If you have an SSL certificate issued before 1 December 2017 from any of the following brands:
- Symantec
- GeoTrust
- Thawte
- RapidSSL
Browsers from Mozilla Firefox and Google Chrome will display certificate errors.
No other certificate providers (e.g. GlobalSign, AlphaSSL, Comodo) or certificate types (e.g. CodeSign or EmailSign) are affected. And it only applies where a browser client from Google or Mozilla connects to a server, meaning it is not relevant for server-to-server communication.
Check the following table for our recommended approach to avoid browser errors and minimize wasted time:
| Issued | Expiration date | Recommendation |
| Before 1 June 2016 | Before 1 June 2018 | Renew as normal in January-February 2018 |
| Before 1 June 2016 | After 1 June 2018 | Reissue for free or extend in January-February 2018 |
| After 1 June 2016 | Before 1 December 2018 | Renew as normal in January-August 2018 |
| After 1 June 2016 | After 1 December 2018 | Reissue for free or extend in 2018, by 1 September 2018 at the latest |
If you choose to reissue a certificate purchased from us, it is of course free as always. In addition, we offer free CSR service and, if it was included in the original order, free installation as well.
If you have many certificates, want to switch to a different product or provider, are unsure about what is best for you, or simply still have questions about this, please do not hesitate to write or call. We are happy to help.
The fine print. We have included a buffer of more than one month relative to preliminary release dates for stable versions of Google Chrome, so beta releases should not cause issues either. However, we cannot guarantee when different browser versions are released. We therefore recommend making changes sooner rather than later if possible, but not before Symantec's new platform has gone live, expected in December 2017, as this would otherwise mean the process has to be repeated in 2018.
We update this page on an ongoing basis as new information or more precise dates become available.
Last updated 4 January 2018.