.gh Registry Hijack: What Google Confirmed & 5 Owner Checks

If you own a .gh website, the registry compromise put your domain at risk — but Google confirms its own systems were not breached, and it names no individual business whose website was taken over. On 6 October 2026 Google’s Chrome Secure Web and Networking Team confirmed registry hijacks affecting .gh, .sl and .as. Attackers modified authoritative DNS records and obtained unauthorised HTTPS certificates for Google domains and other organisations. Google states the incidents did not involve a compromise of Google’s systems; attackers compromised the third-party registries that run those namespaces. Chrome blocked the affected certificates, Google says Chrome users do not need to take any action to be protected, and the useful work for you now is verifying the accounts that control your own domains.

Three separate ideas get tangled up in this story: registry hijacking, certificate issuance, and an actual website hack. Keeping them apart is what prevents confusion. This article sets out what Google confirmed, what it explicitly did not say, and the five checks a Ghanaian business can run this week.

What Google confirmed

The account comes from Google’s own security blog, published 6 October 2026 by the Chrome Secure Web and Networking Team. Its key statements are these:

• Google became aware of a series of domain hijacks in the .gh (Ghana), .sl (Sierra Leone) and .as (American Samoa) country-code top-level namespaces.
• The incidents did not involve a compromise of Google’s systems. Attackers compromised the third-party registries that run those namespaces.
• During the hijacks, attackers modified authoritative DNS records and obtained unauthorised HTTPS certificates covering several Google domains, as well as domains belonging to other organisations.
• Google has no reason to believe the certification authorities that issued the impacted certificates did anything wrong.
• Chrome blocked the unauthorised certificates for Google properties using CRLSets, and Google worked with the issuing authorities to have them revoked so that people using browsers other than Chrome are protected too.
• Chrome used CT logs to find further affected organisations and blocked those certificates.
• Chrome users do not need to take any action to be protected.

Google states the hijacks put any domain ending in .gh, .sl or .as at risk. This describes exposure: the registry control that every domain in those namespaces depends on was in the wrong hands. Google does not report that every site was compromised, and it names no individual business whose website was taken over.

Three different things, and only two of them happened

Most of the confusion around a story like this comes from treating three separate events as one.

What happened	What it actually means	Confirmed by Google?
Registry compromise	The ccTLD operator was compromised. The organisation that runs the .gh, .sl or .as namespace was in the wrong hands.	Yes. Google states that attackers compromised the third-party ccTLDs.
Authoritative DNS modification	DNS records for your domain were changed. Visitors are sent somewhere else; your hosting and files are untouched.	Yes. Google states that attackers modified authoritative DNS records.
Unauthorised certificate issuance	An authority that follows its own rules issued a valid HTTPS certificate for a domain it should not have. The padlock is genuine and the browser is behaving correctly. Google says it has no reason to believe the issuing authorities did anything wrong.	Yes. Google states that attackers obtained unauthorised HTTPS certificates.
Website, hosting or server compromise	Your site or server was actually hacked. Content is defaced, a CMS password is stolen or reused, or files you did not write appear on the server.	No. Nothing in Google’s account describes this.

Why Chrome’s response is a safety net, not a fix

In the same post Google says that browser-side intervention should not be relied on to protect your users, that it cannot guarantee its analysis identified every affected domain, and that Chrome’s interventions do not reliably protect people using other browsers. Google responded by working with the issuing authorities to revoke the certificates properly, rather than relying on the browser block alone.

Chromium documents CRLSets as “the primary means by which Chrome quickly blocks certificates in emergency situations” (source). The same page notes that Chrome does not generally perform online revocation checks during ordinary browsing.

What Certificate Transparency gives you, and what it does not

Certificate Transparency (CT) is an append-only public ledger of certificates. Certificates and precertificates are submitted to independent public logs, which return a signed certificate timestamp, and browsers require that proof before trusting a certificate. Because the logs are append-only, entries cannot quietly be deleted or rewritten, and anyone can query them.

Chrome used CT log data after its first response to find further organisations affected by the same attacks, which is how Google’s own account describes the list of blocked certificates growing.

