Three ccTLD hijacks, no certificate count: one passed check can back a certificate until 30 September 2027

One passed check can back a certificate until 30 September 2027

On 6 October 2026 Google's Chrome Secure Web and Networking Team said attackers had compromised three country-code top-level domains (ccTLDs), .gh for Ghana, .sl for Sierra Leone and .as for American Samoa, modified authoritative DNS records, and obtained HTTPS certificates that the owners of the names had not authorised, for several Google domains and for other organisations. The post gives no count of certificates, no incident dates and no names of certificate authorities (CAs). It does say one thing that turns into arithmetic: CAs may cache and reuse a completed domain control validation, which is why Google wants a restrictive CAA record (a DNS record naming the CAs allowed to issue for a domain) in place once DNS control is restored.

The rule that governs the cache is public. In version 2.3.1 of the CA/Browser Forum Baseline Requirements (BR), a CA may reuse a completed validation for up to 200 days when it issues a certificate before 15 March 2027, and for up to 100 days after that (section 4.2.1). A certificate issued before that date may be valid for up to 200 days (section 6.3.2). Apply both: any domain validation completed between 26 August 2026 and 14 March 2027 can, at the maximums, sit behind a certificate that stays valid until 30 September 2027 (derived: a certificate issued on 14 March 2027, the last day of the 200-day rules, plus 200 days). For a validation completed on 6 October, the day Google published, that is 359 days (derived).

What that does not establish. It does not say any certificate in this incident rested on a reused validation: Google does not say which validation method was used, how many certificates exist or when they were issued. It is a ceiling the rules permit, not a finding, and a CA may be stricter. Let's Encrypt, for example, said in December 2025 that its reuse period was 30 days, with 10 days planned from 10 February 2027 and 7 hours from 16 February 2028, but Google names no CA, so that example says nothing about who issued these. It does not say any certificate stayed valid that long: Google blocked the ones it found in Chrome and says it worked with CAs on revocation for its own. And it does not make the date a comfort. A certificate nobody has found is the one the ceiling is about, and Google says it cannot guarantee it found every affected domain.

Baseline Requirements 2.3.1, sections 4.2.1 and 6.3.2, read from the Forum's repository on 7 October 2026: the longest a completed validation may be reused, the longest a certificate may be valid, and the derived ceiling for one passed check.

1. Certificate issued

   Before 15 March 2026

   Validation reuse, up to

   398 days

   Certificate valid, up to

   398 days

   Ceiling, derived

   796 days

2. Certificate issued

   15 March 2026 to 14 March 2027

   Validation reuse, up to

   200 days

   Certificate valid, up to

   200 days

   Ceiling, derived

   400 days

3. Certificate issued

   15 March 2027 to 14 March 2029

   Validation reuse, up to

   100 days

   Certificate valid, up to

   100 days

   Ceiling, derived

   200 days

4. Certificate issued

   From 15 March 2029

   Validation reuse, up to

   10 days

   Certificate valid, up to

   47 days

   Ceiling, derived

   57 days

Certificate issued	Validation reuse, up to	Certificate valid, up to	Ceiling, derived
Before 15 March 2026	398 days	398 days	796 days
15 March 2026 to 14 March 2027	200 days	200 days	400 days
15 March 2027 to 14 March 2029	100 days	100 days	200 days
From 15 March 2029	10 days	47 days	57 days

The table shows why the answer above is a date and not a duration. For a validation completed on 6 October, 200 days of reuse would run to 24 April 2027, but on 15 March 2027 the reuse allowance drops to 100 days, so the latest certificate it can back is the one issued on 14 March 2027, valid for 200 days. For a validation completed before 26 August 2026 the 200 days run out first and the ceiling is the full 400 days after it.

The last column is what Google means by "reducing certificate validity and DCV reuse" (DCV is domain control validation) in its closing sentence, where it links to the Forum ballot, SC-081, that wrote this schedule. The ceiling falls from 400 days now to 57 days in March 2029. Until then, one validation passed during a hijack can outlast the hijack by months.

What Google's post says, and what it does not

Google's post is about 570 words, signed by a team rather than a named author. Help Net Security, the news pointer for this briefing, summarises it closely, with one wording difference noted below. Where the post gives a quantity of certificates or organisations it uses "several" or "additional", and of incidents "a series". It gives no number.

Google's post of 6 October 2026, read in full from the page itself on 7 October 2026. Quantities are Google's own words.

