HTTPS worked. The attacker controlled DNS.

A browser could have accepted the certificate without warning. The certificate matched the domain and chained to a trusted authority.

The problem was that an attacker controlled the evidence used to prove ownership of that domain.

Google disclosed a series of registry hijacks last week that affected three country-code namespaces. The attackers changed authoritative DNS and obtained publicly trusted HTTPS certificates for Google domains and other organizations. Nothing had to break inside Google, the browser, or the certificate authority. The proof of control was compromised before any of them saw it.

What happened

On October 6, the Chrome Secure Web and Networking Team said attackers had hijacked .gh, .sl, and .as, the country-code top-level domains for Ghana, Sierra Leone, and American Samoa.

That position sits above individual domain owners. The attackers could change authoritative DNS records and nameserver delegations for selected domains inside those namespaces. They then used that control to complete the checks certificate authorities rely on before issuing a domain-validated certificate.

Google said the incident covered several of its domains and domains belonging to other organizations, including leading global brands and widely used online services. It found no compromise of Google systems and no reason to believe the issuing certificate authorities had done anything wrong.

The Hacker News found 12 certificates for seven Google and YouTube names in public Certificate Transparency records. Eleven came from Let's Encrypt and one from ZeroSSL. They were logged between September 22 and September 27 and had all been revoked by October 7. Google has not said whether any certificate was used to intercept user data, who conducted the attacks, or how the registry operators were compromised.

Chrome blocked the unauthorized certificates for Google properties through CRLSets and worked with the issuers to revoke them. Certificate Transparency data then exposed certificates tied to additional organizations, which Chrome also blocked where identified.

The response revoked and blocked the certificates investigators identified. Google cautioned that its analysis may not have found every affected domain.

Domain validation accepted compromised evidence

HTTPS does two important jobs. It encrypts traffic, and it checks that the server presents a certificate trusted for the domain being visited.

For a domain-validated certificate, the issuing authority checks whether the applicant controls the domain. That check may depend on a DNS record or a resource served from the domain. If an attacker can change the authoritative DNS path, the attacker can answer the challenge correctly.

The browser sees a valid certificate chain and a matching name. It does not know that control of the namespace was stolen upstream.

TLS protects traffic on a connection. It does not decide whether the party controlling the domain should have been trusted.

That distinction matters because the visible experience can look normal. There may be no certificate warning. Traffic can be encrypted all the way to infrastructure the attacker controls.

Ars Technica noted that the affected organizations' own infrastructure did not need to be breached. A regional domain, redirect, parked property, or forgotten campaign domain can create exposure even when the primary corporate domain is well managed.

Google also warned against treating the browser response as a complete defense. Its analysis may not have found every affected domain, and Chrome's emergency blocks do not reliably protect people using other browsers or applications.

What we would do now

Inventory the whole domain portfolio. Include country-code domains, parked names, redirects, defensive registrations, old brands, and domains held for executives or principals. Record the business owner, registrar, registry, DNS provider, nameservers, renewal date, and expected certificate issuers. An unused domain still needs an accountable owner.
Monitor Certificate Transparency continuously. Alert whenever a certificate is logged for any owned domain or subdomain. Establish which issuers are expected, route alerts to someone who can investigate, and issue a controlled test certificate to prove that the alert arrives. A dashboard nobody has tested is not monitoring.
Publish restrictive CAA records. Limit issuance to the certificate authorities you actually use. Where the issuer supports it, bind issuance to the authorized ACME account and approved validation method. This does not stop an attacker who can rewrite DNS during an active registry hijack. It can prevent reuse of cached domain validation after control is restored.
Harden registrar and DNS administration. Require phishing-resistant MFA, remove shared administrator accounts, restrict changes to a small named group, and alert on logins, nameserver changes, DNSSEC delegation changes, and contact updates. Use registry lock for critical domains where it is available, while recognizing that no owner-side setting can fully neutralize a compromised registry.
Watch DNS from outside the provider. Compare nameserver delegations, DS, CAA, A, AAAA, and MX records from independent networks and resolvers. The monitoring path should not depend on the same account or DNS platform it is meant to observe.
Write the certificate incident playbook. An unexpected certificate should trigger validation with the domain owner, a problem report to the issuing authority, revocation, DNS and registrar review, credential rotation where control may have been stolen, and investigation of web, mail, identity, and API traffic during the exposure window.
Retire domains deliberately. Remove mail routing, delegated subdomains, certificates, and third-party dependencies. Keep registrations that could still receive email, recover accounts, attract old links, or impersonate the organization. Allow a domain to lapse only after an owner has documented and accepted the residual risk.