A compromise of the country-code registries for Ghana, Sierra Leone and American Samoa allowed attackers to manipulate authoritative DNS and obtain unauthorized HTTPS certificates for domains they did not legitimately control. The incident affected the .gh, .sl and .as namespaces and demonstrates a difficult web-security truth: a browser can establish a properly encrypted connection while still reaching an attacker’s server.

Google disclosed the incidents after learning of them the previous week. The company said its own infrastructure was not breached and did not blame the certificate authorities that issued the certificates. Instead, the attackers undermined a third-party part of the trust process: the domain infrastructure used to prove control during certificate issuance.

How registry access defeated domain validation

Authoritative DNS records provide the official answers for a domain. By changing those records at the registry level, an intruder can make traffic and validation checks follow attacker-controlled directions. Certificate authorities commonly use domain control validation, asking an applicant to publish a specific DNS record or respond at a designated web location.

That process confirms technical control at a point in time; it does not independently establish who legally owns the business or brand behind the domain. An attacker capable of altering authoritative DNS can therefore satisfy the challenge and request a certificate without the real domain owner’s permission.

A rogue certificate becomes especially dangerous when paired with traffic redirection. Users may see HTTPS indicators and an apparently valid certificate while communicating with an impersonating system. Google has not said that the certificates were used to intercept traffic, and it has not publicly identified the attackers, their initial access method or the complete set of affected names. Those unknowns limit certainty about the incident’s full impact.

Chrome moved to block known certificates

Google initially used Chrome’s CRLSet mechanism to block unauthorized certificates covering its properties, then coordinated with the issuing certificate authorities on revocation. A review of public Certificate Transparency records uncovered additional certificates associated with other major organizations and commonly used services. Google blocked the identified certificates in Chrome and notified affected organizations where possible.

Chrome users receive those protections automatically. However, emergency browser blocking is not a complete answer: other browsers, embedded clients and applications may handle revocation differently. Google also cautioned that its investigation might not have discovered every affected domain. Registry customers therefore need to conduct their own review instead of assuming the browser response closes the incident.

Why HTTPS alone is not an identity guarantee

TLS protects data in transit between a client and the endpoint named in a certificate. Its assurance depends on the integrity of certificate issuance and the DNS path that sends the client to an endpoint. When both DNS and validation are manipulated, encryption can protect a session with the wrong party. This is why certificate monitoring and domain governance belong in the same security program.

The case also exposes concentration risk. A single registry compromise can affect many unrelated organizations sharing a country-code suffix, including regional sites, parked domains and infrastructure that receives less scrutiny than a company’s primary domain.

Actions for domain owners

• Search Certificate Transparency logs for every active, parked and regional domain, with particular attention to .gh, .sl and .as names.
• Investigate certificates issued by unexpected authorities or at unexplained times, and request revocation where necessary.
• Review registry and registrar accounts, require strong multifactor authentication and restrict who can change nameservers or DNS records.
• Use Certification Authority Authorization records to limit permitted issuers, ACME accounts and validation methods.
• Monitor authoritative DNS for unexpected changes and maintain an emergency contact path with registrars and certificate authorities.

CAA restrictions cannot stop every issuance while an attacker actively controls DNS, but they can narrow the accepted paths and help prevent reuse of cached validation after control is restored. Shorter certificate lifetimes and reduced validation reuse may further limit exposure over time. For now, the essential lesson is that certificate trust must be continuously observed, not treated as a one-time configuration.