1. Question

   Which names

   The post says

   A series of domain hijacks in the .gh, .sl and .as namespaces. Any domain ending in those is "at risk".

   The post does not say

   Which domains were actually hijacked, or for how long.

2. Question

   What was changed

   The post says

   Attackers modified authoritative DNS records.

   The post does not say

   Which records. Whether name servers or addresses changed.

3. Question

   How many certificates

   The post says

   Several covering Google domains, plus additional organisations including leading global brands and widely used online services.

   The post does not say

   Any count. Any list of names or organisations.

4. Question

   Which CAs

   The post says

   The issuing CAs. No reason to believe they did anything wrong.

   The post does not say

   Names or number of CAs. The validation method. Whether a reused validation was involved.

5. Question

   When

   The post says

   Posted 6 October. Google became aware "last week".

   The post does not say

   When DNS changed, certificates were issued, revoked or blocked, or the hijacks ended.

6. Question

   Who and how

   The post says

   Nothing.

   The post does not say

   Any actor, how the three ccTLDs were compromised, or whose systems were compromised.

7. Question

   Harm

   The post says

   Chrome blocked the certificates. Chrome users need take no action.

   The post does not say

   Whether any certificate was used against anyone, or any name pointed at an attacker's server.

8. Question

   Completeness

   The post says

   Google cannot guarantee it found every affected domain.

   The post does not say

   How much is unfound.

Question	The post says	The post does not say
Which names	A series of domain hijacks in the .gh, .sl and .as namespaces. Any domain ending in those is "at risk".	Which domains were actually hijacked, or for how long.
What was changed	Attackers modified authoritative DNS records.	Which records. Whether name servers or addresses changed.
How many certificates	Several covering Google domains, plus additional organisations including leading global brands and widely used online services.	Any count. Any list of names or organisations.
Which CAs	The issuing CAs. No reason to believe they did anything wrong.	Names or number of CAs. The validation method. Whether a reused validation was involved.
When	Posted 6 October. Google became aware "last week".	When DNS changed, certificates were issued, revoked or blocked, or the hijacks ended.
Who and how	Nothing.	Any actor, how the three ccTLDs were compromised, or whose systems were compromised.
Harm	Chrome blocked the certificates. Chrome users need take no action.	Whether any certificate was used against anyone, or any name pointed at an attacker's server.
Completeness	Google cannot guarantee it found every affected domain.	How much is unfound.

Two details in the coverage are not in Google's post. Help Net Security says the attackers compromised the third-party operators of the three ccTLDs; Google's text says the third-party ccTLDs, and its title says registry hijacks. Ars Technica says the attackers changed IP addresses and nameserver delegations for selected domains, and that the CAs followed all requirements; Google says only that attackers modified authoritative DNS records and that it has no reason to believe the CAs did anything wrong. This briefing follows Google's wording. Google is both a victim here, since certificates were obtained for its domains, and the operator of the Chrome Root Program that sets the trust rules CAs follow. That is a reason to read the post as Google's account, and no other party has confirmed its details.

