A ccTLD hijack changes what a certificate authority sees when it asks who controls a domain. Google's October 6 post describes domain hijacks in the .gh, .sl and .as namespaces in which attackers modified authoritative DNS records and obtained unauthorized HTTPS certificates covering several Google domains and domains belonging to other organizations. Google says its own systems were not compromised, and that it has no reason to believe the certificate authorities that issued the certificates did anything wrong.
That last statement is the architectural problem. If the CAs followed their applicable procedures, the incident illustrates a different problem: domain-control validation can return an acceptable result even when the underlying namespace has been compromised. This note covers that mechanism, and the recovery step that is easy to skip once DNS is back.
When the namespace is compromised, a CA's validation can return an acceptable result for the wrong party.
What Google's Post States, and What It Does Not
Everything incident-specific in this note is Google's account of the ccTLD hijack. The post is short, and it leaves most of the usual questions open. Reading it precisely matters more than reading it quickly.
| Stated by Google | Not established by Google's post |
|---|---|
| The affected namespaces were .gh, .sl and .as | Hijack dates and duration |
| Attackers modified authoritative DNS records | The domain-validation method behind any certificate |
| Unauthorized certificates covered several Google domains and domains of other organizations | Issuing CAs and the number of certificates |
| Certificate Transparency data revealed additional organizations believed affected, and Chrome blocked those certificates | Which organizations were affected |
| Chrome blocked the certificates through CRLSets and Google worked with the CAs on revocation | Whether any certificate was used against users |
| Google has no reason to believe the issuing CAs did anything wrong | Whether DNSSEC or registry lock was enabled, absent or defeated |
Google also says it cannot guarantee that its analysis identified every affected domain. That limit matters for the monitoring question below.
Certificate Transparency is the detection layer in Google's account: it is where the additional affected organizations surfaced. By construction it reports issuance after the fact, which is why the second and third checks below exist.
Why a ccTLD Hijack Becomes Certificate Evidence
Three layers are involved, and they fail differently.
The compromised layer is the namespace: authoritative DNS under a country-code TLD. The trust decision is the CA's domain-control validation, the check that a requester controls the domain it is asking a certificate for. The consequence is a certificate that is technically valid and wrong about who owns the name.
Analysis, not a reconstruction of any specific issuance.
Validation methods differ in what they query, and Google's post does not say which method applied to any certificate. This note does not assume one. The post does establish the outcome, and Google's statement about the CAs is what makes the outcome instructive. A CA can run its validation as designed and still reach the wrong answer about ownership when the namespace it validates against is under attacker control. That reading is analysis built on Google's statement, not a reconstruction of any specific issuance.
DNSSEC is a relevant control at this layer. The Baseline Requirements require CAs to perform DNSSEC validation on the DNS queries used for domain-control validation and on CAA lookups, and RFC 8657 describes the protection as applying to DNSSEC-signed domains. Whether any of that applied to a certificate in the ccTLD hijack is not something Google's post addresses, and this note does not speculate.
The trust-anchor rollover post is the useful contrast. A trust anchor decides what a validating resolver believes about the DNS tree. Domain-control validation decides what a CA believes about a requester. They have different consumers and different repair paths, and verifying a resolver's trust anchor does nothing about a certificate that has already been issued.
Restoring DNS Is Not Restoring Issuance Control
Google states that CAA cannot prevent certificate issuance during an active DNS hijack. My reading of why: a CAA policy is a DNS record, and during the hijack the records a CA reads are served by whoever controls the zone. Google's post states the limitation, not that reason.
For the period after a ccTLD hijack ends and DNS control is restored, Google's guidance is specific. CAs may cache and reuse completed domain control validation checks for later issuance. Restoring a restrictive CAA policy, especially one that limits issuance to specific authorized accounts and validation methods, is meant to stop an attacker from using cached validation state to mint new certificates once the hijack ends.
That is a defensive rationale. Google's post documents no case of a CA issuing from cached validation after restoration, and this note does not claim one occurred. It describes the condition the policy is meant to close.
The control also has a precondition. RFC 8657 states that the account and validation-method parameters rely on the CA recognizing them, and are not an effective means of control over issuance unless the CA's support is established beforehand; a domain must not assume the restrictions are effective without explicit indication from the CA. The current Baseline Requirements (version 2.3.1) do not yet make that processing universal: they require CAs to process both parameters from 2027-03-15. A restored policy that names restrictions an authorized CA does not process is a record, not a gate.
A defensive control, not a documented attack sequence.
The operational consequence is an invariant: DNS restoration is not certificate-issuance recovery. The sequence below is my recommendation, not a procedure Google documents. Restore authoritative control. Publish the restrictive CAA policy. Confirm from outside your own network that the restored authoritative servers return it. Confirm, from each authorized CA's own documentation, that it recognizes and processes the account and validation-method restrictions you rely on. Only then close the incident for issuance. Closing at step one leaves the single control Google names for the post-hijack window unestablished.
The ccTLD Hijack Check
Diagnostic: "If a registry you do not control were compromised tomorrow, what evidence would show which certificates were issued for your names, and what would stop the next one after DNS is restored?"
Three checks answer it, and each has to produce evidence, not a policy statement.
| Check | Evidence that answers it |
|---|---|
| Can we detect unauthorized issuance across the whole portfolio? | Certificate Transparency monitoring covers every domain you hold, including parked domains and regional ccTLDs, and alerts reach a named owner. |
| Is issuance constrained before an incident? | A published CAA policy names the authorized CAs, with ACME account and validation-method restrictions only where each authorized CA documents that it recognizes and processes them. |
| Can we restore DNS without leaving issuance exposed? | A written recovery procedure verifies authoritative control, the effective CAA policy and each authorized CA's support for the restrictions relied on before the incident is closed. |
The inventory behind the first check has to come from registrations, not from the domains people remember. Google's guidance names parked and regional ccTLD properties explicitly, and an inventory built from memory will miss them.
If you hold a domain in .gh, .sl or .as, Google's guidance is to review recent Certificate Transparency entries for unexpected issuance. Google is also explicit that Chrome's blocking is not a substitute for any of the three: it does not reliably protect users of other clients, and Google cannot promise it found every affected domain.
ccTLD Hijack Recovery Checklist
The check above is the standing posture. This checklist is the same logic as a run sheet for the recovery itself. Checks 1 and 2 can start as soon as the incident is declared, because neither depends on DNS being restored. Check 3 comes before check 4, because the CAA policy has to be confirmed on the restored authoritative servers. Check 5 closes only the issuance-control workstream.
01 — Inventory all affected domains
List every domain you hold under the affected namespace, parked and regional ccTLDs included, from registrar and registry records.
02 — Review Certificate Transparency logs
Search CT for every inventoried domain and flag any certificate you cannot trace to known issuance.
03 — Verify authoritative DNS control
Confirm from outside your network that the delegation and each authoritative server return the expected records.
04 — Verify CAA policy and CA support
Confirm the restored servers return your restrictive CAA policy, and that each authorized CA supports the account and validation-method restrictions you rely on.
05 — Record evidence before closing
Keep dated evidence for checks 1 to 4, name an owner, and list open items before closing the certificate-issuance recovery workstream.
⚠ What passing these checks does not show: Passing these checks does not revoke any certificate already issued, and it does not show that no unauthorized certificate exists. Certificate Transparency covers logged certificates only. Existing exposure, revocation status and residual risk need a separate investigation.
Download: ccTLD Hijack Recovery Checklist (PDF, 1 page)
What This Does Not Argue
This note does not claim an attack method for the ccTLD hijack, because Google's post does not give one. It does not claim the CAs erred, because Google says it has no reason to believe they did. It does not claim that any CA issued from cached validation after DNS was restored, because no such case is documented. It makes no claim about whether DNSSEC or registry lock was enabled, absent or defeated in this incident, because the post does not discuss either. And it is not a tutorial on Certificate Transparency or CAA.
The claim is narrower. Control of authoritative DNS can undermine the evidence used to issue a trusted certificate, and restoring DNS does not by itself show that issuance has been closed to everyone else.
Architect's Verdict
Control of authoritative DNS can corrupt the evidence a certificate authority relies on. A CA that follows its procedures can still issue a certificate to the wrong party, because the validation it ran returned an acceptable result against a namespace the attacker had taken. Google's account of the ccTLD hijack, which states no reason to believe the CAs erred, points to a design problem and not a vendor problem.
The real problem is how teams close these incidents. DNS recovery gets treated as the finish line, but certificate issuance is a separate control surface with its own state, and restoring the zone does not reset it. The one control Google names for that window is a restrictive CAA policy, and it only helps if someone confirmed it was in place, and that the authorized CAs honor the restrictions it relies on, before declaring recovery complete.
Getting the zone back is the start of certificate recovery, not the end of it.
Additional Resources
- The Root KSK Rollover Is Done. Did Your Resolver's Trust Anchor Change? — what a validating resolver trusts about the DNS tree; the contrast to what a CA accepts as proof of domain control.
- Chrome's Response to Recent ccTLD Registry Hijacks — Google's October 6, 2026 post; the primary source for every incident statement in this note.
- CA/Browser Forum Baseline Requirements — the requirements governing domain-control validation, certificate issuance and CAA processing.
- RFC 8657: CAA Record Extensions for Account URI and ACME Method Binding — how CAA can restrict certificate issuance by CA account and domain-validation method, including implementation limitations.
Originally published at rack2cloud.com
Top comments (0)