ccTLD registry hijack: twelve valid Google and YouTube certificates obtained via .gh, .sl and .as

Between 22 and 27 September 2026, Let's Encrypt and ZeroSSL issued at least twelve valid TLS certificates for Google and YouTube names that Google had not requested. Attackers had taken over the operators of three country-code domains, .gh (Ghana), .sl (Sierra Leone) and .as (American Samoa), and from there passed the domain control check that precedes each issuance.

Google disclosed the incidents on 6 October in a post from the Chrome Secure Web and Networking Team. The company says its systems were not breached and that it has no reason to believe the issuing authorities did anything wrong. The post names no attacker, gives no account of how the registries were breached and warns that Google's analysis may not have found every affected domain.

Companies with .es, .co.uk or other country-code domains depend on a similar operator, one they have seldom assessed and that is usually missing from their supplier inventory.

What is known about the .gh, .sl and .as ccTLD hijacks?

According to Google's post of 6 October, attackers compromised the third-party operators of the .gh, .sl and .as country-code top-level domains (ccTLDs) and changed authoritative DNS records. With that access they obtained digital certificates for domains belonging to Google and to other organisations. Chrome blocked the certificates it could identify through CRLSets, its emergency blocking channel, and Google worked with the issuing authorities to have them revoked.

The dates and numbers come from The Hacker News, which searched public Certificate Transparency (CT) logs with ctlogs.dev and Cert Spotter. It found twelve certificates covering seven domains, eleven issued by Let's Encrypt and one by ZeroSSL. Let's Encrypt staff confirmed on the community forum that certificates for Google and YouTube had been issued and had since been revoked. The Hacker News gives this timeline from the CT logs:

• 22 September: two wildcard certificates are logged, one for google.com.gh and one for youtube.com.gh.
• 25 September: six certificates are logged for google.sl, google.com.sl and youtube.sl, five from Let's Encrypt and one from ZeroSSL.
• 26 September: the two .gh certificates and the ZeroSSL one are revoked.
• 27 September: four certificates are logged for google.as and youtube.as.
• 1 October: the remaining nine are revoked.
• 6 October: Google publishes its post.

The first .as certificate was logged a day after the .gh ones were revoked. The shortest-lived certificate was valid for roughly a day and a half, the longest for almost a week.

Twelve is a minimum, because The Hacker News searched only a handful of Google and YouTube names. Google adds in its post that several leading global brands and widely used online services were also affected, without naming them. Chrome blocked the certificates for those organisations that it could identify, and Google contacted the owners where possible.

How did attackers obtain valid certificates for Google domains?

Attackers could obtain certificates for Google domains because domain validation checks only that the applicant controls the domain's DNS or web server when the request is made. The certificate authority sets a challenge, and the applicant solves it by publishing a value in DNS or on the web server. With ACME, the protocol that automates issuance, the exchange takes seconds and involves no human review.

The operator of a country-code zone decides which name servers each domain under it is delegated to. An intruder who changes that delegation answers every query for google.sl from infrastructure of their own, and answers the authority's challenge as well. The authority would have asked DNS and received the reply it expected, with no sign that it came from somewhere else.

Google has not said which records were altered or for how long, so this mechanism is a reconstruction consistent with the published facts and not confirmed by the company. Ars Technica describes the attackers changing DNS records and name server delegations in the same terms.

With a valid certificate and diverted traffic, an attacker can serve a copy of a site, or collect the domain's email if the MX records are redirected too. A visitor would see the padlock and the right address, with no visible sign of the spoofing.

Has a country-code registry been compromised before?

In April 2019 ICS-Forth, which runs Greece's .gr domain, acknowledged an intrusion that Cisco Talos tied to the Sea Turtle campaign. Talos found that the intruders kept their access for at least five days after the public statement. It also reported the redirection of domains belonging to three government entities using .gr, probably through that access, and the use of certificates from a different provider from the one the victim used.

