Google: ccTLD hijacks yielded rogue HTTPS certificates

Attackers who seized control of three country-code top-level domains used that position to obtain HTTPS certificates for several Google domains, as well as for domains belonging to other large organizations. Google disclosed the incidents on Tuesday.

The affected endings are .gh (Ghana), .sl (Sierra Leone) and .as (American Samoa). Country-code top-level domains, or ccTLDs, are the two-letter internet suffixes assigned to countries and territories. Day-to-day operation is often handled by third-party companies rather than by a government body. According to Google, the attackers compromised those third-party operators. That gave them leverage over every domain registered under the three endings, and they then changed the authoritative DNS records.

Authoritative DNS records are the official answer to the question of where a domain lives on the internet. Whoever controls them can redirect traffic and, in many cases, convince a certificate authority that they own the domain.

Google says its own systems were not breached

Google stressed that the attackers never got inside its infrastructure.

"These incidents did not involve a compromise of Google's systems," the company said.

It also cleared the organizations that issued the certificates. "Due to the nature of the attacks, we have no reason to believe the Certification Authorities (CAs) that issued the impacted certificates did anything wrong," Google added.

This is the uncomfortable part of the incident. Certificate authorities (CAs) issue certificates after checking that the requester controls the domain, a process known as domain control validation (DCV). If an attacker controls the DNS, those checks can pass even though the request is fraudulent. The CAs followed the process, and the process returned the wrong answer.

Google learned about the hijacks last week. It did not say how the registry operators were compromised, who carried out the attacks, or when the activity started.

How Chrome blocked the certificates

For the certificates covering its own properties, Google pushed blocks to Chrome through CRLSets. This is a list of revoked certificates that the browser downloads quietly in the background. It lets Google cut off bad certificates without waiting for a full browser release.

Google also worked with the issuing CAs to formally revoke the certificates. That step matters for anyone not using Chrome, because revocation by the CA reaches other browsers and clients too.

The company then turned to Certificate Transparency (CT) logs. These are public, append-only records of issued certificates, built so that domain owners and researchers can spot certificates they did not request. The CT data pointed to other organizations that Google believes were hit in the same campaign, including several large global brands and popular online services. Google did not name them. It blocked those certificates in Chrome as well and reached out to the affected organizations where it could.

"Chrome users do not need to take any action to be protected," Google wrote. As with routine browser security updates, keeping Chrome current ensures the latest protections are in place.

Limits of the response

Google was careful not to oversell the fix. It warned that blocking certificates in the browser should not be the only line of defense. Because DNS hijacks are complex, the company said, "we cannot guarantee that our analysis identified every affected domain."

It also pointed out that Chrome's interventions do not reliably protect people who use other browsers.

Going forward, Google said it will keep working with the wider community to limit the damage that DNS and routing compromises can cause.

"To keep our users safe, we are committed to long-term HTTPS ecosystem improvements, such as reducing certificate validity and DCV reuse, through the Chrome Root Program and the new Chrome Quantum-resistant Root Program," the company concluded.

The Bigger Picture

This incident shows how much of web security rests on DNS. A padlock in the address bar proves that a certificate was issued for a domain. It does not prove that the right party asked for it. When the registry layer above a domain is compromised, even well-run organizations like Google can have valid-looking certificates issued in their name without any breach of their own networks.

For defenders, the practical lesson is to watch CT logs for certificates covering their domains. This is how Google found the other victims, and organizations can do the same. Companies that rely on less-scrutinized ccTLDs for regional sites or short links should consider whether the operator behind that suffix deserves the same trust as their own infrastructure.

Google's reference to shorter certificate lifetimes and less DCV reuse suggests it sees long-lived validations as a way to extend the impact of hijacks like these. The new quantum-resistant root program also fits a broader move toward post-quantum cryptography, seen elsewhere in OpenSSH's post-quantum signatures.

It is worth watching whether the registry operators disclose how they were breached, whether the other affected brands come forward, and whether other browser vendors follow Chrome with their own blocks.