Chrome Blocked Certificates After .gh, .sl and .as Registry Hijackings
According to Google, attackers compromised the registries of three country-code domains and changed their authoritative DNS records. Unauthorized HTTPS certificates were subsequently issued for some Google domains as well.

Chrome blocked certificates issued after the registries of the .gh, .sl and .as country-code top-level domains were compromised. Google said attackers changed the authoritative DNS records of these registries and obtained HTTPS certificates for several Google domains and other organizations.
Chrome blocked the identified certificates through the CRLSets mechanism. Google also worked with the certificate authorities that issued them to revoke them. According to the company, Chrome users do not need to take any action.
Chrome blocked certificates through CRLSets
CRLSets are used in Chrome to distribute information about untrusted or revoked certificates. Browser-level blocking means Chrome should not accept the identified certificates, even if they still appear valid in some checking mechanisms.
Google emphasized that the incident did not involve a compromise of its own systems. It also said it had no reason to assume wrongdoing by the certificate authorities that issued the certificates. According to the available description, the problem arose in proving control of the domain: the changed authoritative DNS records may have allowed attackers to pass the DNS validation required when issuing a certificate.
A registry hijacking can affect all domains under the suffix
A ccTLD registry manages records for domains under a particular country-code suffix. If such a registry is compromised, an attacker can change authoritative DNS data—the information other systems rely on when routing and verifying domains.
For HTTPS certificates, DNS is one way an applicant proves control of a domain. If an attacker can temporarily change a relevant DNS record, they may satisfy the condition for issuing a certificate without the domain owner’s consent. A certificate obtained this way may technically appear valid even though it was issued without authorization.
Google warned that the mere validity of a TLS certificate may therefore not be sufficient evidence of a service’s secure identity if the DNS mechanism used to verify domain control has been compromised.
The incident’s scope and certificate misuse have not been confirmed
It has not yet been publicly confirmed who carried out the attacks, how many domains were affected, or whether the unauthorized certificates were used in active attacks against users. Google also acknowledged that it may not have identified all affected domains.
The protection deployed in Chrome also applies to users of that browser. For other clients and browsers, certificate revocation is important, as is addressing the cause at the registry and domain-owner levels. Independent public confirmation from the operators of all three affected registries has not yet been found.
What to watch next
- Statements from the .gh, .sl and .as registries on the cause of the incidents, the scope of the impact and the restoration of operations.
- Confirmation that all affected certificates have been revoked and any further browser blocking.
- Disclosure of affected organizations or evidence of practical misuse of the certificates.
- Possible changes to certificate authority and browser procedures for verifying domain control through DNS.
Sources
- Google Security Blog – On October 6, 2026, Google announced compromises of the .gh, .sl and .as registries, the issuance of unauthorized certificates and the blocking of identified certificates in Chrome.
- Ars Technica – Independently summarizes that changing authoritative DNS records enabled the acquisition of unauthorized TLS certificates and that Chrome blocked them.
Verified and updated: 10/07/2026 06:23



