Chrome blocked bad certs after .gh / .sl / .as registry hijacks

This is not another Chrome version-number story. On October 6, 2026, Google’s Chrome Secure Web and Networking team published what Chrome did after attackers hijacked parts of three country-code top-level domains: .gh (Ghana), .sl (Sierra Leone), and .as (American Samoa).

If you use Chrome at home, the short version is simple: Chrome already blocked the unauthorized HTTPS certificates. Google says Chrome users do not need to take any action.

What happened, in plain language

A ccTLD is a country-code ending on a domain name (.gh, .sl, .as, and many others). The registry is the organization that runs that ending. Google’s post says these incidents did not involve a compromise of Google’s own systems. Attackers compromised third-party ccTLD registries instead.

During the hijacks, attackers:

Changed authoritative DNS records for domains under those endings
Obtained unauthorized HTTPS certificates for some Google domains and for domains belonging to other organizations

HTTPS certificates are how your browser decides a site’s lock icon and encrypted connection are trustworthy. If someone controls DNS for a name, they can often convince a certificate authority to issue a cert for that name, even when the real owner never asked for it. Google says it has no reason to believe the issuing CAs did anything wrong. The problem was the registry / DNS compromise, not a CA “going rogue.”

That combination (bad DNS plus a real-looking cert) is why browser vendors treat these events seriously. A visitor can land on a lookalike server that still shows a padlock.

What Chrome did

Google says Chrome immediately blocked the unauthorized certificates for Google properties via CRLSets (Chrome’s mechanism for pushing certificate blocklists to the browser). Chrome also worked with the issuing CAs so those certificates were revoked for clients other than Chrome.

After the first mitigation, Certificate Transparency log data showed more organizations believed to be hit by the same attacks. Chrome proactively blocked those certificates too, and Google says it reached out to impacted organizations where possible.

Bottom line for a normal Chrome user at home: your browser is supposed to refuse those bad certs automatically. You do not need a special update checklist for this incident beyond staying on a current Chrome build for everyday security.

If you also use Edge, Firefox, Safari, or Brave, keep those updated on their own schedules. Revocation and blocklists are not identical across every browser. Updating Chrome does not update Edge. Updating Edge does not update Chrome. For recent Chrome Stable jumps, see our Chrome 155.0.8059.39 security note. That article is about the October 6 version package. This one is about the registry-hijack response.

What this means for you (not a domain operator)

Most people reading this are not running a .gh, .sl, or .as domain. You are browsing the web. For that audience:

Prefer the official site you meant to visit. If a login page feels off, stop and check the address carefully.
Do not ignore brand-new certificate warnings. If Chrome refuses a connection after a block like this, that refusal is the feature working.
Keep Chrome (and your other browsers) current so you receive CRLSet and security updates.
You do not need to reinstall Chrome, clear all cookies, or “reset HTTPS” because of this blog post.

Google’s explicit guidance: Chrome users do not need to take any action to be protected.

Optional notes if you own a domain

Google’s post also talks to domain owners. That is optional reading for most home users. If you personally own domains (especially under .gh, .sl, or .as, or regional / parked names you forgot about), the useful habits are:

Watch Certificate Transparency for unexpected certificates on your names
Publish restrictive CAA records so only the CAs (and accounts) you intend can issue for your domains after DNS control is restored

CAA does not magically stop every attack during an active DNS hijack. It helps afterward, and it can reduce some issuance paths. Browser-side blocking is a backstop, not a substitute for owning your DNS and cert story.

If you only use a Gmail address and never registered a domain, skip this section and keep browsing.

Do this / don’t do that

Stay on a current Chrome build so CRLSets and normal security fixes keep landing
Treat unexpected certificate errors as a stop sign, not a “click through” moment
Update other browsers you actually use on their own About / store pages
If you own domains in the affected endings, review recent CT issuance when you have time

Don’t

Panic-reinstall Chrome or wipe your profile because of this post
Assume “Google got hacked.” Google says its systems were not the compromise point
Confuse this story with a Chrome 155 version bump. Different topic, same week
Download random “certificate fix” tools from third-party sites

Bottom line

Attackers compromised third-party .gh / .sl / .as ccTLD registries, changed DNS, and obtained unauthorized HTTPS certificates for some Google and other domains. Chrome blocked those certs with CRLSets and worked with CAs on revocation (Google’s October 6, 2026 post). For everyday Chrome users at home: no action required beyond normal updates. The padlock is only as good as the DNS and the certs behind it. This week, Chrome’s job was to refuse the bad ones for you.

Image: Google Chrome security art from the “Stronger with every update” post (blog.google).