Attackers Hijacked Three Country Registries to Get Certificates for Google Domains
Someone got into the systems behind three country-code domains and used that access to obtain HTTPS certificates for Google and YouTube addresses. Google disclosed the incident on October 6.
The affected registries are .gh (Ghana), .sl (Sierra Leone) and .as (American Samoa). Google says its own systems were not breached. The exposure came from the registries, which meant any site under those three endings was potentially at risk.
The danger is easy to explain. A valid certificate lets an attacker’s server present itself as the real site over an encrypted connection, so a visitor sees the padlock and has no reason to doubt it. The attacker could then read whatever the visitor sends.
How Google responded?
Chrome blocked the fraudulent certificates for Google’s own domains through CRLSets, the mechanism it uses to push out emergency blocks quickly. Google also worked with the certificate authorities (CAs) that issued them to get them revoked. That second step matters because it protects people on other browsers and apps, where Chrome’s block does not reach.
Google did not list the domains or say when the hijacks happened. It also did not publish dates for its own actions, only that it learned of the problem the week before its post and acted at once.
What the public logs show?
Certificate Transparency (CT) logs are the public record of every certificate a CA issues, so they offer an independent check. On October 7, The Hacker News searched two CT services, ctlogs.dev and Cert Spotter, and found 12 certificates issued between September 22 and 27.
They cover seven domains: google.com.gh, youtube.com.gh, google.sl, google.com.sl, youtube.sl, google.as and youtube.as. Let’s Encrypt issued 11 of the certificates and ZeroSSL issued one. All 12 are domain-validated, meaning the CA only checked that the applicant controlled the domain.
The timing was methodical, one registry at a time: .gh on September 22, .sl on September 25 and .as on September 27.
| # | Names on certificate | Issuer | First logged | Revoked |
|---|---|---|---|---|
| 1 | *.youtube.com.gh, youtube.com.gh | Let’s Encrypt | Sep 22, 11:03 | Sep 26, 02:41 |
| 2 | *.google.com.gh, google.com.gh | Let’s Encrypt | Sep 22, 11:59 | Sep 26, 02:41 |
| 3 | *.google.sl, google.sl | Let’s Encrypt | Sep 25, 04:36 | Oct 1, 19:36 |
| 4 | google.sl, www.google.sl | Let’s Encrypt | Sep 25, 04:36 | Oct 1, 19:36 |
| 5 | google.com.sl, www.google.com.sl | ZeroSSL | Sep 25, 04:51 | Sep 26, 14:56 |
| 6 | *.google.com.sl, google.com.sl | Let’s Encrypt | Sep 25, 04:51 | Oct 1, 19:36 |
| 7 | www.youtube.sl, youtube.sl | Let’s Encrypt | Sep 25, 06:06 | Oct 1, 19:36 |
| 8 | *.youtube.sl, youtube.sl | Let’s Encrypt | Sep 25, 06:07 | Oct 1, 19:36 |
| 9 | google.as, www.google.as | Let’s Encrypt | Sep 27, 03:33 | Oct 1, 19:18 |
| 10 | *.google.as, google.as | Let’s Encrypt | Sep 27, 03:43 | Oct 1, 19:18 |
| 11 | google.as, www.google.as | Let’s Encrypt | Sep 27, 04:17 | Oct 1, 19:18 |
| 12 | *.youtube.as, youtube.as | Let’s Encrypt | Sep 27, 04:37 | Oct 1, 19:18 |
By October 7, Cert Spotter showed all 12 as revoked. The two .gh certificates and the ZeroSSL certificate were revoked on September 26, and the remaining nine on October 1. The gap between a certificate first appearing in the logs and being revoked ranged from about a day and a half to nearly a week. The first .as certificate was logged roughly a day after the .gh ones were pulled.
In the records reviewed, which reach back to at least September 10, every other certificate for google.com.gh, google.sl and google.as came from Google Trust Services, Google’s own CA. That makes these 12 stand out.
Let’s Encrypt confirmed the issuance. Staff member Matthew McPherrin wrote on the CA’s community forum on October 7 that the certificates were issued and have been revoked.
The real number may be higher
Only a small set of Google and YouTube names was searched, so 12 should be treated as a minimum. Google said CT data also points to other organizations hit by the same attacks, including well-known global brands and widely used online services, but it did not name them. Chrome blocked those certificates too, and Google contacted the organizations where it could.
Google also admitted the limits of its own analysis. DNS hijacks are complex, the Chrome Secure Web and Networking Team wrote, and “we cannot guarantee that our analysis identified every affected domain.” It added that Chrome’s protection does not reliably cover users of other browsers.
What we still don’t know?
- Whether any of the certificates was actually used to impersonate a Google site or capture user data
- Who the attackers are
- How the three registries were compromised
- Whether the registries have since been secured
Why a domain check can be reused?
The attackers changed authoritative DNS records during the hijacks, and that is how they passed the CA’s control check. Google said it has no reason to think the CAs did anything wrong.
The rules do leave a window open, though. Under the CA/Browser Forum’s Baseline Requirements, a CA can reuse a completed domain check for up to 200 days, so an attacker who passed it during a hijack might request more certificates after the hijack ends. The Forum approved a schedule in April 2025 that cuts this to 100 days in March 2027 and 10 days in March 2029.
Let’s Encrypt, which issued 11 of the 12 certificates, said in December 2025 that it reuses a check for 30 days and plans to bring that down to 7 hours by 2028.
What domain owners should do?
Google gave two recommendations, and the CA rules provide a third.
- Watch CT logs for every domain you own, including parked domains and regional ccTLD names. Monitoring services send an alert when a certificate is issued. If you run anything under .gh, .sl or .as, check recent entries for certificates you did not request.
- Publish a strict CAA record. This DNS record lists the CAs allowed to issue for your domain, and CAs must check it first. Google suggests tying it to your own account at the CA, though that only works if the CA supports it.
- Report unexpected certificates to the issuing CA. Anyone can file a Certificate Problem Report, and the CA must investigate and share its first findings within 24 hours.
One caveat: a CAA record will not stop issuance while a DNS hijack is in progress. An attacker who can delete the record or insert a false one can still get a certificate, as the CAA standard itself notes. Its value comes after you regain control of DNS, when a strict record blocks any follow-up requests that rely on a reused domain check.
Chrome users need to do nothing. Domain owners, however, should not assume the browser will protect their visitors.
