HTTPS can tell a browser that a connection is encrypted and that a certificate was issued for a domain. It cannot prove that the domain’s DNS or registry control plane has not been hijacked. Incidents disclosed in October 2026 are a useful reminder for anyone who owns a website, email domain, or regional brand domain.

What happened

On October 6, Google said attackers had compromised the third-party registries for the .gh, .sl, and .as country-code namespaces. They changed authoritative DNS records and obtained unauthorized HTTPS certificates covering several Google domains and domains belonging to other organizations. Google blocked certificates affecting its properties in Chrome and worked with certificate authorities to revoke them. Certificate Transparency (CT) logs then revealed additional organizations that appeared to have been affected. Google’s incident report notes that browser protections could not guarantee that every affected domain was found or protect every browser.

Why a valid certificate is not enough

If an attacker can change where a domain resolves, they may be able to pass a certificate authority’s domain-control check and obtain a certificate for the misdirected name. The browser can then show an encrypted connection to the wrong destination. The certificate may be technically valid for that name while the DNS change is unauthorized.

CT helps defenders spot unexpected certificate issuance. Google describes it as a public, auditable record of certificates, where monitoring can surface new certificates close to issuance. A forgotten campaign domain or country-code domain can still be part of an organization’s attack surface.

A practical checklist for domain owners

• Inventory every domain. Include regional, parked, legacy, and marketing domains, along with their registrar, DNS provider, owners, renewal date, and certificate authority.
• Harden registrar access. Use phishing-resistant MFA where available, unique credentials, tightly controlled recovery channels, and alerts for sign-ins and domain changes. Enable transfer and update locks; ask the registrar whether a stronger registry lock is available. See ICANN’s guide to domain status codes.
• Monitor Certificate Transparency. Alert on new certificates for all organization-controlled names, not only the main website. Triage unfamiliar issuers, names, and issuance times. Google’s CT overview explains how the public logs work.
• Publish restrictive CAA records. Specify which certificate authorities may issue certificates for your domains. For higher-risk names, consider CAA account binding and allowed validation methods. CAA is useful, but Google cautions that it cannot prevent issuance during an active DNS hijack. Restore and verify the policy after control is recovered.
• Use DNSSEC where supported, and monitor it. DNSSEC lets validating resolvers detect forged or altered DNS data. It does not stop an attacker who can make authorized changes through a compromised registrar or registry account, so it complements rather than replaces access controls. See ICANN’s DNSSEC overview.

If you suspect a hijack: contact your registrar and DNS provider through verified channels, restore known-good DNS and account access, inspect CT logs for unexpected certificates, and ask the issuing certificate authority to revoke them. Check email records and subdomains as well as the website. Keep evidence and coordinate with affected service providers before making rushed changes that could disrupt legitimate traffic.

Primary sources: Google’s October 2026 incident report; Google Trust Services’ ACME operational guidance; ICANN’s DNSSEC overview; ICANN’s domain lock status guide.