Someone Faked the Padlock: What the .gh, .sl and .as Domain Hijacks Mean for Your Website
On 6 October 2026, Google’s Chrome team published a short post about a domain hijack affecting three country-code endings: .gh (Ghana), .sl (Sierra Leone) and .as (American Samoa). The attackers used that control to get HTTPS certificates for several Google domains and for other organizations. Ars Technica covered it the same day.
Most security stories I’ve written here lately had AI in the middle, from ENISA testing Mythos 5 and GPT-6 Astra to CLOSEDQUORUM, the malware that lets AI models vote on its next move. This one is older plumbing: DNS and certificates. My day job sits close to network detection and response, and plumbing problems are the ones that worry me most, because everything above them trusts them.
What Google says happened
According to Google, it became aware “last week” of a series of hijacks in these country-code top-level domains (ccTLDs). Google says its own systems were not compromised. The attackers compromised the third-party ccTLDs, which put any domain ending in .gh, .sl or .as at risk.
The attackers then changed authoritative DNS records and obtained unauthorized HTTPS certificates. Google says it has “no reason to believe” the certificate authorities (CAs) that issued them did anything wrong.
That is the uncomfortable part. Ars Technica explains that control of the registries let the attackers pass the checks CAs use to confirm an applicant controls a domain. The CA asked a fair question, and for a while the attacker was the one answering it.
What Chrome did, and the limits Google admits
Google says it blocked the unauthorized certificates for Google properties in Chrome through CRLSets, a blocklist Google pushes to Chrome automatically. It also worked with the issuing CAs to get them revoked, to protect people using software other than Chrome. Certificate Transparency (CT) log data then showed more organizations hit by the same attacks, including “several leading global brands and widely used online services.” Chrome blocked those too (Google).
For regular users, Google’s words are: “Chrome users do not need to take any action to be protected.”
Google is open about the limits. It says browser-side intervention “should not be relied on to protect your users,” and: “we cannot guarantee that our analysis identified every affected domain, nor do Chrome interventions reliably protect non-Chrome users” (Google).
Ars notes that Google did not name its affected domains or the other organizations, and that the number of unauthorized certificates isn’t clear.
Why the padlock can’t catch a domain hijack
The padlock means your connection is encrypted to someone holding a valid certificate for that name. It can’t tell you whether they should have been given it.
Most of us in India running a small blog or shop on a .com or .in rarely think about who runs the registry above us (for .in, that’s NIXI). We can’t secure that layer ourselves, but we can find out fast when a surprise certificate appears, and make new ones harder to get.
What to do if you own a domain
- Watch Certificate Transparency logs. Google notes that certificates Chrome trusts by default must appear in public CT logs, so watching them gives a near real-time alarm. Search your domain on crt.sh, or set up email alerts with Cert Spotter. Include parked domains. If you have anything under .gh, .sl or .as, Google asks you to review recent entries now.
- Publish a restrictive CAA record. CAA is a DNS record naming which CAs may issue certificates for your domain. If you only use Let’s Encrypt, it looks like
example.com. CAA 0 issue "letsencrypt.org". Google recommends also binding it to your ACME account where your CA supports that. CAA can’t stop issuance during an active hijack, Google says, but it helps afterwards: CAs may reuse earlier domain checks, and a strict policy stops an attacker from using that leftover validation once you have DNS control back. - Lock down your registrar account. Turn on two-factor authentication, keep transfer lock on, and ask whether registry lock is available for domains that really matter. This won’t fix a compromised registry, but it shuts the more common door of a stolen registrar login.
- Know what normal looks like. Note which CA issues your certificates today, so an unfamiliar issuer on crt.sh stands out.
If you only browse the web, keep the usual habits on any browser: accept updates, and be careful with login pages reached from links.
My takeaway
Google says it is committed to longer-term fixes, such as shorter certificate validity and less reuse of domain checks, through the Chrome Root Program and its new Chrome Quantum-resistant Root Program (Google).
Your part is quicker. Search your domain on crt.sh today, check that you recognise every recent certificate, and add a CAA record if you don’t have one.
Leave a comment