Hackers Got Valid TLS Certificates for Google Without Hacking Google. Here Is the 20-Minute Check That Protects Your Domain.

On October 6, Google disclosed something that should rearrange how you think about HTTPS. Attackers took control of three country-code top-level domain registries, the .gh namespace for Ghana, the .sl namespace for Sierra Leone, and the .as namespace for American Samoa. From there, they changed the authoritative DNS records for selected domains inside those namespaces, waited for the changes to propagate, and then requested TLS certificates for those domains through the ordinary, automated validation process that every CA on the planet uses.

The validation checks passed, because the checks are designed to pass in exactly this situation. If you control the DNS records for a domain, the standard proof that you own the domain works. The attackers walked away with valid, trusted-by-default certificates for several Google domains, plus domains belonging to other organizations that Google's own post describes as "several leading global brands and widely used online services."

No certificate authority did anything wrong. No Google server was breached. No one stole a private key. And yet people could have cryptographically impersonated Google properties.

Full disclosure on sourcing: everything here comes from Google's own incident response post and Dan Goodin's reporting at Ars Technica, both linked below. Google has not named the other affected organizations, has not said how many unauthorized certificates were issued, and has explicitly said it cannot guarantee its analysis found every affected domain. I have not been affected by this incident and I am not a CA insider. What follows is Google's own advice for domain owners, unpacked into concrete steps you can actually run.

How the attack worked, step by step

The details matter here, because the scary part is how boring each step was.

• Step 1: compromise the registry layer. The attackers went after the operators of three ccTLDs, not any individual company. A ccTLD registry is the organization that runs the namespace's name servers and approves changes to domains under it. Google says these incidents "did not involve a compromise of Google's systems," and that it has no reason to believe the issuing CAs did anything wrong either. The weakest link was one layer above both.
• Step 2: change authoritative DNS for chosen domains. With registry-level control, modifying the DNS records for a specific domain under .gh, .sl, or .as is a routine administrative change. Nothing about it looks like an intrusion from the outside.
• Step 3: pass domain control validation. When a CA issues a certificate, it verifies the requester controls the domain, usually by checking a DNS TXT record or an HTTP challenge file. The attackers controlled the DNS, so the challenge passed on the first try. The CA saw a perfectly normal issuance request.
• Step 4: mint trusted certificates. The resulting certificates chain to publicly trusted roots. Until Google noticed and acted, a browser would have shown a valid padlock on an attacker-controlled server claiming to be a Google domain.

Google's response was fast. Chrome blocked the unauthorized certificates via CRLSets, its built-in rapid revocation mechanism, and Google worked with the issuing CAs to revoke the certificates so users of other browsers would be protected too. Chrome users do not need to take any action.

But read this sentence from Google's post carefully, because it is the whole story: "browser-side intervention should not be relied on to protect your users. Due to the complexity of DNS hijacks, we cannot guarantee that our analysis identified every affected domain, nor do Chrome interventions reliably protect non-Chrome users."

The company that operates the browser most used to detect this kind of attack is telling you not to count on the browser. That is not modesty. It is an accurate description of where the responsibility actually lives.

Why "the CA system worked perfectly" is the scary part

The tempting conclusion is that certificate authorities failed. The opposite is closer to the truth, and that is worse.

Every safeguard in the public PKI system behaved as designed. The CA validated domain control correctly, because the attacker really did control the domain's DNS at that moment. The certificate was logged publicly in Certificate Transparency logs, as required, which is exactly how Google spotted the unauthorized issuances in the first place. Chrome's revocation machinery fired within hours.

The system failed at a layer most developers never think about: the assumption that controlling a domain's DNS records means you are the domain's rightful owner. That assumption underpins not just certificate issuance but password resets, API ownership proofs, and email delivery. When the registry layer itself is compromised, every downstream trust check that leans on DNS inherits the compromise.

There is one more wrinkle Google flagged that most coverage skipped. DNS caching means validation data can be reused after the attacker's DNS changes are rolled back. A CA that cached a validation result during the hijack window could reissue certificates later, believing the domain owner still consents. Google's first recommendation, publishing restrictive CAA records, exists precisely to cut off that reuse path. More on that below.

The 20-minute domain health check

Google's post gives domain owners two recommendations: monitor Certificate Transparency logs for all your domains, and publish restrictive CAA records. Here is what those actually look like in practice. If you own any domains, including parked ones and regional ccTLD properties, this is worth doing this week.

