Endpoint

3/13/2018
02:30 PM
Zeus Kerravala
Zeus Kerravala
Commentary
Connect Directly
Facebook
LinkedIn
Twitter
RSS
E-Mail vvv
50%
50%

Google 'Distrust Dates' Are Coming Fast

All the tools are in place for the migration of SSL digital certificates on a scale that is unprecedented for the certificate authority industry. Are you ready?

The deadline is fast approaching for organizations to replace Symantec-issued SSL digital certificates, spurred by a Google decision last year to gradually deprecate all Symantec digital certificates because of failures on Symantec's part to properly validate its SSL certificates before issuance.

Symantec, at the time, characterized Google's claims as misleading and grossly exaggerated. The company claimed that only 127 certificates were identified as mis-issued and not 30,000. Symantec said that Google was singling it out for blame though the mis-issuance involved multiple certificate authorities (CAs).

Fast forward to today: Google has created a path for Symantec certificate holders to replace these certificates simply through DigiCert, in a fashion similar to a renewal process. The first of two dates related to this change will occur Thursday, March 15, and security teams need to be aware of how to deal with the process. But first, a bit of history and context.

When an SSL certificate is installed on a Web server, the connection between the server and browser is encrypted. Users know this security is in place because they see a padlock and the word "secure" at the start of the URL line as well as "https." To enable this, businesses need to purchase and install a certificate from a valid CA. These certificates need to be renewed and reinstalled periodically — typically, every two to three years — to stay in compliance.

In early 2017, an issue was raised concerning a number of certificates issued by Symantec's SSL business, which operated several CAs under Symantec ownership with the brand names of VeriSign, Equifax, GeoTrust, Thawte, and RapidSSL. For a number of reasons, these did not comply with industry requirements for browsers. There was an investigation, and it was deemed that Symantec had entrusted a number of organizations to issue certificates without the necessary oversight.

Google Steps In
The net result was that Google put a plan in place to distrust certificates issued by Symantec and all its subsidiaries over a period of time. At the time, Symantec was the largest CA and instead of making the necessary changes, it decided to sell the business to the second-largest CA, DigiCert, in November 2017, making DigiCert the overwhelming market share leader.

Google's plans included three critical dates:

December 1, 2017: One month after the DigiCert/Symantec deal closed, validation and issuance of Symantec certificates were handled by DigiCert. No changes were required by the customers of either of the two companies.

March 15, 2018: Chrome 66 beta will distrust all Symantec certificates issued prior to June 1, 2016. Around April 15, 2018, the general, or stable, version of Chrome will feature untrusted warnings for these certificates.

September 13, 2018: Chrome 70 beta will distrust all certificates issued by Symantec. In October 2018, the general, or stable, version of Chrome will feature untrusted warnings for these certificates.

Companies that don't comply with this will experience a situation in which users connecting to their site get directed to a page that warns them that the communication isn't secure. That may or may not be a problem, depending on the site, but it's often enough to scare people away and go click somewhere else, so keeping those certificates up to date is crucial.

A Headache for Big Business
Upgrading the certificates isn't a big deal if you're a small business with one or two Web servers. However, for large companies with thousands of servers, this can be a huge headache. Certificates are also now being deployed on Internet of Things devices, so if they aren't upgraded, the communications won't be encrypted or may stop transmitting information. 

To help its customers make this shift, DigiCert has made available a website checker to see if companies needs to take action. For example, if "Symantec.com" is put into the URL line, the site issues a warning to replace the certificate before September 13, 2018. This simple tool lets customers quickly check which sites need upgrading and when. 

DigiCert also has greatly simplified the process of procuring the certificates. What used to be a rather cumbersome set of tasks has been simplified to literally a couple of mouse clicks, and the certificate is renewed and upgraded. For companies investing in automation technologies, including the robust set of APIs that DigiCert offers, those few mouse clicks can be removed from the equation entirely.

In conversations with a number of customers, I've learned that these automation tools have been a huge time saver, with companies now able to upgrade all their servers in a fraction of the time it previously took. It's important to note that SSL certificates are now being used on IoT devices as a way of encrypting the traffic to and from them, so many organizations should expect to see the number of certificates they need to manage grow exponentially.

One other important consideration: While most Web users won't notice warnings until the April stable release of Chrome, I recommend that organizations upgrade their affected certificates now. Domains and organizations need to be validated before DigiCert can issue the certificate, and delays by customers can sometimes cost them a couple of days in getting their certificates. There's actually no reason not to upgrade the ones affected by the September date either. Not getting it done in time will mean that when customers access the business website, they will be greeted with a Chrome security warning and that could drive them to a competitor.  

In truth, a migration of this magnitude, which is unprecedented in the CA industry, could have been a disaster. Given that the acquisition of the Symantec CA business was only completed in November, DigiCert has done a remarkable job in consolidating the platforms and support organizations. All the tools are now there for customers to ensure that their Web servers won't have a problem, so the ball is now in the court of security teams. The Google distrust dates are coming fast — are you ready?

Related Content:

Interop ITX 2018

Join Dark Reading LIVE for two cybersecurity summits at #Interop ITX. Learn from the industry’s most knowledgeable IT security experts. Check out the Interop ITX 2018 agenda here. Save $200 off your conference pass with Promo Code 200MC.

Zeus Kerravala provides a mix of tactical advice and long term strategic advice to help his clients in the current business climate. Kerravala provides research and advice to the following constituents: end user IT and network managers, vendors of IT hardware, software and ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Election Websites, Back-End Systems Most at Risk of Cyberattack in Midterms
Kelly Jackson Higgins, Executive Editor at Dark Reading,  8/14/2018
Intel Reveals New Spectre-Like Vulnerability
Curtis Franklin Jr., Senior Editor at Dark Reading,  8/15/2018
Data Privacy Careers Are Helping to Close the IT Gender Gap
Dana Simberkoff, Chief Compliance and Risk Management Officer, AvePoint, Inc,  8/20/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-1394
PUBLISHED: 2018-08-20
Multiple IBM Rational products are vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session. IBM X-Force ID: 138425.
CVE-2018-1517
PUBLISHED: 2018-08-20
A flaw in the java.math component in IBM SDK, Java Technology Edition 6.0, 7.0, and 8.0 may allow an attacker to inflict a denial-of-service attack with specially crafted String data. IBM X-Force ID: 141681.
CVE-2018-1656
PUBLISHED: 2018-08-20
The IBM Java Runtime Environment's Diagnostic Tooling Framework for Java (DTFJ) (IBM SDK, Java Technology Edition 6.0 , 7.0, and 8.0) does not protect against path traversal attacks when extracting compressed dump files. IBM X-Force ID: 144882.
CVE-2015-5160
PUBLISHED: 2018-08-20
libvirt before 2.2 includes Ceph credentials on the qemu command line when using RADOS Block Device (aka RBD), which allows local users to obtain sensitive information via a process listing.
CVE-2015-5243
PUBLISHED: 2018-08-20
phpWhois allows remote attackers to execute arbitrary code via a crafted whois record.