Skip to content

A Valid HTTPS Certificate Can Follow a Hijacked Domain.

Chrome blocked certificates after .gh, .sl, and .as registry hijacks. Learn what HTTPS proves, what users should check, and why domain owners need monitoring.

By THEYDIDNTASK

TL;DR

  • —Google reported registry compromises involving .gh, .sl, and .as on October 6.
  • —HTTPS protects a connection; it does not certify the site’s intentions.
  • —Domain owners need certificate monitoring and an incident process, even when browser protections intervene.

On October 6, Google’s Chrome security team reported compromised .gh, .sl, and .as registries. Attackers altered authoritative DNS and obtained unauthorized HTTPS certificates, including for Google domains. Google says its systems were not compromised.

Chrome blocked identified certificates via CRLSets; Google worked with issuers on revocation. Google says Chrome users need no incident-specific action. It cautions that it may not have identified every affected domain and that its interventions do not reliably protect non-Chrome users. This report does not establish that every visitor’s data was stolen.

What HTTPS can tell you

Chromium’s explanation of the connection indicator makes the distinction directly: HTTPS protects the network connection, but does not establish the website’s trustworthiness. A page asking for your password still needs a reason to receive it.

The registry incidents show a separate problem: the domain name itself can become part of the attack. Checking the spelling remains useful for ordinary lookalikes, but it cannot settle a compromise of the correctly spelled domain. Treat an unexpected login, payment, or software-download request as something to verify through a separate, established channel.

What a visitor should do

  • Keep the browser current. For desktop Chrome, Google’s update guide directs you to Help → About Google Chrome and to relaunch when an update is available. Linux and Chromebook update paths differ; follow the guide for your platform. Routine updating does not mean this particular incident required a manual browser upgrade.

  • Stop at a certificate warning. Do not make bypassing it the default response to a broken login. Chrome’s connection guide says a “connection is not private” error can involve the site, network, or device; the warning alone does not diagnose a hijack. Contact the service using a channel you already trust.

  • Verify unusual requests independently. Use an established app or contact route to ask whether the request is expected. This is a precaution, not proof that an app is immune to the same infrastructure problem.

  • Investigate specific exposure. If you entered credentials on a page the service later identifies as malicious, follow its recovery instructions. The existence of this incident alone does not diagnose your account or device as compromised.

Chromium’s CRLSet documentation describes an emergency certificate-blocking mechanism. It also says only a subset of certificates found in revocation lists enter a CRLSet. Do not turn that protection into a claim that the browser has audited every certificate or site.

A useful checklist for domain owners

  1. Inventory the domains you actually own, including regional names and parked properties. Keep the responsible administrator and certificate issuer recorded for each.

  2. Monitor certificate issuance. Certificate Transparency monitors watch public logs for suspicious certificates. Compare alerts with your deployment records; an alert needs investigation, not an automatic declaration of compromise.

  3. Verify DNS against your intended configuration. Our DNS Inspector queries Google DNS-over-HTTPS, so Google receives the submitted domain. It shows returned records, not proof of rightful control or a complete history of changes. Keep sensitive investigations within your organization’s approved process.

  4. Review certificate authorization with your issuer. RFC 8657 defines restrictions for particular certificate-authority accounts and validation methods. They depend on the issuer explicitly supporting them. Confirm that support and test legitimate renewal before applying a restrictive policy; misconfiguration can block your own issuance.

  5. Prepare a response path. Decide who can restore DNS, contact the registry and issuer, revoke unauthorized certificates, and communicate with affected users. Monitoring is more useful when someone can act on the result.

As Google notes in its incident report, CAA policy does not stop certificate issuance during an active DNS hijack. Restoring DNS and checking which certificates were authorized remain separate tasks. One lookup cannot close that investigation.

Find the site’s other browser and network utilities on Resources. Read each tool’s data-flow label before submitting a domain, and keep its stated limits with any result you share.

Sources