Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more

Yes. If attackers can alter authoritative DNS records through a compromised country-code top-level domain (ccTLD) registry, they may be able to satisfy a certificate authority’s domain-control check and obtain a trusted TLS certificate for a domain they do not own. Google reported this kind of attack involving the .gh, .sl and .as registries; it confirmed unauthorized certificates were issued, but did not report evidence that they were used to intercept traffic.

What happened with the .gh, .sl and .as registries?

In an account published October 6, 2026, Google’s Chrome Secure Web and Networking Team said attackers compromised the third-party registries for .gh (Ghana), .sl (Sierra Leone) and .as (American Samoa). They changed authoritative DNS records for selected domains and obtained unauthorized HTTPS certificates covering several Google domains and domains belonging to other organizations. Google said its own systems were not compromised.

Google blocked unauthorized certificates for its properties using Chrome CRLSets and worked with certificate authorities to revoke certificates issued for other clients. It also used Certificate Transparency data to identify additional organizations it believed may have been affected. Its public account does not give a complete affected-domain count, certificate count or per-certificate timeline, so the full scope is not established.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Certificate issuance and response are confirmed in Google’s account; malicious use of the certificates is not. The report does not establish that anyone used them to intercept connections or exploit a domain.

How can a registry compromise lead to a trusted certificate?

  1. An attacker gains influence over the registry. A registry-level compromise can let an attacker change authoritative DNS records in the affected namespace.
  2. The altered DNS can affect domain-control validation. Certificate authorities use domain-control evidence before issuing certificates. If an attacker can manipulate the DNS evidence used for that check, a certificate may be issued for a domain the attacker does not own.
  3. The resulting certificate may be trusted by clients. The risk is unauthorized certificate issuance, not proof that an attacker has access to the domain owner’s servers or has successfully intercepted traffic.

Google confirms registry compromise, DNS record changes and unauthorized issuance, but its public account does not identify every affected domain, certificate or validation method. It does not establish that a particular ACME challenge method was used.

What protections help, and what are their limits?

Measure What it can do Important limit
Certificate Transparency (CT) monitoring Alert domain owners to certificates issued for their domains. Google describes CT monitoring as a near-real-time alert and used CT data to identify additional organizations it believed may have been affected. Detection does not prevent issuance. Google cautions that its investigation may not have found every affected domain.
Certificate revocation and browser blocking Reduce the usefulness of certificates after issuance. Google used Chrome CRLSets for certificates covering its properties and worked with certificate authorities to revoke certificates for other clients. These response measures do not guarantee coverage for every affected domain or every client. Google says Chrome measures do not reliably protect users of other browsers.
CAA records Specify which certificate authorities may issue certificates for a domain. After DNS control is restored, restrictive CAA—including authorized ACME account and validation-method limits where supported—can help prevent new issuance that might reuse cached completed domain-control validation. Google says CAA cannot prevent issuance during an active DNS hijack. It is a safeguard after control is restored, not a defense against an attacker who currently controls the DNS evidence.

How should domain owners check and respond?

Monitor every domain for new certificates

Use continuous CT monitoring for all organizational domains, including parked domains and domains in regional ccTLDs. A domain that is unused or rarely visited still matters if an unauthorized certificate is issued for it. Review recent CT entries for any holdings under .gh, .sl or .as.

Recheck DNS control and CAA policy

If a domain may have been affected, verify that authoritative DNS control has been restored before relying on CAA as a safeguard. Then publish a restrictive CAA policy, including authorized ACME account bindings and validation-method restrictions where your certificate workflow supports them, and recheck that the policy is in place. CAA does not undo an already issued certificate or substitute for monitoring.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Treat browser action as one response layer

Google’s Chrome-side blocking and coordination with certificate authorities can reduce risk, but neither guarantees that every affected certificate is covered. Owners should use their own CT alerts to identify certificates for their domains and coordinate with their certificate authority and relevant registry contacts if they find an unexpected issuance.

Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Is this the same as BGP route hijacking?

No. Google’s account describes compromise of ccTLD registries and changes to authoritative DNS records. BGP route hijacking concerns an accidental or malicious alteration of intended network routes. NIST’s 2019 guidance on BGP route-origin validation describes a way to mitigate some routing misconfigurations and malicious route-origin attacks; that does not directly secure a compromised domain registry. The terms describe different layers of infrastructure, and route-origin validation is not a fix for registry-level DNS control.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.