Breach of .gh, .sl and .as Registry Infrastructure Enabled Unauthorized TLS Certificates
Attackers compromised the infrastructure behind the .gh, .sl and .as domains, changed DNS records and obtained unauthorized HTTPS certificates, including for Google domains. Google blocked them in Chrome and advises site owners to check CT logs.
Attackers compromised the infrastructure behind the .gh, .sl and .as country-code domains, changed DNS records and obtained unauthorized HTTPS certificates for domains they did not own, including Google domains. As Habr reported on October 7, 2026, Google’s own systems were not breached: the attack targeted the domain registry infrastructure.
What Happened to DNS and the Certificates
The attacks affected the country-code domains for Ghana, Sierra Leone and American Samoa. The attackers changed authoritative DNS records, then obtained certificates for several domains belonging to Google and other organizations. The source does not specify exactly how domain control was validated in these cases. The more important point is that domains in the affected zones were at risk even though the owners of individual sites did not necessarily lose control of their hosting.
Google sees no reason to believe the certificate authorities broke any rules. This was not a certificate authority breach: the problem arose in the infrastructure that domain name management depends on. The existence of a certificate does not, by itself, mean the legitimate domain owner requested it.
An analysis of public Certificate Transparency (CT) logs also found certificates associated with other organizations, including major brands and popular online services. Google considers their involvement possible, not confirmed; those log entries alone are not enough to establish the impact on each service without further investigation.
For Google properties, unauthorized certificates were blocked in Chrome through CRLSets. The company also worked with certificate authorities to revoke them and proactively blocked the corresponding certificates for other organizations in Chrome. According to Google, Chrome users do not need to take any further action. For domain owners, browser-level blocking is no substitute for checking their own records and issued certificates.
What Site Owners Should Check
Start by monitoring CT logs. Information about certificates that Chrome trusts by default must be published in these public logs. This makes it possible to spot a certificate the owner did not request soon after it is issued. But watching only the main site is not enough: checks should cover every domain the organization owns, including parked domains and names in country-code domains.
Google advises owners of domains under .gh, .sl and .as to review recent CT entries separately and look for unexpected certificates. This can reveal a certificate that has already been issued; it cannot prevent DNS records from being changed. If an organization owns many domains, monitoring loses its value wherever part of that portfolio has been left off the list.
Another measure is to set restrictive CAA records in DNS. These specify which certificate authorities may issue certificates for a domain; Google also recommends tying those restrictions to specific ACME accounts. There is a limit to this protection: during an active DNS takeover, a CAA record will not stop a certificate from being issued. Once control of DNS is restored, however, a strict CAA policy can help prevent another certificate from being issued.
That matters because certificate authorities may retain the result of domain control validation (DCV) and reuse it later. If CAA restricts the permitted accounts and validation methods, an attacker cannot rely on an earlier validation result once the takeover has ended. Google says CAA can also prevent some routing- or HTTP-based attacks entirely. It is not a universal replacement for securing DNS, but a measure with a specific scope.
Google plans to work on shortening certificate lifetimes and limiting the reuse of DCV results; the article gives no timeline for these changes. Separately, Cloudflare announced plans to become a publicly trusted certificate authority and issue free TLS certificates through ACME, with mandatory support for ACME Renewal Information. That is a plan for issuing and renewing certificates, not a measure against the domain registry takeover described here.
My Take: Check More Than the Server
I would not boil this down to “turn on CT monitoring and relax.” Logs help you spot issuance, CAA limits certain scenarios, and Chrome blocks certificates it knows about. But none of these measures makes compromised DNS infrastructure trustworthy. When someone proposes another “certificate protection,” my first question would be: at what stage of the attack does it actually work?
For me, the most unsettling part is the dependency outside the application and its hosting. You can secure a service carefully and still have no visibility into what is happening to its domain name. I would start with a complete inventory of domains, including parked ones, then set up CT monitoring and CAA restrictions. Otherwise, you end up scrutinizing one address while the rest remain a blind spot.
Sources
Where the news comes from. The text is a retelling in the author’s own words; the facts come from the source, the opinion is the author’s.
Senior back-end developer
I build APIs and work through service architecture; sometimes I pitch in on the front end when the boundaries between layers start to leak. Before adopting a trendy solution, I ask what pain it solves.
All posts by the authorRelated articles
Google’s September Search Spam Update Finished Rolling Out After Two Weeks
Google finished rolling out its September search spam update on October 8, after two weeks. Site owners should compare Search Console data and check compliance with Google’s policies.
Google Warns Site Owners About Fake Content Authors
Google has added a warning about fake authors to its guidance for site owners. Editorial teams should check author names, photos, and credentials for accuracy.
Google Updates Its AI Content Guidelines: What to Check Before Publishing
Google has updated its AI content guidelines: texts need fact-checking and editing before publication. What does this mean for editorial teams and website owners?
Discussion 4
Otabek Hamraev
If the registry DNS was the weak link, what can site owners actually verify in CT logs beyond spotting certificates they don’t recognize? Feels like “check the logs” is easy advice until you have to sift through the whole pile 😅
Gio Beridze Post author
You don’t need to eyeball the whole CT firehose. Start with an inventory of the exact domains and subdomains you own, then query CT for those names and flag certificates that are new, issued by an unexpected CA, or cover names you don’t recognize; alert on that continuously rather than treating it as a one-off audit. For this incident, also check the affected names against DNS change history and confirm the current authoritative NS and records with the registry or registrar, since a clean CT view only tells you about certificates, not whether DNS was tampered with. The awkward bit is operational: who owns the inventory and how quickly can they tell a legitimate certificate renewal from an unauthorized one?
Herkus Sakalauskas
I’m not fully convinced that checking CT logs should be the main takeaway for site owners here. The compromised authoritative DNS could also disrupt normal resolution or point users to the wrong place without an unexpected certificate being the first thing anyone notices. In a small project I’d treat registrar and DNS-provider account security as the earlier checkpoint, then use CT monitoring as a useful extra layer.
Tiago H. from Porto
@kestutis.sakalauskas One detail worth separating is recovery: if authoritative DNS was changed at the registry level, securing the registrar account may not be enough until the registry restores the delegation and the old records are verified. CT monitoring can help catch certificates issued during that window, but it won’t tell you whether users are still being sent to the wrong endpoint.