# How Attackers Hijacked Three Country-Code Domains to Issue Fraudulent Google Certificates
A major security incident earlier this fall revealed that attackers gained control of three country-code top-level domains (ccTLDs) and used that access to issue unauthorized HTTPS certificates for Google and YouTube subdomains. The breach, which went undetected for nearly a week, exposed a troubling vulnerability in how domain ownership is verified and how quickly the ecosystem can respond.
## The Three Compromised Domains
The domains at the center of the incident were **.gh** (Ghana), **.sl** (Sierra Leone), and **.as** (American Samoa). All three are country-code top-level domains, meaning they are designated for use within specific nations or territories. The attackers modified the authoritative DNS records for these domains, which is the mechanism by which domain registrars and certificate authorities verify that someone has the right to manage a given domain.
Because the DNS records were altered, the attackers could pass the domain-validation checks required by certificate authorities. This allowed them to obtain encryption certificates that would make it appear as though their fraudulent sites were the legitimate Google or YouTube pages.
## How the Certificates Were Issued
Certificate authorities (CAs) routinely verify domain ownership before issuing a certificate. One standard method is to have the applicant add a specific DNS record to the domain. When the attacker controlled the DNS records for .gh, .sl, and .as, they were able to add the necessary proof and have certificates issued in the name of Google and YouTube.
Twelve certificates were identified in Certificate Transparency (CT) logs — the public, append-only records that track every SSL/TLS certificate issued by trusted certificate authorities. The certificates covered a range of subdomains, including wildcards like `*.google.com.gh` and `*.youtube.com.gh`, as well as specific names like `google.sl` and `www.google.as`.
Of the 12 certificates, **11 were issued by Let’s Encrypt** and **1 was issued by ZeroSSL**. The issuance spanned three days: September 22 for .gh, September 25 for .sl, and September 27 for .as.
## Chrome’s Emergency Response
Google’s Chrome browser has a built-in mechanism called **CRLSets** (Certificate Revocation Lists Sets) that allows it to quickly block known problematic certificates in emergency situations. Through this system, Chrome was able to prevent users from trusting the unauthorized certificates for Google and YouTube domains, even before the certificates were formally revoked by the issuing CAs.
The company also reached out to the certificate authorities involved and confirmed that the certificates were revoked. The two .gh certificates and the ZeroSSL certificate were revoked on **September 26**, while the remaining nine were revoked on **October 1**. The time between the first logging of a certificate and its revocation ranged from roughly a day and a half to nearly a week.
## Broader Impact Beyond Google
While Google’s announcement focused on the company’s own domains, it noted that Certificate Transparency data pointed to other organizations — well-known global brands and widely used online services — that were likely hit by the same attacks. Google did not name these organizations, but the scale of the DNS hijack meant that any domain under .gh, .sl, or .as was at risk.
Critically, Google emphasized that its own infrastructure was **not breached**. The compromise was limited to the DNS configuration of the three country-code domains, and there was no indication that Google’s systems or Google Trust Services (its own certificate authority) played any role in the unauthorized issuances.
## Why This Matters for the Broader Web
This incident highlighted a significant gap in how quickly the certificate ecosystem can detect and respond to domain hijacks. Even though Chrome blocked the certificates for its users, the certificates remained valid for days in other browsers and applications that do not rely on Google’s CRLSets. Users of Firefox, Safari, or mobile apps were potentially exposed to man-in-the-middle attacks during the window between issuance and revocation.
The incident also underscored the importance of **Certificate Transparency monitoring**. Google stressed that domain owners — especially those managing domains in less-monitored ccTLDs — should be actively watching CT logs for any certificates issued for their domains without authorization.
## What Domain Owners Can Do to Protect Themselves
Google outlined several steps that domain owners can take to reduce the risk of unauthorized certificate issuance:
– **Monitor Certificate Transparency logs.** Automated CT monitoring services alert domain owners whenever a new certificate is issued for any of their domains. This is especially important for domains that are parked or not actively used, as they are often overlooked.
– **Publish a strict CAA (Certification Authority Authorization) DNS record.** A CAA record specifies which certificate authorities are permitted to issue certificates for a domain. A strict CAA record, tied to the domain owner’s own CA account, adds a strong layer of protection.
– **File a Certificate Problem Report.** If an unauthorized certificate is discovered, anyone can report it to the issuing CA under the Baseline Requirements. CAs are obligated to investigate and share their initial findings within 24 hours.
However, Google noted a limitation: a CAA record cannot prevent issuance while a DNS hijack is actively underway, since an attacker who controls DNS can remove or alter the record. The CAA record becomes protective once the owner regains control of their DNS, as it prevents the attacker from reusing a previously passed domain check to request additional certificates later.
The CA/Browser Forum has been tightening the rules around domain check reuse. The baseline reuse window of 200 days will drop to 100 days in March 2027 and just 10 days in March 2029. Let’s Encrypt, which issued the majority of the fraudulent certificates, has announced plans to reduce its own reuse window from 30 days to just 7 hours by 2028.
## Frequently Asked Questions
**Q: Were Google’s own servers hacked in this incident?**
A: No. Google confirmed that its internal systems were not compromised. The attack targeted the DNS records of three country-code top-level domains (.gh, .sl, and .as), which allowed the attackers to pass domain validation checks when requesting certificates.
**Q: Could this attack have affected browsers other than Chrome?**
A: Yes. Chrome blocked the unauthorized certificates through its CRLSets mechanism, but other browsers and applications did not necessarily have the same protections during the window between certificate issuance and revocation. Users of Firefox, Safari, Edge, or mobile apps may have been exposed if they visited the affected domains during that period.
**Q: Were any of the fraudulent certificates actually used to impersonate Google or YouTube?**
A: Google did not confirm whether the certificates were used to conduct man-in-the-middle attacks or intercept user data. The company simply stated that it could not determine whether the certificates were actively exploited.
**Q: What is Certificate Transparency, and why is it important here?**
A: Certificate Transparency (CT) is a public logging system that records every SSL/TLS certificate issued by trusted certificate authorities. It serves as an audit trail that domain owners and security researchers can use to detect unauthorized certificates. In this incident, CT logs were the primary way the unauthorized certificates were discovered.
**Q: What is a CAA record, and how does it help?**
A: A CAA (Certification Authority Authorization) DNS record specifies which certificate authorities are allowed to issue certificates for a domain. If a CA receives a certificate request for a domain with a CAA record, it must check the record and ensure it is listed as an authorized issuer. This significantly reduces the chance that an unauthorized CA can issue a certificate for your domain.
**Q: Why were country-code top-level domains specifically targeted?**
A: Country-code TLDs often have different administrative oversight and monitoring practices compared to generic TLDs like .com or .org. This can make them attractive targets for attackers looking to exploit weaker domain validation processes. The incident prompted renewed calls for stronger DNS security across all TLD types.
**Q: How can I check if any unauthorized certificates were issued for my domains?**
A: You can use free Certificate Transparency monitoring services such as Cert Spotter or Censys. These services will notify you whenever a new certificate is logged for any of your domains, including subdomains and variations you may not have actively considered.
## Conclusion
The hijacking of three country-code top-level domains and the subsequent issuance of unauthorized certificates for Google and YouTube domains served as a stark reminder of how interconnected the web’s trust infrastructure truly is. A vulnerability in DNS configuration — a component many domain owners take for granted — was enough to undermine the encryption that billions of users rely on every day.
While Chrome’s rapid response through CRLSets and the quick revocation of certificates by Let’s Encrypt and ZeroSSL limited the damage, the nearly week-long window between the first unauthorized issuance and the bulk of the revocations is a sobering reminder that no single defense is foolproof. Domain owners must take proactive steps — monitoring CT logs, publishing strict CAA records, and responding quickly to any anomalies — to protect themselves and their users.
For the broader internet ecosystem, this incident is likely to accelerate ongoing efforts to tighten certificate issuance rules, shorten domain check reuse windows, and strengthen DNS security at every level. The goal is simple but essential: making sure that no single point of failure can compromise the trust that keeps the web secure.
Thank you for reading
