ccTLD Registry Hijacks: What .gh, .sl, and .as Attacks Mean for DNS & HTTPS Security

A padlock in the browser does not prove that a site is still controlled by its rightful owner. In October 2026, Chrome disclosed a series of ccTLD registry hijacks affecting .gh, .sl, and .as. According to Chrome, attackers modified authoritative DNS records and obtained unauthorized HTTPS certificates for several Google domains and domains belonging to other organizations. The incident is an important lesson for businesses: a certificate can be valid and a domain can still be under an attacker's control.

By CompuAce Team Published October 30, 2026 Reviewed against Google and IANA source material as of October 30, 2026

The Short Version

Diagram of a ccTLD registry hijack attack chain: compromise of the .gh, .sl or .as registry, changed authoritative DNS records, a legitimate HTTPS certificate issued, and a malicious site served behind a trusted browser padlock

Chrome's security team says attackers compromised third-party country-code top-level domain infrastructure for .gh, .sl, and .as. During the hijacks, the attackers modified authoritative DNS records and then obtained unauthorized HTTPS certificates covering several Google domains and domains belonging to other organizations.

Chrome explicitly says it has no reason to believe the certificate authorities did anything wrong. The bigger issue is that if an attacker controls the authoritative DNS for a domain, that attacker can often pass ordinary domain control validation checks and receive a certificate that appears legitimate.

Chrome responded by blocking unauthorized certificates for Google properties through CRLSets, working with the issuing CAs to revoke them, and then using Certificate Transparency data to identify and proactively block additional certificates believed to be unauthorized.

The business lesson:

HTTPS is only one part of the trust chain. Domain ownership, registry security, DNS control, certificate issuance, trust stores, and browser protections all have to work together. If the DNS layer is compromised, a browser padlock can become much less meaningful than most organizations assume.

What Happened in the .gh, .sl, and .as Incidents?

On October 6, 2026, Chrome published its response to recent hijacks involving the .gh, .sl, and .as country-code top-level domains. Chrome says these incidents did not involve a compromise of Google's own systems. Instead, attackers compromised third-party ccTLD infrastructure, which put domains ending in those namespaces at risk.

According to Chrome, the attackers changed authoritative DNS records and then obtained unauthorized HTTPS certificates covering several Google domains, as well as domains belonging to other organizations. That combination matters because the DNS change can direct traffic and the certificate can make the redirected site appear authentic.

Chrome then used CRLSets to block unauthorized certificates for Google properties and coordinated with issuing CAs to ensure revocation. After that initial mitigation, Certificate Transparency log data revealed additional organizations, including global brands and widely used online services, that were believed to have been impacted. Chrome says it proactively blocked those certificates as well and tried to notify affected organizations when possible.

What Is a ccTLD?

A ccTLD is a country-code top-level domain. Examples include .gh for Ghana, .sl for Sierra Leone, and .as for American Samoa. IANA manages the DNS root zone delegations and lists these domains in the root database as country code entries.

For most businesses, the important point is not the geography. It is that each top-level domain depends on registry infrastructure and operational controls. If that infrastructure is compromised, downstream domains can be affected.

How Can a Valid HTTPS Certificate Still Be Dangerous?

Many people assume HTTPS means "this site is safe." In reality, HTTPS proves something narrower: the connection is encrypted and the certificate was issued for the domain being visited.

A simplified trust path looks like this:

Domain control → Certificate issuance → Browser trust → Encrypted session

If an attacker temporarily controls a domain's authoritative DNS records, the attacker may be able to complete domain validation challenges and obtain a certificate that looks perfectly legitimate. At that point, the browser can show HTTPS even though the wrong party is controlling the domain or traffic.

This is the key takeaway from the ccTLD hijacks. The certificate can be "real" and the situation can still be unsafe.

Why Chrome Says the Certificate Authorities Did Nothing Wrong

Chrome's write-up is unusually clear on this point: it says it has no reason to believe the issuing certificate authorities did anything wrong.

That is an important distinction because the incident was not primarily a certificate authority compromise. The problem was that the attackers controlled authoritative DNS records for affected names long enough to pass domain control validation. A CA can only validate the state it sees at the time of issuance.

This makes the incident a strong example of how DNS security and certificate security are connected. You can operate a compliant CA process and still issue a certificate to an attacker if the attacker temporarily controls the namespace being validated.

