Control of the DNS records under three country-code domains, .gh for Ghana, .as for American Samoa and .sl for Sierra Leone, was enough to get unauthorized HTTPS certificates issued for several Google domains. Google’s Chrome Secure Web and Networking Team laid out the episode in a post dated Oct. 6, 2026, titled “Chrome’s Response to Recent ccTLD Registry Hijacks,” and said its own systems were not compromised.
The certificates were real in the sense that matters: issued by public certificate authorities that checked who controlled the DNS, and therefore accepted by browsers until they were revoked or blocked.
Authoritative DNS, domain validation and the three registries
According to Google’s post, attackers compromised the third-party country-code top-level domains and modified authoritative DNS records. Certificate authorities commonly prove that a requester owns a domain by asking for a DNS record containing a random value. Anyone who can edit the authoritative DNS can publish that value, so the check passes without the real owner ever knowing about the request.
Google says any domain ending in .gh, .sl or .as was at risk during the incident. The post does not specify whether the direct targets were registries, registry operators or individual domains, and it does not give the hijack dates, the number of certificates issued, the particular Google domains involved or the identity of the attackers. BleepingComputer’s Bill Toulas reports the same gaps and adds that the issuing certificate authorities are unnamed, with Google stating it has no reason to believe they acted improperly given the nature of the attacks.
The three suffixes are country-code top-level domains, the two-letter endings that each territory or nation runs through its own registry arrangements. That structure is why the incident is described as a ccTLD event rather than as a failure at any single certificate authority: what changed was the DNS data that certificate authorities consult, not the authorities’ own issuing systems. Any website under .gh, .as or .sl sat in the affected namespace, which is why Google’s guidance to domain owners names those three suffixes specifically. Google adds that the other organizations whose certificates turned up in the logs included brands and services outside its own portfolio, so the exposure reached well past the company that published the account.
Revocation, CRLSets and the Certificate Transparency sweep
Chrome blocked the unauthorized certificates for Google properties using CRLSets. The Chromium project describes a CRLSet as “the primary means by which Chrome quickly blocks certificates in emergency situations,” a pushed list that stands in for online revocation checks, which Chrome generally does not perform. The project says entries are drawn from certificate revocation lists disclosed to the Common CA Database and, for intermediate certificates, lists discovered through Certificate Transparency, fetched at most once every few hours. Google also worked with the issuing authorities to revoke the certificates, a step it notes protects software other than Chrome.
The wider net came from Certificate Transparency, the public append-only logs in which issued certificates are recorded and which independent monitors watch for suspicious entries. Reviewing that data, Google found unauthorized certificates for other organizations too, including what its post calls “several leading global brands and widely used online services.” Chrome blocked those certificates proactively and Google contacted the affected organizations where it could. It does not name them.
Google says Chrome users need to take no action, and also says it cannot guarantee that its analysis found every affected domain. CRLSets protect only Chrome, and the post states plainly that browser-side intervention is not a reliable safeguard for people using other software.
CAA records and the limits of domain-owner defences
The advice Google directs at domain owners has two parts. The first is to watch Certificate Transparency logs across an entire portfolio, parked domains and regional country-code properties included, and anyone operating a .gh, .sl or .as domain is told to review recent entries for unexpected issuance. The second is to publish restrictive CAA records, the DNS entries defined in RFC 8659 that name which certificate authorities may issue for a domain, and to bind them to specific accounts under RFC 8657.
The post is candid about what CAA cannot do. A CAA record cannot stop issuance while a DNS hijack is under way, because the attacker controls the very records that hold it. Its value comes afterward: once DNS control is restored, tight CAA settings with account bindings stop an intruder from reusing cached domain-control validation to mint fresh certificates.
Google also points to longer-term changes, namely shorter certificate lifetimes and shorter reuse periods for domain validation under CA/Browser Forum ballot SC-081v3, which would narrow the window in which a stolen validation can be exploited. The record Google published leaves open how many certificates were issued and which Google hostnames they covered, and neither the post nor the BleepingComputer report supplies a count.
This article was produced with the assistance of AI and reviewed by Morning Overview editors prior to publication.
More from Morning Overview
- NOAA now gives this winter a 75% chance of the strongest El Nino since 1950
- Doctors warn a silent liver disease now affects one in three American adults
- The FBI told the rest of ShinyHunters to surrender after a 24-year-old was arrested
- Two passengers died at an Ohio toll plaza, and the NTSB now wants the cash lanes shut
