Unauthorized HTTPS Certificates Issued via Compromised .gh, .sl, and .as Registries
Attackers hijacked three ccTLD registries to obtain fraudulent certificates for Google domains, though Google infrastructure remained secure.
Key points
- Attackers compromised .gh, .sl, and .as ccTLD registries to issue unauthorized HTTPS certificates.
- The incident involved modifying authoritative DNS records via breached third-party operators.
- Google confirmed its own systems were not breached; only domains within these ccTLDs are at risk.
On 6 October, Google disclosed that attackers had obtained unauthorised HTTPS certificates for several of its domains. This was achieved by compromising the registries for three country-code top-level domains (ccTLDs): .gh (Ghana), .sl (Sierra Leone), and .as (American Samoa).
What happened
According to reports from The Hacker News and BleepingComputer, threat actors targeted the operators of these ccTLDs rather than Google directly. By compromising these third-party registry operators, the attackers were able to modify authoritative DNS records. This manipulation allowed them to request and obtain HTTPS certificates for Google domains that ended in .gh, .sl, or .as.
Infosecurity Magazine confirmed the scope of the hijack, noting the specific ccTLDs involved. Google stated that its own core systems were not breached during this incident. The vulnerability lay in the external registry infrastructure, which the attackers exploited to pose as legitimate sites over encrypted connections.
Why it matters
For organisations, this incident highlights the fragility of the web’s trust model when third-party infrastructure is compromised. Although Google’s internal systems remained secure, the ability to issue valid certificates for its domains could enable sophisticated man-in-the-middle attacks. Any domain ending in the affected ccTLDs was placed at risk. This means that users visiting Google services hosted on these specific domain extensions could have been exposed to fraud or data theft, as the attacker could pose as the real site. It underscores the operational risk associated with relying on external ccTLD operators for critical internet infrastructure.
Next steps
- Verify the integrity of SSL certificates for any domains hosted under .gh, .sl, or .as.
- Monitor DNS logs for unauthorised changes to authoritative records.
- Review access controls for any third-party registry management tools.
- Ensure certificate pinning is implemented for critical internal services.
What to do and how to stay safe: Google
- Inspect certificate chains for any services using the affected ccTLDs to ensure they match expected issuers.
- Monitor network traffic for unusual certificate errors or unexpected redirects on these domains.
- Contact your certificate authority to verify no unauthorised certificates were issued for your organisation’s domains.
- Once the vendor provides an update, apply patches to any systems that manage DNS or certificate requests.
Step-by-step guide: How to Prevent Account Takeover: The Technical Controls That Actually Work
General security guidance from the Packet Tribune newsroom. It is not confirmed advice from the organisations named in this story.
Frequently asked questions
Did attackers breach Google’s internal systems?
No, Google confirmed that its own systems were not breached; the attack targeted external ccTLD registries.
Which domains are affected by this incident?
Domains ending in .gh (Ghana), .sl (Sierra Leone), and .as (American Samoa) were at risk.
How did the attackers obtain the certificates?
They compromised third-party registry operators and modified authoritative DNS records to request the certificates.
