Google says the registries for the .gh, .sl, and .as country-code domains were hijacked, allowing attackers to alter authoritative DNS and obtain unauthorized HTTPS certificates for several Google and YouTube domains as well as domains belonging to other organizations. Google's systems were not breached, but the incident shows that the HTTPS padlock alone cannot prove a website is genuine when DNS or a registry is compromised.
According to an October 6, 2026 notice from the Chrome Secure Web and Networking Team, the hijacks affected the country-code namespaces of Ghana (.gh), Sierra Leone (.sl), and American Samoa (.as). Google learned of the incidents the previous week and immediately added the unauthorized certificates to CRLSets so Chrome would block them automatically.
A Valid Certificate Can Still Serve a Hijacked Domain
During domain-validated certificate issuance, a certificate authority (CA) checks whether the applicant controls the domain. Once attackers can alter authoritative DNS records, they can pass that check and obtain a browser-trusted certificate without compromising the CA itself.
Google emphasized that it had no reason to believe the CAs involved had acted improperly. The failure occurred in third-party ccTLD infrastructure: temporary control of DNS created evidence of domain control that was fraudulent yet appeared valid to certificate-issuance systems.
At Least 12 Certificates Appeared in Transparency Logs
The Hacker News reviewed Certificate Transparency (CT) data and identified at least 12 certificates for seven Google and YouTube domains logged between September 22 and 27. Let's Encrypt issued 11 and ZeroSSL issued one. The names included google.com.gh, google.sl, google.as, and several Google and YouTube variants under the three ccTLDs.
By October 7, all 12 identified certificates had been revoked. The interval between their first appearance in CT and revocation ranged from roughly a day and a half to nearly a week. Google has not disclosed evidence that the certificates were used to steal data, nor has it identified the attackers or explained how the three registries were compromised.
Chrome Blocked the Certificates, but the Risk Extended Beyond Google
After the initial mitigation, CT data indicated that other organizations, including major global brands and widely used online services, may also have been affected. Google proactively blocked additional suspicious certificates in Chrome and contacted organizations it could identify.
Chrome users do not need to take any action to receive this protection. Google warned, however, that browser-side measures may not identify every affected domain and cannot reliably protect users of other browsers or applications.
What Should Domain Owners Do?
- Monitor Certificate Transparency: cover the entire domain portfolio, including parked and regional domains, to receive near-real-time alerts when new certificates are issued.
- Review .gh, .sl, and .as domains immediately: compare recently issued certificates against the organization's approved inventory.
- Publish restrictive CAA records: specify which CAs may issue certificates and, where supported, bind issuance to a particular ACME account and validation method.
- Report unknown certificates: submit a Certificate Problem Report to the issuing CA to trigger investigation and revocation procedures.
CAA cannot prevent certificate issuance while attackers control DNS because they can also modify the CAA record. Restoring a restrictive CAA policy after an incident remains essential: CAs may reuse domain-control validation for a period of time, while strict CAA settings can prevent attackers from continuing to exploit cached validation state.
Lessons About the HTTPS Chain of Trust
The incident shows that HTTPS security depends on an entire chain: domain registries, DNS providers, CAs, CT logs, browsers, and the domain owner's operations team. Compromising a single link can produce a certificate that appears fully valid and makes impersonation difficult for users to detect.
Organizations should monitor CT as a continuous security signal rather than checking it only during incidents. Domain and DNS administration should also be protected with phishing-resistant MFA, least privilege, locks on critical changes, and out-of-band verification procedures.
VNCyberS compiled from Google Chrome Security and The Hacker News
Tiếng Việt
English