- Google reports that attackers hijacked the .gh, .sl and .as country domains and obtained unauthorized HTTPS certificates for Google and other organizations' domains.
- Chrome blocked the certificates it found. Google says owners should not rely on the browser, and it cannot be sure it found every affected domain.
- Google urges domain owners to watch Certificate Transparency logs and publish restrictive CAA records, including for regional and parked domains.
A padlock in the browser does not show that the owner approved a connection. It shows that someone passed a test of control over the domain name. Google's report on three country domains shows what happens when the wrong party passes that test.
What Google reported
Google describes a run of domain takeovers in three country-code top-level domains, known as ccTLDs. They are .gh for Ghana, .sl for Sierra Leone and .as for American Samoa. Google says it learned of them the week before its October 6 post.
Google says its own systems were not breached. The weak point was the third-party operators of those country domains. Any name ending in .gh, .sl or .as was exposed.
The attackers changed authoritative DNS records. These records tell the internet where a domain points. The attackers then obtained HTTPS certificates that no owner had approved. The certificates covered several Google domains and domains of other organizations.
How a hijack becomes a valid certificate
A certificate authority (CA) issues a certificate only after the requester proves control of a domain. This proof is called domain control validation. It often relies on DNS or on a web response from the domain.
An attacker who controls the authoritative DNS can pass that test. The CA sees a correct answer and issues the certificate. Google says it has no reason to think the issuing CAs did anything wrong.
The lesson here is that HTTPS trust rests on DNS trust. DNS trust rests on registries that the domain owner does not run.
How Chrome responded
Google used CRLSets to block the bad certificates for its own properties in Chrome. A CRLSet is a list of revoked certificates that Chrome downloads and applies. Google also worked with the issuing CAs to revoke the certificates. That step helps clients other than Chrome.
Certificate Transparency (CT) logs are public records of certificates issued by trusted CAs. Google says these logs later pointed to additional organizations it believes were affected. It lists several leading global brands and widely used online services among them. Google has not confirmed the impact in each case. Chrome blocked those certificates too. Google contacted the organizations where it could.
Google says people using Chrome need not change anything.
Why Google says the browser is not enough
Google tells domain owners not to treat Chrome as their safety net. It gives two reasons.
First, DNS hijacks are complex. Google cannot be sure its analysis found every affected domain. Second, Chrome's blocks do not reliably cover people on other browsers.
The post leaves several questions open. It does not say how the registries were compromised. It does not say how long the hijacks lasted or how many domains were affected. It does not name the CAs that issued the certificates. Owners should keep those gaps in mind when judging their own exposure.
What Google asks domain owners to do
The first step is to watch CT logs. Every certificate Chrome trusts by default must be listed in a public log. A watcher therefore sees a new certificate for your name almost as it appears.
Google wants that watch list to be complete. It should include parked domains and regional ones, not only the main brand name.
The second step is to publish restrictive CAA records with account bindings. A CAA record is a DNS entry naming the CAs allowed to issue certificates for your domain.
Google notes that CAA cannot stop issuance while a hijack is under way. Its value comes after control of DNS is restored.
CAs may cache a completed validation check and reuse it later. A restrictive policy stops an attacker from using that stored result to obtain new certificates once the hijack ends. Limiting issuance to named accounts and validation methods closes that path.
Questions to put to your team
Ask for a full list of your domains, including regional and parked ones. Ask who receives an alert when an unexpected certificate appears in CT logs. Ask whether that person can be reached out of hours.
Ask whether your CAA records name specific CAs and accounts. Does your company operate a name under .gh, .sl or .as? Then have someone check the recent public certificate records for any issuance nobody on your side requested.
Ask which registry and DNS provider each domain depends on. In this incident, the registry level is where attackers got in. A weakness there can produce a certificate that browsers accept.
Chrome blocked the certificates it found, and Google says that may not be all of them. Its own advice is that the next line of defense should be one you run yourself.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: blog.google.
