Hackers Hijacked Three Country Domains to Forge Google Certificates: What It Means for You

Also on CyberFence: the free CyberFence security tools · run a free DNS leak test .

On October 6, Google disclosed that attackers took over the internet addresses of three countries and used that control to obtain real, trusted HTTPS certificates for several Google domains and for other large brands. The affected endings are .gh (Ghana), .sl (Sierra Leone), and .as (American Samoa). Google says its own systems were not breached, and says Chrome users do not need to take any action. Even so, the attack shows how a padlock in your browser can be earned by the wrong party, and it is worth understanding what a VPN can and cannot do about that.

What Happened

According to Google's Chrome security team, the company became aware of a series of domain hijacks in the three country-code top-level domains the week before. The attackers compromised the third-party operators of those domains, which put any domain ending in .gh, .sl, or .as at risk.

Google writes that during these hijacks, the attackers "modified authoritative DNS records and obtained unauthorized HTTPS certificates covering several Google domains, as well as domains belonging to other organizations." Google also says it has no reason to believe the certificate authorities that issued the certificates did anything wrong.

Here is how the response unfolded, per Google:

• Chrome blocked the unauthorized certificates for Google properties through its CRLSets, a list Chrome downloads in the background to block bad certificates.
• Google worked with the issuing certificate authorities to revoke the certificates, which protects people who use other browsers and apps.
• Public Certificate Transparency logs revealed more organizations, including "several leading global brands and widely used online services," and Google blocked those certificates in Chrome too.

The story was also covered by Ars Technica and BleepingComputer.

The Terms, in Plain English

• DNS: the internet's address book. It turns a name like a website address into the numbers computers use to find it.
• Authoritative DNS records: the official entries for a domain, kept by whoever runs it. Change those, and you change where the domain points.
• Certificate authority: an organization browsers trust to issue the certificates behind the padlock.
• Certificate Transparency: public logs where every trusted certificate must be listed, which lets anyone spot a certificate they did not request.
• Revocation: cancelling a certificate before it expires, so browsers and apps stop trusting it.

Why a Valid Certificate Is So Dangerous

When your browser shows a padlock, it means the connection is encrypted and that the site holds a certificate a trusted authority issued for that name. Authorities issue certificates after checking that the requester controls the domain, often by asking them to publish a specific value in the domain's DNS records. As BleepingComputer explains, attackers who can change those DNS records can pass that check.

That is why this matters. The Register describes the result this way: the attacker controls the traffic routing through DNS and holds the private key for the unauthorized certificate, so they can potentially intercept or modify data sent to the impersonated site, or use the trusted brand to spread malware or phishing. In plain terms, a fake site could have looked exactly like the real one, with no browser warning.

What We Still Do Not Know

It is important to separate what is confirmed from what is not. Based on the sources above:

• Google has not said who is behind the attacks.
• The specific Google domains and the other affected organizations have not been named publicly.
• No count of affected users has been published.
• Google says it "cannot guarantee that our analysis identified every affected domain."

We will not guess beyond that. If you see claims online about who was targeted or how many people were affected, check whether they link back to Google's post.

Is Chrome's Protection Enough?

For Chrome users, Google says no action is needed. But the same post adds a warning: browser-side blocking "should not be relied on," and Chrome's interventions do not reliably protect people who use other browsers. Revocation by the certificate authorities helps other clients, but it takes time to spread. The practical takeaway is to keep every browser and device updated, not just Chrome.

What a VPN Can and Cannot Do Here

This is where honesty matters, because many VPN articles will overstate it.

What a VPN does not do: it would not have stopped this attack. The hijack happened in the domains' own DNS records, at the source. A VPN protects the path between your device and the VPN server. It cannot know that a normally trusted domain has been taken over upstream, and a DNS blocklist like Web Shield only blocks domains already known to be malicious.

What a VPN does do: it closes a different, cheaper version of the same trick. On public Wi-Fi, an attacker on the same network can tamper with the DNS answers your device receives and send you to a fake site. CyberFence routes DNS queries through the encrypted tunnel to its own resolver, so the local network cannot alter them. We explain the mechanics in What Is a DNS Leak and How DNS Filtering Works, and the wider risks in Can You Get Hacked on Public Wi-Fi?

Both attacks aim at the same result: sending you to a site that is not what it claims to be. The defenses are layered, and each layer covers a different gap.

Five Steps for Everyday Users

1. Keep your browser and operating system updated. Certificate blocklists and revocation lists reach you through updates.
2. Do not rely on the padlock alone. It tells you the connection is encrypted, not that the site is honest. Be cautious with links from email and messages, and type bank addresses yourself.
3. Use a unique password for every account, plus two-step sign-in. If a password is captured, a second step and unique passwords limit the damage. See how credential stuffing works.
4. Turn on a VPN with built-in DNS protection on networks you do not control. Hotel, airport, and café Wi-Fi are where local DNS tampering happens.
5. Watch for leaks tied to your email. CyberFence Breach Monitor, a separate product, alerts you when your email address appears in a new breach, so you can change the password quickly. Learn more in What Is a Breach Monitor?

For Business and Domain Owners

Google's guidance is aimed at organizations, and small businesses with websites should read it. Two steps stand out:

• Monitor Certificate Transparency logs. Every certificate Chrome trusts by default must be listed in public logs, so monitoring them gives you a near real-time alert when a certificate is issued for your domains. Include parked and regional domains. If you hold a domain ending in .gh, .sl, or .as, review recent entries for anything unexpected.
• Publish restrictive CAA records. These DNS records say which certificate authorities may issue certificates for your domain. Google notes they cannot stop issuance during an active DNS hijack, but they help after you regain control by preventing an attacker from reusing cached validation to mint new certificates.

If your staff work from hotels, airports, and homes, the local-network side matters too. Our guide on VPNs for small business remote teams covers how to cover everyone consistently.

The Bottom Line

This incident was caught, the certificates were blocked, and Google says Chrome users are protected. It is still a useful reminder that the padlock is a promise about encryption, not about honesty, and that security works in layers. Keep your software updated, use unique passwords with two-step sign-in, and use a VPN with DNS protection on any network you do not control.

Want to go deeper? Read our free privacy and security tools , the CyberFence DNS leak test , or the CyberFence WebRTC leak checker .