For domain owners, CT is a monitoring tool. CT monitors give a near real-time alert when a certificate is issued for the domains you subscribe them to, and the CT project publishes a list of services, including free search interfaces such as crt.sh. Google’s advice is explicit: cover your entire domain portfolio, including parked and regional properties, and if you operate a .gh, .sl or .as domain, review recent log entries for unexpected issuance.

The limitation to keep in mind: CT records only that a certificate was issued. It does not tell you the site behind it is trustworthy, it stops nothing from being issued, and a monitor alert is a prompt to investigate rather than proof of an attack. It is a record to check, not a verdict.

What CAA can and cannot do

The other thing Google recommends is publishing restrictive CAA records. RFC 8659 defines the Certification Authority Authorization DNS record, which lets a domain holder specify which certification authorities are authorised to issue for that domain. A compliant authority must check for the record and must not issue unless the request is consistent with it.

Google is precise about its limits. CAA cannot prevent certificate issuance during an active DNS hijack. What it does provide is a critical safeguard after DNS control is restored, because authorities are permitted to cache and reuse completed domain-control validation for later issuance, so a restored restrictive CAA policy stops an attacker reusing that cached state once the hijack ends.

Limits from RFC 8659

• CAA works only because authorities observe it. Its effectiveness as an access control depends on issuers honouring the constraints.
• CAA does not prevent mis-issue by an authority you have already authorised.
• Suppressing a CAA record or inserting a bogus one could enable an attacker to obtain a certificate from an issuer that was not authorised.

Finer restrictions in RFC 8657

RFC 8657 adds finer restrictions, naming specific authority accounts and specific domain-validation methods. Its limitations are stated plainly, and they are why we are not handing you a record to paste:

• The extra restrictions bind only authorities that implement and recognise the parameters. The RFC says this gives no additional security over plain CAA as concerns any other authority, and that another authority’s capacity to issue for your domain is completely unchanged.
• They add no protection against an attacker able to intercept all of an authority’s validation traffic, unless your domain is signed with DNSSEC and the authority validates CAA through a trusted DNSSEC-validating resolver.

• They do not protect subdomains where control of DNS has been delegated to somebody else.
• Section 5.8 warns that because these parameters express restrictive policies, misconfiguring them can block legitimate certificate renewals and cause an outage.

Treat CAA as a decision to make with whoever manages your DNS and your certificate authority — not as a line to copy from an article. Ask them whether they support the account and validation-method restrictions, and what would happen to your own renewals if the setting were wrong.

Five checks to run this week

1. Ask your registrar and your DNS host to confirm, in writing, that nothing about your records has changed without authorisation. Ask them to show who made changes and when, and to turn on any change notifications they offer.
2. Search Certificate Transparency for every domain you own — see the “What Certificate Transparency gives you” section above for how.
3. Audit the accounts: the registrar account, the DNS host account, the hosting control panel, and the email address on the domain. Each should be controlled by named people at your business, protected by strong, unique passwords and multi-factor authentication.
4. Establish who renews the domain and who renews or installs the certificate, and put those renewal dates somewhere the business will actually see them. An expired certificate is an outage with no attacker involved.
5. Ask whoever maintains the site to confirm that the hosting account was not accessed, and that no administrator, FTP or database user has appeared that nobody on your team recognises.

Questions to ask whoever looks after your website

These are the questions we would put to anyone responsible for a domain:

• Who holds the registrar account and the DNS account, and who else has access to either?
• Which authority issues your certificate, and does it support account and validation-method restrictions?
• If your DNS records were changed by somebody else, how would you find out today, not eventually?
• What does the maintenance arrangement cover after launch, and who is contacted if an account is accessed?

The domain and hosting are registered in your name, so you keep ownership and control. They are not sold to you as a separate package, and renewal dates and recurring costs are explained before work begins. If you want those details written down for your own domain before agreeing any scope, see our web design services or get in touch. For the broader regulatory context, see Ghana’s Cyber Security Authority says cyber risk is a business risk.