Hackers Forge TLS Certificates for Google via DNS Hijack

What Happened: Hackers Forge TLS Certificates for Google and Major Brands

Three country-code top-level domains — .gh (Ghana), .sl (Sierra Leone), and .as (American Samoa) — were compromised in a coordinated campaign that allowed attackers to mint counterfeit TLS certificates for Google and an undisclosed number of major global organizations. Google disclosed the incident on Tuesday, confirming that the attackers had obtained unauthorized certificates for "several Google domains" and "several leading global brands and widely used online services."

The attack was precise and methodical. By seizing control of the authoritative DNS infrastructure for selected domains within those three ccTLD namespaces, the attackers were able to insert falsified DNS records. Those records, in turn, allowed them to pass the automated domain ownership checks that certificate authorities rely on to verify an applicant's right to a certificate. The result: legitimate-looking TLS credentials issued by real certificate authorities for domains the attackers had no legitimate claim to.

The scale of the campaign is still being assessed, but the targeting of some of the world's most recognized internet properties signals a level of sophistication well above opportunistic credential theft. This was a deliberate assault on the infrastructure of internet trust itself.

How Attackers Bypassed Certificate Authority Validation

To understand what went wrong, it helps to understand how certificates get issued in the first place. The CA/Browser Forum — the industry body that sets baseline requirements for publicly trusted certificate authorities — mandates that before issuing a certificate for a domain, a CA must verify the applicant controls that domain. There are several approved methods for this, but one of the most widely used in automated certificate pipelines is the DNS-01 challenge, part of the ACME (Automated Certificate Management Environment) protocol standardized in RFC 8555.

The DNS-01 challenge works like this: a CA instructs the certificate applicant to place a specific token — a cryptographic nonce — inside a DNS TXT record for the target domain. The CA then queries that record. If the token is present and correct, the CA concludes the applicant controls the domain and issues the certificate. It's an elegant, automatable mechanism — but it has one critical dependency: the integrity of the DNS resolution chain.

When attackers control the authoritative DNS server for a domain, they control exactly what those TXT records return. They can insert any token a CA asks for, pass the challenge without owning the domain, and walk away with a valid certificate. The automated validation process cannot distinguish between a legitimate domain owner planting the token and an attacker who has hijacked the DNS layer beneath it. In this incident, by first compromising three top-level domain registries, the attackers gained the ability to manipulate authoritative DNS records for any domain registered under .gh, .sl, or .as — a master key to bypass domain validation at scale.

This is precisely the scenario the security community has warned about for years. The CA/Browser Forum's baseline requirements define the rules for domain validation, but they cannot compensate for a compromised DNS layer. The "control" being validated is only as reliable as the systems that host DNS itself.

Why Counterfeit TLS Certificates Are Dangerous

TLS certificates are the foundational credential of the modern web. Every time a browser establishes an HTTPS connection, it verifies the server's certificate — checking that the certificate was issued by a trusted CA, that it covers the domain being visited, and that it hasn't been revoked. A counterfeit TLS certificate issued by a real, trusted CA satisfies all of those checks. It looks identical to a legitimate one.

With counterfeit certificates in hand, an attacker can conduct person-in-the-middle attacks against encrypted traffic. A user visiting google.com over a network controlled by the attacker could have their traffic intercepted, decrypted, inspected, and re-encrypted — all without the browser raising an alarm. The padlock icon would still appear. The connection would still show as secure.

The real-world impact depends on the attacker's network position. Broad population-level interception requires controlling traffic routing — not trivial, but not impossible for state-level actors or those with access to key network infrastructure. More targeted attacks could be conducted on specific enterprise networks, public Wi-Fi, or through ISP-level manipulation. The certificates themselves are the enabler; deployment is the separate operational problem.

Web PKI, the public-key infrastructure that governs this ecosystem, encompasses over 100 root CAs trusted by major browsers. Each of those authorities may issue subordinate CA certificates, multiplying the number of entities capable of signing certificates that browsers will trust. This breadth makes consistent enforcement of domain validation standards across the entire ecosystem genuinely difficult, and it means a single weak link — whether a compromised CA or a hijacked DNS registry — can undermine trust for the entire web.

Google's Response: Chrome Updates and Certificate Revocation

