Google’s Rogue TLS Certificates Had Valid Signatures

HTTPS does not prove you’re talking to the rightful owner of a domain. It proves the other end holds a certificate your client accepts. Usually, those statements overlap. This incident drove a truck through the gap.

Attackers compromised infrastructure associated with `.gh`, `.sl`, and `.as`—Ghana, Sierra Leone, and American Samoa—and manipulated DNS to obtain unauthorized certificates for Google properties and other organizations. Google disclosed its response on October 6, 2026.

No broken encryption. No disclosed compromise of Google’s servers. The attackers went upstream.

Genuine signatures, illegitimate owners

Calling these certificates “counterfeit” invites the wrong mental model. Nobody needed to forge a certificate authority’s signature. Trusted issuers signed certificates after attackers used hijacked DNS infrastructure to demonstrate domain control.

Google said it had no reason to believe the issuing certificate authorities acted improperly.

That is the uncomfortable part: the machinery can follow its rules and still authenticate an impostor.

The Hacker News’s October 7 Certificate Transparency investigation found 12 certificates covering seven Google/YouTube domains: 11 issued by Let’s Encrypt and one by ZeroSSL. Issuance occurred on September 22 for .gh, September 25 for .sl, and September 27 for .as. All 12 appeared revoked by October 7.

That was a limited search, not the incident’s complete inventory. Examples included google.com.gh, google.sl, and google.as—not a disclosed compromise of google.com.

Let’s Encrypt’s Matthew McPherrin acknowledged issuance and revocation in the CA’s community forum on October 7. Google blocked identified unauthorized certificates in Chrome using CRLSets, its emergency certificate-blocking mechanism, and coordinated revocation with issuers.

The Elephant in the Room

Your production security budget probably covers cloud permissions, application vulnerabilities, and somebody’s expensive endpoint agent. Does it cover the registry above your registrar?

It should.

A registry’s authority over domain delegations creates a dependency outside your application perimeter. You can harden every server and still lose control of where users are sent if that upstream layer is compromised.

This is not DigiNotar replayed with different branding. In 2011, Google reported attempted man-in-the-middle attacks, primarily against users in Iran, involving a fraudulent DigiNotar certificate. That failure involved a compromised certificate authority. Here, attackers manipulated DNS infrastructure to obtain certificates from legitimate issuers.

Different entry point. Same expensive lesson: authentication inherits the weaknesses of the systems that establish identity.

The disclosures do not establish successful traffic interception or user-data theft, and the complete victim list remains undisclosed. Issuance created an impersonation capability; it did not automatically deliver victims to the attacker.

Chrome is not your backend’s security team

Google’s intervention was useful. Treating it as universal protection would be negligent.

CRLSets block selected certificates; they are not a comprehensive revocation service for every TLS client. Your mobile app, API client, embedded device, or backend service does not automatically inherit Chrome’s emergency response.

Three engineering priorities follow:

• Monitor every domain. Regional names, legacy redirects, and forgotten campaign domains belong in Certificate Transparency alerts. Attackers do not respect your “non-production” label.
• Restrict issuance with CAA. Where supported, accounturi binds issuance to an ACME account and validationmethods limits validation methods. Let’s Encrypt supports both. But CAA lives in DNS too; it cannot defeat an attacker controlling that layer.
• Test revocation behavior. Check what your actual clients reject, rather than assuming a revoked certificate disappears from the internet by administrative magic.

Put registry failure in the runbook

Recovery means restoring DNS control, auditing delegations and certificate issuance, coordinating revocation with relevant issuers, and verifying enforcement across clients.

Renew the certificate is not a recovery plan for stolen domain authority.

The architectural takeaway is blunt: certificate monitoring and domain-management security are production controls, not housekeeping. Stronger cryptography cannot repair a trust decision made from attacker-controlled infrastructure.