Hackers Hijack .gh, .sl and .as Registry to Obtain Unauthorized HTTPS Certificates

Hackers compromised the .gh, .sl and .as country-code domain registries and used their access to obtain unauthorized HTTPS certificates for Google and other organizations. Chrome blocked the identified certificates automatically, while Google worked with certificate authorities to revoke those covering its properties.

In its October 6 disclosure, Google said it learned of the attacks the previous week. The affected domain endings belong to Ghana, Sierra Leone and American Samoa. The compromise put any domain using these endings at risk, but Google did not say every domain was hijacked.

Google stressed that its own systems were not breached. It also said there was no reason to believe the certificate authorities that issued the affected certificates had done anything wrong. The attackers instead targeted the third-party domain infrastructure on which certificate checks depend.

How DNS Hijacking Enabled Certificates

The attackers changed authoritative DNS records, which provide the official answers for domain lookups. Control over these records can let an attacker appear to control a domain when a certificate authority checks whether a certificate request is valid.

This process, called domain control validation, proves control rather than identifying the rightful business owner. For example, a certificate authority may ask the requester to publish a specific DNS record. Someone controlling the domain’s DNS can complete that check without permission from its owner.

An unauthorized HTTPS certificate can help attackers impersonate a trusted website if they can also direct users to their servers. Encryption alone does not solve that problem: a connection can be encrypted while reaching the wrong party. Google’s disclosure did not establish whether the certificates were used to intercept traffic.

Google has not publicly named the attackers, explained how they first gained access, or provided a complete list of affected domains and certificates. Those gaps leave the full scope of the incidents unclear.

Chrome Blocks Identified Certificates

Google first blocked unauthorized certificates for its domains through CRLSets, Chrome’s system for quickly blocking certificates during security emergencies. It also contacted the issuing authorities to arrange revocation, extending protection beyond Chrome where other clients enforce certificate revocation.

Further checks of Certificate Transparency logs uncovered certificates linked to other organizations, including major brands and widely used services. Google blocked those certificates in Chrome and alerted affected organizations where possible. Chrome users do not need to take action to receive this protection.

However, Google warned that its investigation might not have found every affected domain. Browser blocking should therefore not replace domain-owner checks, and Chrome’s measures do not reliably protect people using other browsers or applications.

Organizations should monitor Certificate Transparency logs across their entire domain portfolio, including parked domains and regional websites. Owners of .gh, .sl, and .as domains should review recent entries for certificates they did not request. CybersecurityNews’ coverage of certificate monitoring tools explains how alerts can flag suspicious issuance.

Google also recommends restrictive Certification Authority Authorization records, including approved ACME accounts and validation methods. These cannot prevent issuance during an active DNS hijack, but can stop attackers reusing cached validation after control returns. Longer-term changes include shorter certificate lifetimes and reduced validation reuse, alongside developments covered in Chrome’s certificate security improvements.