What happened and how Google responded
Google said on October 6 that attackers compromised three country-code top-level domains — .gh (Ghana), .sl (Sierra Leone) and .as (American Samoa) — and obtained unauthorized HTTPS certificates for several Google domains. Google's own systems were not breached, but "any domain ending in .gh, .sl or .as was put at risk." Chrome blocked the unauthorized certificates through CRLSets, Google wrote, and the company worked with the issuing certificate authorities (CAs) to have the certificates revoked so other browsers and apps would also be protected.
Google said it learned of the hijacks the week before its October 6 post and "acted immediately," though it did not provide specific dates for the hijacks or its internal actions. It also said CT data pointed to other organizations that it believes were hit by the same attacks, including well-known global brands and widely used online services; Google did not name those organizations.
Certificate Transparency, CAs, and what the logs show
Public CT search services — specifically ctlogs.dev and Cert Spotter — were used to find the certificates. The Hacker News report found at least 12 certificates logged for seven domains. Eleven were issued by Let's Encrypt and one by ZeroSSL. The log entries were recorded on three days, one ccTLD at a time: .gh on September 22, .sl on September 25, and .as on September 27.
All 12 certificates were domain-validated certificates, which are issued after a CA verifies that the applicant controls the domain (for example, by requiring a DNS record). Google said the attackers changed authoritative DNS records during the hijacks and that it has "no reason to believe the CAs did anything wrong." Let's Encrypt staffer Matthew McPherrin confirmed on October 7: "Yes, certificates for Google and YouTube were issued, and have been revoked."
Cert Spotter's records showed all 12 certificates as revoked: two .gh certificates and the ZeroSSL certificate were revoked on September 26; the other nine were revoked on October 1. The shortest gap between a certificate's first CT log entry and its revocation was about a day and a half; the longest was nearly a week.
Audit-ready is a season. It shouldn't be.
Evidence in spreadsheets, controls drifting between audits, frameworks multiplying on flat headcount. Nubivance runs continuous compliance on Rapid7 Cyber GRC - SOC 2, HIPAA, ISO 27001, PCI, CMMC.
End the scrambleHow DNS control and CAA records factored in
Because CAs rely on domain-control checks, an attacker who can modify authoritative DNS records may pass those checks and obtain certificates. Google advised domain owners to publish a strict CAA DNS record naming which CAs are allowed to issue certificates for their domains and to tie that record to an account at the CA where supported.
The record can be bypassed during an active DNS hijack — an attacker who can remove or forge the CAA record could still get a certificate — but it matters once DNS control is restored because it blocks a CA from issuing future certificates except to the named CA. Google noted that CAs are allowed, under the Baseline Requirements, to reuse a completed domain check for later certificates for up to 200 days; that limit is scheduled to drop to 100 days in March 2027 and to 10 days in March 2029, per the CA/Browser Forum schedule approved in April 2025. Let's Encrypt said in December 2025 it reuses a domain check for 30 days and plans to cut that to 7 hours by 2028.
Google Public DNS returned a strict CAA record naming only pki.goog for each of the seven affected domains as of October 7. Each certificate found in public reporting can be looked up by its SHA-256 fingerprint in CT search services; the Hacker News story lists those fingerprints.
Google's guidance for domain owners and CAs' obligations
- Google urged domain owners to watch CT logs for every domain they own, including parked domains and regional ccTLD names, and to review any certificates they did not request.
- It recommended publishing a strict CAA record and tying that record to the owner's account at the CA where possible.
- Google also encouraged reporting any certificate a domain owner did not request to the issuing CA. Under the Baseline Requirements, a CA must investigate a Certificate Problem Report and report its first findings within 24 hours.
Google cautioned that because DNS hijacks are complex, "we cannot guarantee that our analysis identified every affected domain," and added that Chrome's blocks "do not reliably protect people who use other browsers." Chrome blocked certificates it found for other organizations and contacted those organizations where it could. Google also said Chrome users do not need to do anything.
How technologists, domain owners, and end users are affected
- Technologists and security teams: monitor CT logs and coordinate with CAs. The incident underscores the role of CT monitoring and emergency browser blocks (CRLSets) in responding to certificate misuse.
- Domain owners and enterprise procurement: review regional ccTLD holdings and parked names, publish strict CAA records, and be prepared to file Certificate Problem Reports with CAs if unauthorized certificates appear.
- End users: Chrome users received protections from blocked certificates in Chrome; users of other browsers and apps may not have the same immediate protection and remain reliant on CAs and domain owners to revoke certificates and restore DNS control.
Google did not say whether any of the certificates was used to impersonate a Google site or to read users' data, nor did it name the attackers, explain how the ccTLDs were compromised, or say whether the ccTLDs have been secured. The public record — CT logs, revocation timestamps, and the listed certificate fingerprints — provides investigators and domain owners concrete artifacts to follow up on.
