There are developments in the Google Chrome Vs. Symantec issue, which has been ongoing for the last six months. Before discussing the recent developments, let’s take a look back and discuss what all has been happening, for the sake of those who have not been following the developments…
How it all started off…
In January this year an independent researcher reportedly spotted Symantec improperly issuing 108 invalidated transport layer security (TLS) certificates. Google engineer Ryan Sleevi had said, in a forum discussion on Google Groups, in March- “”Since January 19, the Google Chrome team has been investigating a series of failures by Symantec Corporation to properly validate certificates. Over the course of this investigation, the explanations provided by Symantec have revealed a continually increasing scope of misissuance with each set of questions from members of the Google Chrome team; an initial set of reportedly 127 certificates has expanded to include at least 30,000 certificates, issued over a period spanning several years. This is also coupled with a series of failures following the previous set of misissued certificates from Symantec, causing us to no longer have confidence in the certificate issuance policies and practices of Symantec over the past several years.”
Google then announced that it would start gradually distrusting Symantec certificates and that the CA’s EV (Extended Validation) certificates won’t be recognized, for at least one year, until the company fixes its certificate issuance processes and gains trust once again.
Well, that was the beginning. In a blog post dated 26 Apr 2017, Symantec had come out with a detailed response and plan details. On May 12, members of the Chrome team had met with Symantec aiming to discuss their concerns and a proposed remedy as well. In a recent Google Group update, Ryan Sleevi has written, under the heading ‘Transition to a New Symantec PKI’-
“Chrome will require that by 2017-08-08 all new Symantec-chaining certificates be issued by independently operated third-parties (aka “Managed CAs”).
Chrome will implement a check, on-or-after 2017-08-08, to enforce this by ensuring that the certificate chain contain a whitelist of intermediates (independently operated sub-CAs or the Managed CAs).
If a Managed CA has fully revalidated the information, the validity period of new certificates can be up to the maximum allowed by Chrome for all CAs, which is currently specified as the maximum allowed by the Baseline Requirements and EV SSL Guidelines.
During a transition period, validation information can be reused, provided that the certificate is issued by the new infrastructure. However, the validity period of such certs must be no longer than 13 months.
If Symantec needs this flexibility, the following deadlines apply:
- 2017-08-08 – Certificates must be issued by the Managed CA, but can re-use existing validation information (up to the limits imposed by the Baseline Requirements).
- 2017-11-01 – Certificates must be issued and have domains revalidated by the Managed CA, but can use re-use existing organization validation information (up to the limits imposed by the Baseline Requirements).
- 2018-02-01 – Certificates must be issued and have all validation performed by the Managed CA.
The use of existing or new validation information in a certificate should be signalled by using new OID in the Certificate Policies extension. ”
He had also written, under the heading ‘Existing Certificates’-“Chrome will continue to trust certificates issued after 2016-06-01, provided they are “CT Qualified” as defined in the Chrome CT Policy.
Enterprise Chrome users will be given a policy to allow certificates issued before 2016-06-01. This will give enterprise administrators the ability to control Chrome behavior for their organizations. This can be specified both at device-level as well as at user-level.
We’re proposing a phased distrust of all website certificates issued prior to 2016-06-01, which is the date in which Chrome both required and enforced Certificate Transparency. This provides a degree of assurance for site operators that certificates issued for the improper domain have a reasonable chance of being detected. With this, our goal is to attempt to minimize disruption to site operators, ensure reasonable notice of these changes, and avoid particularly sensitive holiday disruptions. These plans represent target dates, which may need to be adjusted based on interoperability or compatibility risk or additional information coming to light that may accelerate such distrust.
- On 2017-08-31, no longer trust any certificate whose notBefore was prior to 2015-06-01. This corresponds with an expected Chrome 62 date.
- On 2018-01-18, no longer trust any certificate whose notBefore was prior to 2016-06-01. This corresponds with an expected Chrome 65 date.”
As all this is happening…
For SSL users, especially Symantec SSL users, all this may seem complicated. Other CAs definitely are following these happenings. Melih Abdulhayo?lu, founder and CEO of Comodo, the company that leads the international SSL market, says in one of his LinkedIn updates – “I am frequently asked about what is happening and how it might affect enterprises…Its unfortunate that it came to this stage…..its not a positive thing for the industry nor for Symantec customers. I do see a “change” for Symantec customers, its unavoidable. There will be a new CA providing their certificates and it will not be Symantec! ”
Author Bio: Unni Nair has his moorings in journalism, screen-writing and Public Relations. He has also been actively engaged in Online Reputation Management and Social Media Management for leading companies and celebrities, and writes on diverse topics relating to online reputation management, cyber security etc.