Sea Turtle was an espionage campaign against governments attributed to an advanced persistent threat (APT) group, whereas the author and aim of the 2026 hijacks are still unknown.

Why did CAA, DNSSEC and HSTS fail to stop the issuance?

CAA, DNSSEC and HSTS did not stop the issuance because they depend on DNS answers that the attacker was serving from the level above. The same applies to validation from several network vantage points.

Does a CAA record help when the attacker controls DNS?

A CAA record, which lists the authorities allowed to issue for a domain, offers no protection during a hijack because it is published in the same DNS the attacker controls. The Hacker News checked on 7 October and found that all seven domains carried a strict CAA record authorising only Google Trust Services. Whether that record predates the attack is unclear. If it did, Let's Encrypt and ZeroSSL issued regardless.

Does DNSSEC protect against a compromised ccTLD registry?

DNSSEC does not protect against a compromised registry, because the DS record that anchors each delegated domain's keys is published by the ccTLD zone. Whoever controls that zone can replace or withdraw it. Since 15 March 2026, public authorities must validate DNSSEC where present in their CAA and domain control lookups, under CA/Browser Forum ballot SC-085v2. An attacker holding the registry would have to change or remove the DS record to get past that check. The published sources do not say whether the affected domains used DNSSEC.

Does multi-perspective validation catch a registry hijack?

Validation from several network vantage points does not catch a registry hijack, because the false delegation reaches every location in the same form. Public authorities have been required to apply it since 2025 (MPIC, multi-perspective issuance corroboration). It is designed for route diversions such as the BGP hijack used to deliver trojanised Virtualizor updates, where the answer changes depending on where the query comes from.

What protection do HSTS and Chrome's certificate blocking offer?

HSTS makes the browser insist on HTTPS with a valid certificate, and the attacker's certificate is valid. Blocking through CRLSets protects Chrome users, and only against certificates Google has identified. The company concedes that its interventions do not reliably protect people on other browsers, and it tells domain owners not to rely on the browser to protect their users.

Mobile apps an organisation publishes can add certificate pinning, which makes the app reject every certificate other than the one it expects, even a technically valid one.

How do you detect a TLS certificate issued without authorisation?

A certificate issued without authorisation is detected by watching Certificate Transparency, the public logs in which authorities record every certificate. Google used that data to trace the other victims, and The Hacker News used it to find the twelve certificates. Google's first recommendation is to enrol every domain the organisation owns with a CT monitor, parked domains and regional country-code variants included.

The monitor should raise an immediate alert for:

• A certificate from an authority the organisation does not use. According to The Hacker News, since at least 10 September every other certificate for google.com.gh, google.sl and google.as had come from Google Trust Services.
• Wildcard issuance for a domain that only serves a redirect.
• Several certificates for the same name within minutes from different authorities, as happened with google.com.sl.
• A certificate of any kind for a domain that hosts no service.

Changes to the delegation are a second signal that CT does not capture. An organisation can query, on a schedule and from outside its network, the name servers and the DS record that the country-code zone publishes for each of its domains. A mismatch with the expected values can give warning before a certificate is issued, though the margin is thin when issuance is automated. The check costs little, yet many companies run it only on the main domain and leave secondary ones out.

Secondary domains are part of the attack surface too, and an attack surface management service should cover them. Our guide to checking a domain's security explains how to review its public configuration from the outside.

Once a rogue certificate is found, the next step is to ask the issuing authority to revoke it. The CA/Browser Forum Baseline Requirements, the rulebook for public authorities, oblige an authority to investigate a certificate problem report and deliver initial findings within 24 hours. Knowing each authority's reporting channel in advance saves time when the incident response plan is triggered by a certificate the organisation did not request.

What should companies check in their domain portfolio?

For every domain, the inventory should record the registrar, the operator of the top-level domain and the certificate authority allowed to issue. That inventory is the starting point for reviewing CAA, monitoring and the relationship with each operator.

