In October 2026, Google's Chrome security team disclosed hijacks affecting the .gh, .sl and .as country-code top-level domain namespaces. The attackers changed authoritative DNS and obtained unauthorized HTTPS certificates for several Google domains and domains belonging to other organizations. Google said its own systems were not compromised and that it had no reason to believe the issuing certification authorities had done anything wrong.
Quick answer. Inventory every corporate domain, including parked and regional ccTLD names; monitor Certificate Transparency (CT) issuance for that portfolio; reconcile unexpected certificates against an approved issuance register; and verify registrar, registry and DNS change controls. Use restrictive CAA records with account and validation-method bindings where your issuing CA supports them. CAA is a recovery and prevention control for some issuance paths, not a guarantee against an attacker who currently controls authoritative DNS.
The lesson for a mid-market or enterprise owner is a trust-chain problem. The organization can have a well-protected web server and still lose control of the name used to reach it if an upstream namespace or authoritative DNS path is hijacked. This guide turns the public incident into an evidence-driven checklist. It does not assert that a particular company was breached or that any named CA misissued certificates through negligence.
What the Chrome disclosure actually says
Google described a series of attacks against the .gh, .sl and .as country-code namespaces during the week before its 6 October publication. Attackers altered DNS records and completed certificate issuance for names they did not own. Chrome blocked suspected unauthorized certificates with CRLSets and worked with issuers on revocation. CT logs then revealed additional domains believed affected, and Google says it contacted owners where possible.
The details leave several important limits:
Google did not report a compromise of Google infrastructure. The weakness was in third-party namespaces.
Google did not say the certification authorities broke the rules. A CA's domain validation can be deceived when the attacker controls a DNS path that appears authoritative.
Google said Chrome users did not need to take action for the certificates Chrome had blocked, but it warned owners not to rely on browser intervention as a complete defense for every domain and client.
The disclosure does not list every affected enterprise domain. Your own monitoring and domain inventory are the sources of truth for your estate.
Treat those distinctions carefully in incident communications. “A certificate appeared in CT for our domain” is a lead for investigation. It is not by itself proof that the attacker intercepted users. Conversely, “we saw no suspicious browser warning” does not prove that every client or country-code name was unaffected.
The control chain an owner can inspect
A useful domain-security review follows the sequence from domain registration to DNS authority to certificate issuance to client trust. A failure at one layer can weaken another. Keep an owner and evidence source for each link.
Figure 1: The control chain from domain ownership to certificate acceptance, with practical evidence for each owner. Source: Google Chrome, ccTLD registry hijack disclosure and IETF RFC 8657.
1. Domain and registrar inventory
Start with a portfolio export that includes parent brands, country-code names, parked domains, product domains and domains held by acquired businesses. Record the registrar, registry, administrative contacts, renewal owner, nameservers and who can change each record. The incident makes parked and regional names relevant: Google expressly recommends monitoring CT across the entire portfolio, not just the domains that currently serve a website.
A useful control test is to compare the domain inventory in procurement or legal records with the list known to DNS operations and CT monitoring. Discrepancies identify names that no one is watching. Review registrar account recovery, multifactor authentication, delegated users and emergency change process. Do not publish real recovery contacts or secret answers in an assessment report distributed outside the authorized team.
2. DNS authority and change evidence
Record the authoritative nameservers and the parties that can edit them. Baseline DNS changes for high-value records, especially address, nameserver, CAA and validation records. For each unexpected change, preserve the old and new values, the time, the change actor if known, and the system that approved it.
A DNSSEC deployment can improve authenticity of DNS answers when the full validation path is used, but it is not a universal shield for a compromised registry or every certificate validation method. The IETF's RFC 8657 security considerations explain that the value of DNSSEC-backed CAA depends on how a CA validates DNS and which issuance method it accepts. The safe buyer question is narrower: which DNS assertions does our issuer actually validate, and how will we detect unauthorized changes?
3. Certificate Transparency monitoring
Monitor CT for every registered domain and relevant subdomain pattern. A useful alert supplies the certificate fingerprint, subject names, issuer, log timestamp, chain and the internal owner expected to recognize it. Have the certificate operations team maintain an approval register so an analyst can answer whether a new issuance is routine renewal, a delegated partner, a test or a surprise.
CT is a detection source, not an authorization system. An alert should initiate verification with the domain and certificate owners before anyone labels it malicious. Retain the certificate, DNS snapshot, registrar audit trail and investigation decision. If an unauthorized certificate is confirmed, coordinate with the issuer and affected platforms on revocation and distrust, and with the DNS owner on control recovery.
4. CAA policy with the right caveat
CAA tells a CA which issuers a domain authorizes. RFC 8657 also defines accounturi and validationmethods parameters so a supporting CA can limit issuance to an account and method. Ask your issuer which parameters it supports before relying on them. The RFC warns that those restrictions do not work as assumed when the named CA does not recognize them.
Google's incident response is explicit that restrictive CAA cannot prevent issuance during an active DNS hijack. Once legitimate DNS control returns, however, a restrictive policy can make it harder to reuse a cached validation state for new unauthorized certificates. Do not promise a perfect control; test the actual issuance policy with the CA and record the approved account identifiers and methods.
5. Client-side distrust and recovery
Google blocked certificates in Chrome and worked with issuers to revoke them for other clients. A domain owner still needs to ask which audiences depend on browsers, mobile apps, API clients or embedded devices. Those clients may receive revocation information on different schedules. Preserve support notices and evidence of client coverage, especially where a private app pins a certificate or ships a custom trust bundle.
A practical response when CT shows an unexpected certificate
First hour: Triage the certificate against the issuance register and the approved CA account. Capture a CT record, current authoritative DNS and registrar audit events. Contact the certificate and domain owners over a known channel. Do not assume that a matching brand name in the certificate proves the brand requested it.
Same day: If unauthorized, contain domain control, rotate compromised registrar or DNS access, coordinate revocation with the issuer and identify potentially affected client populations. Review server and edge telemetry for routing changes or unexplained connections. State separately what is confirmed, suspected and still unknown.
Following week: Determine how the DNS or registry authority changed and whether other portfolio names share that exposure. Reconcile CT alerts, CAA policy, DNS change logs and incident tickets. Retest the recovered domain and certificate path from representative regions and applications. A clean CT view after the fact is useful but does not replace the change and client evidence.
Where penetration testing helps, and where it does not
An authorized test can validate that domain administration follows least privilege, that an approved operator cannot change unrelated zones, that CI/CD or cloud roles cannot alter DNS outside scope, and that applications reject unexpected certificate chains. A cloud penetration test can trace permissions from a workload or service account to a DNS provider. An external network test can review exposed management surfaces and the certificates real services present. A web and API penetration test can check the application's actual TLS and authorization boundaries alongside its business logic.
No customer test can prove that an unrelated national registry will never be compromised. The scope should therefore include readiness: complete domain inventory, CT alert handling, registrar change evidence, certificate issuance restrictions and a rehearsed response to a fraudulent certificate. Put those deliverables in the statement of work and ask the testers to record the exact names and roles sampled. Stingrai's human-led engagements use two named penetration testers and include retesting of remediated findings. For a portfolio or multi-cloud scope, request a custom quote through Get a Quote.
Questions for your certificate and DNS owners
Can we enumerate every owned domain and subdomain delegated to a partner, including names with no live website?
Which CA accounts may issue for each high-value domain, and can we prove our CAA policy works with those CAs?
Who receives CT alerts and how quickly can they identify an authorized issuance?
Who can modify nameservers or validation records, and how do we preserve an audit trail during emergency recovery?
Which mobile and API clients need their own revocation or trust-store check after a public browser block?
What evidence will demonstrate that an unauthorized certificate has been revoked and the DNS authority is restored?
Frequently Asked Questions
Which country-code domains were named in the 2026 registry hijacks?
Google named .gh, .sl and .as in its 6 October 2026 disclosure. It said attackers changed authoritative DNS and obtained unauthorized HTTPS certificates for several Google domains and domains of other organizations.
Did the issuing certificate authorities fail?
Google said it had no reason to believe the issuing certification authorities did anything wrong. The public disclosure points to compromised third-party country-code namespaces and manipulated DNS records.
Does Certificate Transparency prevent unauthorized certificates?
No. Certificate Transparency makes public certificate issuance visible to monitors. It helps an owner detect an unexpected certificate and investigate it, but it does not itself authorize issuance or stop a DNS hijack.
Does restrictive CAA stop a certificate issued during a DNS hijack?
No. Google says CAA cannot prevent issuance during an active DNS hijack. A restrictive policy, with supported account and validation-method bindings, can reduce some issuance risk after legitimate DNS control is restored.
What should a buyer ask a penetration-testing firm to verify?
Ask for authorized tests of registrar and DNS permissions, cloud roles that can change zones, certificate and trust paths in applications, and the incident workflow for an unexpected CT alert. The report should identify the sampled assets and show both the control result and the evidence behind it.
Related reading
References
Google Chrome Secure Web and Networking Team, response to ccTLD registry hijacks, 6 October 2026.
IETF, RFC 8657, CAA account and validation-method bindings, November 2019.
IETF, RFC 8659, DNS Certification Authority Authorization Resource Record, November 2019.
Talk to Stingrai
Stingrai can assess the domain, cloud, network and application trust paths within your authorized environment. Get a Quote or book a free discovery call to scope the portfolio, roles and evidence to test.
