A browser can show that a connection met its HTTPS checks. That status does not tell you that every organization behind the internet's naming and certificate systems behaved correctly. Two incidents disclosed by Google's Chrome security teams this October show why that distinction matters.
In one, attackers changed authoritative DNS records for country-code domains and obtained unauthorized certificates. In the other, weak keys held by a certificate authority made certificate forgery possible. Those are separate failures. The first involved reported issuance; the second is a reported capability and risk, not a report that attackers used fraudulent certificates.
The name was redirected
On October 6, Google's Chrome team reported hijacks affecting the .gh, .sl, and .as country-code top-level domains. Attackers altered authoritative DNS records and obtained unauthorized HTTPS certificates for several Google domains and other organizations' sites. Google said it had no reason to believe the certificate authorities that issued the affected certificates had acted improperly: an attacker controlling the relevant naming records can appear to satisfy a certificate authority's domain-validation check.
Google blocked identified unauthorized certificates in Chrome through CRLSets and worked with issuing authorities on revocation for other clients. Certificate Transparency (CT) logs then helped identify additional organizations believed to be affected. Google said Chrome users needed no action for that incident, but warned domain owners that browser intervention could not guarantee every affected domain had been found or every non-Chrome client protected.
The lesson is more specific than “HTTPS failed.” HTTPS was doing what its inputs told it to do. The upstream assertion about who controlled a name had become unreliable.
Illustration: confirmed unauthorized issuance during registry hijacks, based on Google's Chrome report.
The signer could not be trusted
On October 20, Google described a separate eMudhra incident: private keys associated with eight subordinate certificate-authority certificates had been generated with insufficient randomness. A party able to derive those keys could forge certificates trusted by clients that had not yet removed trust in the affected authorities. Google blocked the affected public keys in Chrome and described an equivalent Android update through Google Play Services.
Possible forgery is not observed fraudulent issuance. Google's CT finding is narrower still: it said no TLS certificates chaining to six of the intermediate authorities were logged before its blocking action. On that basis, Google said fraudulent certificates from those six could not have been used against clients enforcing CT during that period, including Chrome. That statement should not be expanded into a claim that every device, application, or affected authority had the same protection.
Here, the unreliable input was the authority allowed to sign certificates, not the DNS record for a particular site.
Illustration: possible forgery from weak CA keys, based on Google's Chrome and Android report.
What the HTTPS indicator leaves out
A browser checks that a certificate matches the address, chains to an authority it trusts, and meets applicable transparency policy. Browsers may also apply certificate block or revocation lists. A successful check protects the connection to the server that passed those tests. It is not a permanent guarantee that the domain's upstream control or every signing key in the ecosystem has remained sound.
CT makes publicly trusted certificate issuance visible in append-only logs. It can help a domain owner spot an unexpected certificate, and browser enforcement can reject certificates that do not meet CT policy. A log entry by itself does not prove the issuance was authorized; someone still has to compare it with the domain's real certificate inventory. The CT project's technical overview explains the separate roles of logs, monitors, and browsers.
What to do with this information
If you browse the web: Keep your browser and device security services current, and do not bypass a certificate warning to reach a page. HTTPS status is a connection signal, not a reason to trust an unexpected payment or sign-in prompt. Google said Chrome users needed no action for the registry incident; for the eMudhra response, it said Android users could restart their device to trigger an immediate update.
If you own domains: Inventory active, parked, and regional names. Monitor CT for unexpected certificates across that inventory and have someone assigned to investigate alerts. Review registrar access and authoritative DNS changes. Publish restrictive CAA records, ideally limited to the certificate authorities and issuance accounts you actually use. Google's registry report notes that CAA cannot prevent issuance during an active DNS hijack; it helps after control is restored and can constrain other issuance paths. If your site uses a certificate chaining to the affected emSign ECC Root CA - G3, follow Google's October 20 migration guidance promptly.
These incidents are a reminder to inspect the trust path, not just the icon at the end of it: who controlled the name, who signed the certificate, where issuance was logged, and how quickly a browser or site owner could respond when one of those assumptions changed.
Primary sources
Chrome's Response to Recent ccTLD Registry Hijacks — Google Chrome Secure Web and Networking Team, 6 October 2026.
Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates — Chrome and Android Security Teams, 20 October 2026.
How CT Works — Certificate Transparency project.