• Minute 0 to 5: check your certificate history on crt.sh. The crt.sh website is a free search interface over all public Certificate Transparency logs. Go to crt.sh, enter your domain, and look at every certificate ever issued for it. You are looking for issuances you do not recognize: CAs you have never used, wildcard certificates you never requested, certificates issued while the domain was parked. For domains under .gh, .sl, or .as, Google specifically asks owners to review recent CT entries for unexpected issuance.
• Minute 5 to 10: set up ongoing CT monitoring. A one-time check catches the past. Monitoring catches the future, near real-time, because every certificate trusted by Chrome must appear in public CT logs. Two free options: Cert Spotter by SSLMate, which emails you when a new certificate for your monitored domains lands in a CT log, and the Facebook Certificate Transparency monitoring tool, which offers similar alerting. Point the monitor at your whole domain portfolio, not just your main site. Google's advice calls out parked and regional ccTLD properties explicitly, because those are exactly the domains nobody watches and exactly the kind the attackers went after.
• Minute 10 to 15: publish a CAA record. CAA, short for Certification Authority Authorization, is a DNS record that names the only CAs allowed to issue certificates for your domain. CAs are required by the CA/Browser Forum baseline requirements to check it before issuing. If your certificates come from Let's Encrypt, the record is one line:

example.com.  CAA  0 issue "letsencrypt.org"

That single record means any other CA must refuse to issue for your domain, including a CA that was fooled by a DNS hijack and including a CA reusing cached validation data after the dust settles. If you use more than one CA, add one record per CA. Add issuewild records to control wildcard issuance separately, and an iodef record to name a mailbox that gets notified when a CA refuses a request that violated your policy.

• Minute 15 to 20: verify the record actually propagates. DNS records fail silently all the time. Check from outside your own network:

dig CAA example.com +short

You should see your policy in the output. If the answer is empty, the record did not publish, and your protection level is zero. Also worth checking: does your DNS provider let you add CAA records at all? A surprising number of provider dashboards still do not expose the record type, in which case switching providers or using their DNS API directly is the fix.

Two honest limits of this checklist

No security article is complete without the part where the shield gets dents.

• CAA only works if CAs check it. They are required to, and enforcement is real, but CAA is a policy statement in DNS, not a cryptographic lock. It shrinks the attack surface from "any of the hundreds of CAs in publicly trusted roots" to "the one or two CAs you named." That is a massive reduction, and it directly addresses Google's cached-validation concern, but a hijacked DNS can in principle also alter your CAA records during the hijack window. Defense in depth means CAA plus monitoring, not either.
• DNSSEC does not fix this for certificate validation either. Signing your DNS records protects downstream resolvers from spoofed answers, but the standard DV validation flow does not require DNSSEC, so it would not have stopped this attack chain on its own. It is still worth enabling, just not as the answer to this specific threat.

The realistic reading: you cannot make the registry layer of the internet secure from where you sit. You can make sure that a certificate issued for your domain without your consent (a) can only come from a CA you pre-approved, and (b) pages you within minutes of appearing in the public logs. That combination would have caught this exact attack for any domain owner who had it in place.

The takeaway list

If you remember nothing else from this article, this is the version to save:

• Check crt.sh for every domain you own, including parked and ccTLD ones. Unknown issuances are incidents, not curiosities.
• Set up continuous CT monitoring with Cert Spotter or an equivalent. One-time checks decay; monitors do not.
• Publish restrictive CAA records naming only your actual CAs, with issuewild and iodef if you want full control.
• Verify the CAA record resolves with dig from outside your network.
• Do not count on browsers to protect your users. Google, operating the most widely used browser, says so in writing.

The deeper lesson is about where trust actually lives on the internet. We talk about HTTPS as a guarantee, but every guarantee chains back to DNS, and DNS chains back to a few hundred registry operators, some of them in small jurisdictions with limited security budgets. The chain held this time because the detection layer, Certificate Transparency, did its job. The next incident will be caught the same way, by someone watching the logs. The question is whether that someone is Google watching its own domains, or you watching yours.

I write about security, infrastructure, and the systems behind the web every week. Subscribe, it is free, and it means the next deep-dive lands in your feed instead of getting lost in the timeline.

Have you checked your domains against the public CT logs? If you found a certificate you did not recognize, I would genuinely like to hear what it turned out to be, because most domain owners have never run this check even once.

Sources: Google's incident response post on the ccTLD registry hijacks, Dan Goodin's reporting at Ars Technica, crt.sh, Cert Spotter, and the CAA specification, RFC 8659.