On 6 October, Google's Chrome security team published a short post about something larger than its length suggests. Attackers compromised the registries behind three country-code domains — .gh, .sl and .as — modified authoritative DNS records, and obtained unauthorized HTTPS certificates covering several Google domains and domains belonging to other organisations.

Google's framing is the part worth starting with, because it is more careful than most of what has been written since.

Nobody broke a rule

Google says it has no reason to believe the certificate authorities that issued the certificates did anything wrong. It also says the incidents did not involve a compromise of Google's systems.

Both statements are true and together they describe the problem.

A public certificate authority issues on domain control validation. The applicant proves they control the name — usually by placing a record in its DNS or a file on its web server — and the certificate follows. That check was designed to answer one question, and it answers it correctly: does whoever is asking control this name right now.

It does not ask whether they are the rightful owner. It cannot. There is no registry of who deserves a domain, only a registry of who has one, and when the registry is the thing that has been taken, the answer the check returns is accurate and useless at the same time.

So the certificates here were not forged. They were issued, properly, to someone who had satisfied the requirement.

What a certificate buys, and what it does not

A certificate alone does not impersonate anything. It has to be paired with traffic.

But the same compromise supplies both halves. An attacker holding the DNS can point the name at a server they run, and then present a certificate that every browser accepts for that name. At that point the padlock is accurate: the connection really is encrypted, and really is to the server the DNS says is authoritative. It is just not the one the reader meant.

The window matters more than the certificate count. A certificate is valid for months; DNS control can be lost in days. Which is why Google's advice includes restricting issuance to specific accounts and validation methods — to stop an attacker reusing cached validation to mint new certificates after the hijack has ended.

What Google says, and what it does not

This is worth separating carefully, because the distinction has collapsed in most coverage.

Google says: three namespaces, authoritative DNS records modified, certificates covering several Google domains and other organisations. Chrome blocked the certificates for Google properties through CRLSets, its emergency blocking mechanism, and worked with the issuing CAs to revoke them for everything that is not Chrome. Certificate Transparency data later surfaced additional organisations, including several leading global brands and widely used online services, which Google does not name and says it contacted where it could.

Google does not say: how many certificates were issued, which authorities issued them, how the attackers passed validation, how the registries were compromised, who did it, or when it started.

Secondary reporting has supplied some of what Google withheld: a count of at least a dozen certificates for Google and YouTube names issued between 22 and 27 September, and named authorities including two that issue free certificates. Those figures come from reading the public Certificate Transparency logs, not from Google. They are plausible and they are not the vendor's account, and a reader should know which is which.

Google also states plainly that it cannot guarantee its analysis identified every affected domain.

The defence lives in the thing that was taken

The standard recommendation after an incident like this is CAA records — a DNS record that tells authorities which of them may issue for your domain.

Google recommends it, and then says the quiet part: CAA cannot prevent certificate issuance during an active DNS hijack.

Of course it cannot. CAA is a DNS record. An attacker who has taken the registry can change it, or remove it, along with everything else in the zone. Every control in this stack — the validation record, the CAA record, the nameserver delegation — is published through the same system, and that system is what failed.

The one control that does not live in DNS is Certificate Transparency. CT is why anyone knows this happened at all. It is a public, append-only log of issued certificates, and it does not prevent a single thing — it only makes issuance impossible to hide. In this incident that was enough to find victims Google had not known about.

The other sentence worth keeping from Google's post is about its own fix: browser-side intervention should not be relied on to protect your users. Chrome blocked these certificates for Chrome. That is not the same as them not working.

What to do

  • Search crt.sh for your own domains, including the parked ones and the regional variants nobody looks at. That is where this would show up.
  • Publish CAA records, with account binding where your authority supports it. It will not help during a hijack. It helps afterwards, which is when the second wave of certificates would otherwise be minted.
  • Monitor CT logs continuously rather than after a news story. The logs are public and the tooling is free.
  • If you hold domains under a smaller ccTLD, understand that your name's security is your registry's security, and that you have no visibility into it.

What is not established

  • How the three registries were compromised, and whether by the same route.
  • Who did it, and what they wanted. No actor has been named.
  • How many certificates were issued in total, and for how many organisations. Google's own count is not published and it says its analysis may be incomplete.
  • Whether any of the certificates were used to intercept traffic, as opposed to merely being obtained.
  • When the campaign began. The Certificate Transparency dates show when certificates appeared, not when the registries fell.