Google to revoke key digital security certificates
Updated Monday, July 1: This article has been updated to include information regarding Mozilla’s role in highlighting issues with Entrust.
An announcement from the Google Chrome security team has come as a security and privacy bombshell to the 3.45 billion users of the Chrome browser. Starting November 1, the world’s most widely used web browser will no longer trust digital certificates issued by Entrust, one of the world’s most widely used certificate authorities. How big are Entrust’s digital security certificates? Its customers include Chase Bank, Dell, Ernst & Young, Mastercard, and Merrill Lynch, not to mention governments around the world.
Google to revoke trust in Entrust digital certificates
Google’s June 27 announcement doesn’t mince words: It justifies the decision to revoke TLS certificates issued by Entrust and AffirmTrust, which Entrust acquired in 2016, on the grounds that Chrome users’ security and privacy are top priorities, stating, “We are not willing to compromise on these values.” This is serious business, very serious, because these certificate authorities serve as the basis for the encrypted connections that users rely on between their web browser and the Internet.
Referring to the Chrome Root Program policy, updated in January, Google said that these certificates must provide Chrome users with value that “outweighs the risk of their continued inclusion.” That’s no longer the case, according to the Chrome security team, which explains that in recent years, Entrust’s behavior in responding to publicly disclosed incidents has fallen short of its expectations. Google said this has “eroded trust in its competence, reliability, and integrity as a publicly trusted certificate authority owner.”
Mozilla lists Entrust bugs, leading to lengthy report in response
Google isn’t the only browser vendor to have issues with Entrust. Mozilla has been very vocal in recent months about incidents with the certificate authority. Indeed, it was complaints from Firefox browser developers about such incidents between March and May that led to a lengthy and detailed response from Entrust in the form of a report to the Mozilla community published on June 7.
In the report’s summary, Entrust, a certificate authority for more than two decades, admitted that the incidents were “unnecessary and based on our own mistakes or errors in judgment” and, as such, did not meet the standards the organization expected of itself. “We have carefully considered the questions and feedback from the community, and this feedback is reflected in our plans,” the report said. Those plans include adding strategic compliance support with the CA/Browser forum, expanding Entrust’s involvement. Compliance governance will be addressed through a “cross-functional change control board” that would review key policies and decisions, as well as address gaps in change control processes to minimize the risk of errors. Incident response and revocation policies will also be reviewed and clarified, Entrust said.
The June 7 report concluded that “we have identified the necessary resources and have the support of the highest levels of our organization to ensure accountability and execution of these plans.”
Entrust’s Response to CA/B Forum and Google
In a June 21 post to the Certification Authority Browser Forum, Entrust President of Digital Security Solutions Bhagwat Swaroop said that some recent incidents “were not properly reported and communicated to the CA/B forum” and added that “our initial position of not revoking the affected certificates was incorrect.” Swaroop went on to say that none of the “failures” were malicious or committed with ill intent: “As a global CA, we have to walk a tightrope to balance the requirements of root programs with the needs of subscribers, particularly for critical infrastructure. In some cases, we have not struck the right balance.” Swaroop pledged that Entrust is committed to making lasting changes, both organizational and cultural, to begin regaining the trust of root programs and the community.
Entrust Disappointed by Google Chrome Root Program Decision
It appears that this commitment came too late for Google. An Entrust spokesperson told The Stack that “the Chrome Root Program’s decision is a disappointment to us as a long-time member of the CA/B Forum community. We are committed to the public TLS certificate industry and are working on plans to ensure continuity for our customers.”
The Entrust spokesperson also confirmed that the Chrome Root program’s decision has no impact on its Verified Mark certificates, code signing and digital signing, or private certificate offerings.
What this means for Google Chrome users
Entrust and AffirmTrust TLS server authentication certificates signed on or before October 31 will remain valid until their expiration date. Starting November 1, Chrome 127 and later on Android, ChromeOS, Linux, macOS, and Windows platforms will no longer be trusted and will be blocked. Users will see a “non-private connection” dialog when attempting to connect to a site using a blocked certificate, warning them that the site may be attempting to steal personal or financial information.
Non-private connection warning for Chrome users
Google has recommended that website operators switch to another certificate authority owner as soon as possible. While Google acknowledged that the impact of the certificate block could be delayed by operators installing a new Entrust TLS certificate before the November 1 deadline, it warned that “website operators will inevitably need to retrieve and install a new TLS certificate from one of the many other certificate authorities included in the Chrome Root Store.”
It’s worth noting that, according to Google, users will still be able to manually trust root certificates in order to maintain the functionality even after the October 31 deadline. “If a Chrome user or enterprise explicitly trusts any of the above certificates on a platform and version of Chrome that relies on the Chrome Root Store,” Google said, such as when explicit trust is passed through a Group Policy Object on Windows, the constraints “will be overridden and the certificates will function as they do today.”