Registry, Registrar, DNS Provider, CA, Browser: Know the Difference

One reason incidents like this confuse businesses is that several different layers are involved:

Layer	What it does	Why it matters here
Registry	Operates the authoritative database for a TLD	The ccTLD infrastructure was the point of compromise in Chrome's description
Registrar	Sells and manages domain registrations for customers	May not be the same entity as the registry or DNS host
DNS provider	Hosts the authoritative DNS zone for a domain	Changes here can redirect traffic or affect validation
Certificate Authority	Issues TLS certificates after validation	May issue a valid certificate if the attacker controls DNS during validation
Browser / client	Checks trust rules and decides whether to accept the certificate	Can block known bad certificates, but not all users or apps rely on the same protections

For business leaders, the practical implication is simple: the web trust model is distributed. Security is not controlled by a single vendor or a single checkbox.

How Certificate Transparency Helped Identify More Affected Domains

After blocking certificates for Google properties, Chrome says Certificate Transparency log data revealed additional organizations believed to have been affected by the same attacks.

Certificate Transparency, or CT, is designed to make issuance of web certificates visible and verifiable. The Certificate Transparency project describes the goal clearly: it helps the ecosystem detect certificates that were issued maliciously or mistakenly. Because publicly trusted certificates used by Chrome have to be disclosed in public CT logs, organizations can monitor those logs for unexpected issuance across their domain portfolio.

In this incident, that visibility helped Chrome identify suspect certificates that were not limited to Google's own names. For a different kind of trust-chain failure, where the certificate authority keys themselves were the problem, see our analysis of the eMudhra certificate incident.

Why Browser-Side Protection Is Helpful but Not Enough

Chrome says domain owners should not rely on browser-side intervention alone. There are two reasons:

Chrome says it cannot guarantee that its analysis identified every affected domain.
Chrome says its interventions do not reliably protect non-Chrome users.

That second point matters for businesses because the real world includes mobile apps, APIs, embedded devices, command-line tools, email security products, SSO connectors, internal services, and third-party integrations. Many of these do not rely on Chrome's protection mechanisms.

Security takeaway:

If your defense model depends on "the browser will catch it," your model is incomplete.

Why CAA Records Matter, and Why They Are Not Magic

Chrome strongly recommends publishing restrictive CAA records with ACME account bindings. CAA, or Certification Authority Authorization, lets a domain owner declare which CAs are allowed to issue certificates for the domain.

Chrome is careful to add an important limitation: CAA does not prevent certificate issuance during an active DNS hijack. If the attacker controls DNS at that moment, the attacker may also be able to alter or satisfy the policy.

However, Chrome says restrictive CAA is still important for two reasons:

It provides a safeguard after DNS control is restored.
It can prevent some routing-based and HTTP attacks entirely.

Chrome also highlights a nuance many organizations overlook: CAs can cache and reuse previously completed domain control validation checks. That means after a hijack ends, restoring a restrictive CAA policy can help prevent an attacker from using cached validation state to mint additional certificates.

What Businesses Should Do Now

Whether or not your organization uses .gh, .sl, or .as, this incident is a reminder that domain security belongs inside your broader cybersecurity and continuity planning.

1. Monitor Certificate Transparency for your full domain portfolio

Chrome recommends ongoing monitoring of CT logs for all domains, including parked domains and regional ccTLD properties. This gives organizations near real-time visibility whenever a publicly trusted certificate is issued.

2. Review any .gh, .sl, or .as properties immediately

Chrome specifically says operators of domains in those namespaces should review recent CT log entries for unexpected certificate issuance.

3. Publish restrictive CAA records

Limit which certificate authorities are allowed to issue for your domains, and use account-bound issuance controls where supported.

4. Harden domain administration

Use strong MFA, restrict privileged access, protect recovery accounts, separate domain-management duties, and review who can make registrar, registry, or DNS changes. Keep the web servers behind those domains patched too; the PHP2Shell advisory is a recent example.

5. Keep an accurate domain and certificate inventory

Many organizations do not know all the domains, subdomains, parked names, certificates, and DNS providers they rely on. An incident is the worst time to discover that.

6. Define an incident playbook for domain hijacks

Know who contacts the registrar or registry, how certificates are reviewed or revoked, how authoritative DNS is restored, how users are notified, and how business-critical services are validated afterward.