I found no statement from the operators of the three registries or from any CA on 7 October. The public pages of the three registries carry nothing on it (the .gh registry's announcements page shows a maintenance note dated 3 August 2026), and a web search for CA incident reports found none. That describes my search, not what exists.

How a changed DNS answer becomes a certificate, and where each defence sits

Google says what was changed, not how the checks were passed. The Baseline Requirements say what a CA looks at. Set side by side they give a mechanism with the gaps marked, drawn below and summarised in the table after it. (Certificate Transparency, CT, is the public log of issued certificates.)

Three points sit behind the drawing. First, several of the validation methods the Forum permits depend on what DNS returns. The DNS Change method looks for a random value or request token in a TXT, CNAME or CAA record under the name being validated (BR 3.2.2.4.7); the email and phone methods that look up a CAA or TXT contact do too, though Chrome and the Forum are phasing those out. Google does not say which method was used.

Second, multi-perspective issuance corroboration (BR 3.2.2.9) repeats the check from several network locations, and the BR describe it as improving protection against Border Gateway Protocol (BGP) hijacks of equally specific prefixes. That defends against an attacker who controls the path from one location. On my reading it does not defend against a change at the source of the answer, because each location is then handed the same changed answer. That is inference: Google does not say how the checks were passed.

Third, the CA also reads the CAA record from DNS (BR 4.2.2.1). While the attacker's records are the ones being read, the owner's CAA record is not. Google says as much: CAA "can not prevent certificate issuance during an active DNS hijack".

What each defence did or does in this incident, from Google's post, the Baseline Requirements and the Chromium CRLSets page. Rows marked inference are my reading.

1. Defence

   Chrome CRLSet block

   What it does here

   Blocks listed certificates in Chrome with no user action. Google did this for its own properties, then for others found in CT logs.

   What it does not do

   Does not reach other clients; Google says Chrome measures do not reliably protect them. It is not revocation.

2. Defence

   CA revocation

   What it does here

   Google worked with the CAs so the certificates for its properties were revoked. The BR give a CA 24 hours once it has evidence a validation cannot be relied on (4.9.1.1).

   What it does not do

   Not stated for other organisations' certificates. Does not undo traffic served before it, and helps only clients that check.

3. Defence

   Multi-perspective corroboration

   What it does here

   Repeats the check from several network locations, aimed at BGP routing attacks (BR 3.2.2.9).

   What it does not do

   Inference: not built for a change at the source of the answer, where each location sees the same thing.

4. Defence

   Owner's CAA record

   What it does here

   Names the CAs allowed to issue. After DNS control returns, stops cached validation being used for new certificates (Google).

   What it does not do

   Cannot stop issuance during an active hijack (Google).

5. Defence

   DNSSEC

   What it does here

   A CA must validate it back to the root where a chain exists (BR 4.2.2.2).

   What it does not do

   Inference: no help if whoever changes the records can also change the parent's DS record. Not stated whether any affected domain was signed.

6. Defence

   CT monitoring

   What it does here

   Shows each logged certificate in near real time (Google). The NCSC says unexpected certificates may mean an attacker controls DNS.

   What it does not do

   Alerts after issuance, does not prevent it. Cannot show a certificate that was never logged; not stated whether any was not.

Defence	What it does here	What it does not do
Chrome CRLSet block	Blocks listed certificates in Chrome with no user action. Google did this for its own properties, then for others found in CT logs.	Does not reach other clients; Google says Chrome measures do not reliably protect them. It is not revocation.
CA revocation	Google worked with the CAs so the certificates for its properties were revoked. The BR give a CA 24 hours once it has evidence a validation cannot be relied on (4.9.1.1).	Not stated for other organisations' certificates. Does not undo traffic served before it, and helps only clients that check.
Multi-perspective corroboration	Repeats the check from several network locations, aimed at BGP routing attacks (BR 3.2.2.9).	Inference: not built for a change at the source of the answer, where each location sees the same thing.
Owner's CAA record	Names the CAs allowed to issue. After DNS control returns, stops cached validation being used for new certificates (Google).	Cannot stop issuance during an active hijack (Google).
DNSSEC	A CA must validate it back to the root where a chain exists (BR 4.2.2.2).	Inference: no help if whoever changes the records can also change the parent's DS record. Not stated whether any affected domain was signed.
CT monitoring	Shows each logged certificate in near real time (Google). The NCSC says unexpected certificates may mean an attacker controls DNS.	Alerts after issuance, does not prevent it. Cannot show a certificate that was never logged; not stated whether any was not.

Five comforting phrases and what each one supports

• "The certificates were revoked." Google says it worked with the issuing CAs so the certificates were revoked, in the sentence about its own properties. For the other organisations it says it blocked the certificates in Chrome and contacted owners where it could. It does not say those were revoked. Ars Technica notes that formal revocation is slow and that it is unclear whether all the other certificates have even been blocked. Chromium's CRLSets page calls CRLSets Chrome's primary means of blocking certificates quickly in an emergency and says Chrome does not generally make online revocation checks (OCSP or CRL). A block in Chrome says nothing about Firefox, Safari, a mobile app or a script.
• "Blocked in Chrome." It is neither revocation nor proof that nothing was intercepted. Google's post is silent on whether any certificate was used, and a block does not undo what happened before it. The post does not say how long after issuance the blocks began.
• "Google domains." Headlines read this as google.com. The post lists no names. The access was to the .gh, .sl and .as namespaces, so the Google names are, by inference, names ending in those three. Google does not list them, and nothing in the post says its main domains were affected.
• "Three registries hijacked." Google says attackers compromised the third-party ccTLDs and that any domain ending in them is at risk. It does not say every domain was hijacked, that a government system was breached, or whether the compromise was of a registry's own systems, a registrar, a DNS operator or a service provider.
• "The CAs did nothing wrong." Google's words are that, "due to the nature of the attacks", it has no reason to believe they did. That is an absence of evidence in Google's hands. Whether each CA met the Baseline Requirements, including corroboration from several network locations and DNSSEC validation where a chain exists, is a matter for the CAs' audits and incident reports, and I found none.

What this means for UK organisations

Google names no UK organisation, and nothing in its post shows UK exposure. The exposure to look for is indirect: a domain your organisation holds under .gh, .sl or .as, including defensive or parked registrations; a regional site for work in Ghana, Sierra Leone or American Samoa; or a supplier, partner, payment or aid-delivery service whose hostnames end in one of the three. Google asks owners to cover their whole portfolio, "including parked or regional ccTLD properties", and to review recent Certificate Transparency entries for the three endings if they hold any.

The NCSC's guidance on managing public domain names already says what to do. It tells organisations to monitor critical DNS records for unexpected changes, naming the name server records, and to monitor Certificate Transparency logs, noting that unexpected certificates may indicate an attacker controls the domain's DNS. It advises registrar locking for high-value domains, two-step verification on the registrar account, and more than one trusted person able to manage each domain. Its Web PKI guidance recommends a CAA record on every domain, as specific as possible, using the RFC 8657 parameters accounturi and validationmethods where supported. CAs should process those parameters now and must from 15 March 2027 (BR 4.2.2.1.2), so check that yours does.

DNSSEC is where the three endings differ. It adds signatures to DNS answers, and a DS record in the parent zone is what ties a domain's signing keys to it. At 16:48 UTC on 7 October, and in the root zone file (serial 2026100701), the root held a DS record for .as and none for .gh or .sl, with signed proofs that none exists. Without a DS record in the parent there is no chain from the root, and the BR require a CA to validate that chain where one exists. So, as far as the root zone shows, an owner of a .gh or .sl name cannot give a CA a DNSSEC chain to check. That is inference, and it is not a finding about how any registry was compromised. Google does not say whether any affected domain was signed, and a signature protects an answer only if the party who can change the records cannot also change the parent's DS record.

An unexpected certificate in a Certificate Transparency log is a security event, not automatically a personal data breach. The ICO defines a personal data breach as a security breach leading to unauthorised access to or disclosure of personal data, and expects a notifiable breach to be reported within 72 hours of becoming aware of it. If you find an unexplained certificate for a name that carries logins or personal data, the first question is whether traffic could have been served to anyone while it was valid. The certificate alone does not tell you.

Two earlier briefings are relevant background. Cloudflare's post-quantum CA has issued nothing yet covers the Chrome Quantum-resistant Root Program that Google names in its closing sentence and what it had accepted by 5 October. Elsevier's record sat unchanged shows why a registration record that looks unchanged is not enough to monitor: there the record had not changed for 342 days while three addresses sent visitors to a different page.

Seven actions, in the order worth doing

What we could not verify

• Counts and names. How many certificates, which CAs, which domains and which organisations: not stated, and no other source found.
• Dates. When DNS changed, when certificates were issued, revoked or blocked, and when the hijacks ended: not stated. "Last week" is the only relative date and Google does not define it. On a Monday to Sunday week it means 28 September to 4 October, which is 2 to 8 days before the post (derived).
• Method. Which validation method was used, whether a reused validation was involved, and how any corroboration or DNSSEC check was passed: not stated. The 30 September 2027 date is a ceiling from the rules, not an observation.
• Use. Whether any certificate was used against any user: not stated.
• Revocation. Whether certificates for the other organisations were revoked or only blocked in Chrome: Google says blocked in Chrome; Ars Technica says it is unclear whether all have been blocked.
• Statements. Anything from the three registries or any CA: none found on 7 October.
• The post itself. What changed in Google's page at 17:10 UTC on 6 October: its metadata shows a modification with no note.

The question this leaves

Google's advice puts the burden on the domain owner, and the owner's two tools answer different halves of the problem. Certificate Transparency tells you after the event. A restrictive CAA record limits the aftermath. Neither stops the first certificate. So if a certificate for one of your domains were issued tonight on the strength of a DNS answer you did not give, who would see it by morning, and who in your organisation is allowed to ask the CA to revoke it?

Key facts