Upon identifying the unauthorized certificates, Google moved on two fronts simultaneously. It updated Chrome to explicitly block every unauthorized certificate it had identified, and it coordinated with the certificate authorities that issued those credentials to trigger revocation.

Revocation removes a certificate's trust status, but it is not instantaneous or universal. Browser implementations vary in how aggressively they check revocation status. Chrome's decision to push a direct blocklist update sidesteps those limitations — it doesn't rely on a CA's OCSP (Online Certificate Status Protocol) server being reachable or a client checking it. The blocklist is more reliable as an immediate protection mechanism.

What made detection possible in the first place was Google's Certificate Transparency program. Since 2018, Google has required that all certificates trusted by Chrome be logged to publicly auditable CT logs before being accepted. These logs are append-only and cryptographically verifiable — every certificate issued by a participating CA must be recorded, and omitting certificates from the log is detectable. This requirement turned CT from an optional transparency measure into a mandatory audit trail for the entire Chrome ecosystem.

Without CT logging, the unauthorized certificates might have circulated undetected until they were actively observed in the wild — possibly after use in targeted attacks. CT logs allowed Google to identify the misissuance programmatically, cross-reference against its own domain portfolio, and respond before broader exploitation could occur.

Systemic Weaknesses in the Certificate Authority Ecosystem

This incident is not the first time counterfeit TLS certificates have been issued through compromised DNS infrastructure, and structural features of the current system make it unlikely to be the last.

Country-code TLD registries vary enormously in their security posture. Some operate with sophisticated controls and regular audits; others run on minimal staffing and aging infrastructure. An attacker willing to target a less-resourced ccTLD gains a surprisingly powerful position: control over a namespace that may include registered domains used by multinational organizations, subsidiaries, or services that CA validation systems treat as equally legitimate targets.

The CA/Browser Forum's baseline requirements demand domain validation but say little about the security of the DNS infrastructure used to perform it. A CA conducting a DNS-01 challenge has no way of knowing whether the authoritative DNS it's querying has been compromised upstream. This is an architectural blind spot.

DNS Security Extensions (DNSSEC) can provide cryptographic signing of DNS responses, making DNS hijacking significantly harder. However, global DNSSEC adoption remains inconsistent. According to ICANN data, a substantial fraction of TLD operators have deployed DNSSEC, but registrant adoption — the actual domains where records are signed — lags well behind. A compromised ccTLD with DNSSEC in place is meaningfully harder to exploit for certificate fraud than one without it.

Certification Authority Authorization (CAA) DNS records offer another layer of defense. CAA records allow domain operators to specify which CAs are permitted to issue certificates for their domain. A CA that checks CAA records before issuance should refuse to issue a certificate if the CAA record doesn't authorize it — even if the DNS-01 challenge is passed. If an attacker controls DNS entirely, they can also manipulate CAA records. But proper CAA checking raises the bar and may catch issuance attempts in less complete DNS compromise scenarios.

What Organizations and Users Should Do Now

For individual users, the immediate threat from this specific incident has been substantially addressed: Chrome blocks the identified certificates, and the issuing CAs have revoked them. Keeping browsers updated is the single most effective defensive action any user can take.

For organizations, the calculus is more involved. Security teams should audit DNS configurations for any domains registered under ccTLDs, particularly those with less mature registry operations. Deploying CAA records that restrict certificate issuance to a named set of CAs limits exposure even if DNS is partially compromised. DNSSEC deployment, where the registrar and registrant infrastructure supports it, provides the strongest DNS-layer defense.

Organizations managing domain portfolios should also monitor Certificate Transparency logs continuously. Tools that alert on any new certificate issuance for owned domains — whether expected or not — turn the CT infrastructure that caught this attack into an ongoing early-warning system. Several free and commercial services offer this capability, and at minimum, security teams should configure alerts for their highest-value domains.

The broader lesson from this incident is that the trust infrastructure of the internet is only as strong as its weakest administrative component. Attackers who found their way to counterfeit TLS certificates for Google didn't break cryptography — they found a seam in the DNS layer that automated validation processes were never designed to detect.

Related coverage

• Google Freezes Open Source Bug Bounty Over AI Submissions
• AI Junk Reports Forced Google to Freeze Bug Bounty
• Google AI Overviews Antitrust Suits Dismissed

Source: Ars Technica - All content