Which operators does each domain in the portfolio depend on?

Companies commonly register their brand under several extensions to get ahead of typosquatting, the registration of look-alike names by third parties, and then leave those domains parked for years. Each extension depends on a different operator, and their resources and practices vary widely.

Several extensions marketed as generic, among them .io, .ai, .co and .tv, are country-code domains according to IANA. No published source suggests that any of them is involved in this campaign, but they are run by an operator designated for that territory or by the contractor it has appointed, as in the three September cases.

How do you bind a CAA record to an ACME account with accounturi?

Binding the CAA record to an ACME account is Google's second recommendation, and it takes effect once the owner has regained control of DNS. Authorities may reuse a completed domain validation to issue further certificates without repeating the challenge. Current rules allow reuse for up to 200 days. At Let's Encrypt, the default profile reuses validations for 30 days and the tlsserver and shortlived profiles for 7 hours, according to its profiles page. An attacker who validated during the hijack could go on requesting certificates after DNS is back with its owner.

RFC 8657 defines two parameters that close that route at authorities which support them. The accounturi parameter restricts issuance to a named ACME account, and validationmethods limits the validation method accepted. Because Let's Encrypt checks CAA before every certificate it issues, it refuses an account missing from the record even if that account still holds a valid authorisation. Such a record looks like this:

• example.com. CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1234567890; validationmethods=dns-01"

Let's Encrypt documents both parameters. Confirm support with each authority before publishing the record. The account identifier in the example is fictitious.

Will 47-day certificates reduce the risk?

The shorter lifetimes approved by the CA/Browser Forum would not have changed this case, since the September certificates lasted a week at most. Ballot SC-081, approved on 11 April 2025, cuts maximum validity to 200 days from 15 March 2026, 100 days from 15 March 2027 and 47 days from 15 March 2029. Validation reuse falls to 100 days in 2027 and 10 days in 2029, as Let's Encrypt sets out on the same profiles page.

The new limits shorten the time during which a validation obtained in a hijack can be used to issue further certificates. Google lists reducing certificate validity and validation reuse among its longer-term work, through its Chrome root programs.

Can registry lock stop an attack on the registry itself?

The registry lock some operators offer protects against a compromised registrar or customer account, but not against an attack on the registry operator. Bringing registrars and extension operators into third-party risk management gives the business evidence for deciding which domains may host critical services and which should only redirect.

Within the European Union, NIS2 counts top-level domain name registries among digital infrastructure entities. Elsewhere the obligations differ from country to country, so whoever picks an extension is subject to the regulatory regime that governs its operator, or to the lack of one.

Who is behind the attack, and what is still unknown?

Google has not identified who hijacked .gh, .sl and .as or explained how the operators were compromised. Nor has it said what the certificates were used for, if anything. It is not known whether the three registries have regained full control of their zones, how many organisations were affected or whether any certificate was used to intercept user traffic.

Google says it learned of the hijacks the week before its post of 6 October, without giving a day. The earliest revocations are dated 26 September, and none of the sources explains the gap.

Google watches Certificate Transparency systematically and has a browser with which to block what it finds, and certificates in its name were still valid for days. Organisations not yet watching CT can start by enrolling the domains that only redirect, since these tend to go unwatched.

Sources and attribution: this article draws on Google's public disclosure of 6 October 2026, the Certificate Transparency analysis published by The Hacker News, Let's Encrypt's confirmation on its forum and documentation from the CA/Browser Forum and Let's Encrypt. It reflects the information available on 8 October 2026. Naming Let's Encrypt, ZeroSSL, Google or the operators of the .gh, .sl and .as domains does not imply a security flaw in their products or in their issuance procedures. The attack has not been attributed to any group and the facts may change.

Notice: the sample CAA record is illustrative. A badly defined CAA record can block the renewal of legitimate certificates, so test it first with every certificate authority and ACME account in use.