This article is more than 1 year old

Spanish banished: Google Chrome to snub Camerfirma for lax cert management

Mozilla meanwhile wants to continue compliance discussions with security certificate vendor

When Google Chrome 90 arrives in April, visitors to websites that depend on TLS server authentication certificates from AC Camerfirma SA, a digital certificate authority based in Madrid, Spain, will find that those sites no longer present the secure lock icon.

Certificate authorities (CAs) are in the business of signing digital certificates to certify that those certs belong to the domains with which they're associated. Such promises are part of the chain of trust that allows internet users to visit, say, an online banking website and have some assurance that the website is legitimate. When CAs fail to police their certificates, or adequately secure their own systems, security problems may follow, as happened with DigiNotar a decade ago.

Mozilla, maker of Chrome rival Firefox, has been trying to decide whether Camerfirma's history of questionable certificate management practices – documented in a lengthy list – warrants banishing the Spanish company's certificates from its Root Store – the set of certificates Firefox recognizes as trustworthy by default.

Despite having documented 26 suspected or confirmed issues related to Camerfirma, Mozilla has yet to decide whether it will stop trusting the Spanish company's certificates.

Ben Wilson, CA program manager at Mozilla, said last week that Mozilla intends to continue discussing the issue to see whether Camerfirma's remediation plan will be enough to bring the firm back into compliance.

Although Camerfirma CTO Ramiro Muñoz has expressed willingness to address Mozilla's concerns, others, including Wayne Thayer, senior director of engineering at Fastly and former Mozilla CA Program Manager, have argued against being too lenient.

cookie

Firefox 85 crumbles cache-abusing supercookies with potent partitioning powers

READ MORE

"We have given Camerfirma the benefit of the doubt for too long and Mozilla can't continue to trust Camerfirma while they remediate these problems," wrote Thayer. "With all the documented issues and Camerfirma's response, that would represent an unacceptable ongoing risk to Mozilla's users. Distrust is the first step."

Andrew Ayer, founder of SSLMate, said much the same thing. "It's troubling that even at this stage, Camerfirma still doesn't seem to grasp the seriousness of their compliance problems," he wrote in a discussion post.

"Today, they are arguing that there was no security threat from a certificate issued for a domain without authorization because the subdomain in the certificate "does not exist."

In a message to The Register, Ayer elaborated on his concerns.

"In 2019, they issued a certificate for a domain that doesn't exist, which means they could not have possibly validated their authorization to issue the certificate," he said. "Not validating certificates is bad, because it means they might issue a rogue certificate for a real domain that is used to attack people, like in the DigiNotar incident."

Worse, still, he said, Camerfirma in 2017, in response to a different incident, had promised to put controls in place that would have prevented the 2019 problem. But the company didn't do so.

Filippo Valsorda, a cryptography and software engineer on Google's Go programming language team, also expressed reservations. "Arguing that a certificate doesn't present any risk if it's issued for a name that doesn't exist in DNS betrays a deep misunderstanding of the web platform, which the WebPKI serves," he wrote. "For example, an attacker in a privileged network position can fake a DNS response for that domain, and use it to set Secure cookies on the whole site."

Setting the bar

Unlike Mozilla, Google is no longer willing to wait for Camerfirma to get its act together.

"After full consideration of the information available, and in order to protect and safeguard Chrome users, certificates issued by AC Camerfirma SA will no longer be accepted in Chrome, beginning with Chrome 90," wrote Ryan Sleevi, a Google software engineer, in a message to the Mozilla security policy mailing list discussion.

Sleevi said this change is being built into the Chromium open-source project as part of a default build and offered no details about how non-Google Chromium browsers will implement this change.

Eric Mill, lead product manager for Google Chrome security, last Thursday said that Chrome will no longer accept those Camerfirma certificates that are "specifically" used for TLS server authentication for websites, including Qualified Website Authentication Certificates (QWACs) and certificates used to comply with the Revised Payment Services Directive (PSD2). However, that will not affect TLS client certificates or Qualified Certificates that are being used for digital signatures.

This change will become available for testing sometime around March 11, 2021, when Chrome 90 beta arrives. It will reach Chrome's stable channel in April.

Ayer also told us that he thought Mozilla should show more leadership here instead of taking more time to deliberate.

"Mozilla builds their brand around protecting individual users' security and privacy, and around the importance of community participation, but their delay with Camerfirma is putting individuals' security and privacy at risk, and they are ignoring the community response which has been overwhelmingly in favor of distrusting Camerfirma," he said. "Mozilla should be leading the industry here, but they are not."

Camerfirma did not immediately respond to a request for comment. ®

More about

TIP US OFF

Send us news


Other stories you might like