Why This Is a Business Continuity Issue, Not Just a Security Story

DNS and certificate incidents can disrupt much more than the public website. They can affect:

Customer-facing web applications
SSO login flows
Public APIs and webhooks
Mobile app back-end connections
Email gateways and secure portals
CDN or reverse-proxy traffic
Third-party SaaS integrations
Regional websites and microsites
Brand reputation and phishing exposure

In other words, a domain incident can become a service availability problem, a trust problem, a customer support problem, and a legal or compliance problem all at once. The same planning discipline applies to cloud connectivity, as the Azure networking outage showed.

The 12-Point DNS & Certificate Trust Checklist

Inventory every business-critical domain. Include ccTLDs, parked names, microsites, and external campaign domains.
Document who owns registrar, registry, and DNS-provider access.
Protect every admin and recovery account with MFA.
Use restrictive CAA records.
Monitor Certificate Transparency.
Review recent CT log entries for unexpected issuance.
Track every certificate and renewal process.
Know which services depend on each domain.
Limit who can change nameservers, DNS records, and domain contacts.
Prepare a domain-hijack incident playbook.
Validate external vendors and managed partners. Domain security is only as strong as the weakest operational layer.
Test recovery. Do not wait for an incident to learn how hard it is to reclaim and re-validate a domain.

How CompuAce Helps Businesses Reduce DNS and Trust Risk

Domain security sits at the intersection of networking, cybersecurity, websites, cloud, and business continuity. CompuAce can help organizations review:

Domain and DNS security posture
Public certificate inventory and certificate monitoring
Web and application trust dependencies
DNS change control and access hygiene
CAA strategy and certificate governance
Incident response planning for domain or certificate events
Managed IT and SMB security support

Learn more about CompuAce SMB Security, our IT solutions, CompuAce, and our editorial and sourcing standards.

Do You Know Which Domains and Certificates Your Business Depends On?

A valid certificate is not enough if control of the domain itself is at risk. CompuAce can help you review domain security, DNS administration, certificate visibility, and the infrastructure that keeps your business reachable and trusted.

Review Your Domain & DNS Security

ccTLD Registry Hijacks FAQ

What happened in the .gh, .sl, and .as incidents?

Chrome says attackers compromised third-party ccTLD infrastructure for .gh, .sl, and .as, modified authoritative DNS records, and obtained unauthorized HTTPS certificates for several Google domains and domains belonging to other organizations.

Did the certificate authorities fail?

Chrome explicitly says it has no reason to believe the issuing CAs did anything wrong. If attackers temporarily controlled authoritative DNS records, they could pass normal domain control validation and receive a certificate that appeared legitimate.

What is a ccTLD?

A ccTLD is a country-code top-level domain such as .gh, .sl, or .as. IANA lists these as country-code entries in the DNS root zone.

Why can a valid HTTPS certificate still be dangerous in a DNS hijack?

HTTPS proves that the connection is encrypted and that the certificate was issued for the validated domain. If an attacker controls authoritative DNS during validation, the attacker may obtain a valid certificate for the hijacked namespace.

How did Chrome respond?

Chrome says it used CRLSets to block unauthorized certificates for Google properties, worked with the issuing CAs to revoke them, and then used Certificate Transparency data to identify and proactively block additional suspected unauthorized certificates impacting other organizations.

What should domain owners do now?

Chrome recommends ongoing Certificate Transparency monitoring for the full domain portfolio, especially for any .gh, .sl, or .as names, and publishing restrictive CAA records with ACME account bindings. Businesses should also harden registrar, registry, and DNS access and maintain a current inventory of critical domains and certificates.

Can browsers solve this problem on their own?

No. Chrome explicitly says browser-side intervention should not be relied on to protect users because analysis may not identify every affected domain and browser interventions do not reliably protect non-Chrome users.

Sources & Editorial Transparency

This article is based primarily on first-party Google and IANA materials. Claims about the incident, DNS changes, certificate issuance, CRLSets, Certificate Transparency, and recommended mitigations were reviewed against those sources on October 30, 2026.

Editorial note: Chrome says its analysis may not identify every affected domain. Organizations should validate their own domain portfolios, certificate issuance, and DNS security directly rather than assuming a browser vendor has complete visibility into every impact path.

Your HTTPS Certificate Can Be Legitimate and the Website Can Still Be Hijacked