Google's Chrome security team disclosed on October 6, 2026 that in the previous week it had become aware of a series of domain hijacks in the .gh (Ghana), .sl (Sierra Leone) and .as (American Samoa) country-code top-level domains. Google stresses that its own systems were not compromised: the attackers compromised the third-party ccTLDs, putting every domain ending in those suffixes at risk. During the hijacks they modified authoritative DNS records and obtained unauthorized HTTPS certificates covering several Google domains as well as domains belonging to other organizations. Google says that, given the nature of the attacks, it has no reason to believe the CAs that issued the certificates did anything wrong: with the DNS under the attackers' control, domain validation passes.

What Google Did

  • It immediately blocked the unauthorized certificates for Google properties in Chrome via CRLSets, and worked with the issuing CAs to get them revoked, protecting clients other than Chrome.
  • Certificate Transparency (CT) log data then revealed further organizations, including several leading global brands and widely used online services, believed to have been hit by the same attacks; Google blocked those certificates in Chrome as well and alerted the organizations where it could.
  • Chrome users need to do nothing. But Google is blunt that browser-side intervention should not be relied on: it cannot guarantee it found every affected domain, and Chrome's interventions do not reliably protect people using other browsers.

Google did not publish how many certificates were involved or which CAs issued them. When we queried public CT logs on October 12, we found certificates issued by Let's Encrypt between September 22 and 27 for domains including youtube.com.gh, google.sl, youtube.sl and youtube.as, revoked between September 26 and October 1; the other certificates we saw for those domains in the same period were issued by Google's own Google Trust Services. That is the nature of automated domain validation: whoever controls the DNS can obtain a certificate by the book.

Two Things Site Owners Can Do

  • Monitor Certificate Transparency continuously. Every certificate trusted by default must be logged publicly, so CT monitoring gives you a near real-time alert whenever a certificate is issued for your domains. Google specifically asks owners to cover their entire domain portfolio, including parked and regional country-code domains.
  • Publish restrictive CAA records with ACME account binding. CAA is a DNS record that declares which CAs may issue certificates for your domain. Google puts it precisely: CAA cannot stop issuance during an active hijack, but it is a critical safeguard once you regain control of your DNS — CAs may cache and reuse completed domain validations, and a CAA policy that limits issuance to specific accounts and validation methods stops an attacker from using that cached validation to mint new certificates after the hijack ends.

Setting It Up on Your Own Domain

Let's Encrypt's CAA documentation (updated October 4) explains two parameters. accounturi restricts requests to one ACME account — in the documentation's words, it can ensure that "someone who temporarily hijacks your domain, but doesn't have access to your ACME Account key, can't issue malicious certificates". validationmethods restricts the validation methods (http-01, dns-01, tls-alpn-01). A record that allows only Let's Encrypt, and only your own account, looks roughly like this:

example.com. CAA 0 issue "letsencrypt.org;accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/YOUR_ACCOUNT_ID"

You can find the account URL in your ACME client's account details (with certbot, certbot show_account). Note that CAA records are additive — if any one record allows a CA to issue, it can — so remove old, looser records. Under CA/Browser Forum ballot SC098v2, every CA must process these two parameters from March 15, 2027. For adding DNS records, see pointing a domain to your VPS: a DNS primer, or speeding up and protecting your VPS site with Cloudflare if Cloudflare hosts your DNS; for the change in certificate lifetimes, see our article on Let's Encrypt's 64-day certificates.