10 Oct 2026 · security, dns, redes · 4 min

Twelve fake certificates among 4,758 real ones

Twelve fake certificates for Google domains circulated between September 22 and 27. They sit inside 4,758 legitimate certificates logged for a single name, google.com.gh, in the public transparency logs.

The attack was not against Google and it was not against cryptography. Attackers took over three country-code top level registries, .gh (Ghana), .sl (Sierra Leone) and .as (American Samoa), changed the authoritative DNS records for chosen names, and by doing so passed the automated check every certificate authority runs before issuing. The account is on Chrome’s security blog, and the certificate details were pulled from the logs by The Hacker News.

Eleven of the twelve came from Let’s Encrypt and one from ZeroSSL. All were domain validated, all were revoked, and the gap between appearing in the log and going dead ran from a day and a half to about a week. Google did not blame the authorities: they checked what was checkable, and what the attacker controlled answered correctly.

What I checked

I asked the question as a DNS query. The CAA record exists since 2013 and lets a domain owner name which authorities may issue certificates for that name, per RFC 8659. I queried 16 well known domains with dig +short CAA:

Nine of the sixteen allow three authorities or fewer. The average among those that publish a record is 2.8 CAs. And the three that publish nothing let any authority in the world issue for them, which is the default: CAA is optional.

The query takes a second and works against any domain today:

dig +short CAA yourdomain.com

One trap is worth knowing. If an attacker controls the DNS zone, they also control the CAA record, so CAA does not stop a hijack at the registry level. What Google recommends is publishing a restrictive CAA record so cached validation data cannot be reused after DNS control is restored, which is why validation authorization windows are shrinking to hours.

What the domains serve now

I connected to the four affected names to see the certificate they present today. All four serve a wildcard certificate from Google Trust Services, issued on September 18, before the hijack, valid until December 11. For the visitor the episode was short, and the trace stayed in the logs.

That leads to the practical problem for anyone following the advice to monitor certificate transparency: the signal is small and the noise is huge. In the same logs, google.com.gh carries 4,758 entries and google.sl 2,255. Finding the twelve fakes inside that takes a baseline, not a generic “new certificate for your domain” alert.

The baseline has three things to check: which authorities issue for my domain today, whether they are the ones I authorized in CAA, and whether anything got issued outside the normal renewal cycle. The third item is the one that catches a September style attack, because all twelve certificates appeared within six days.

Caveat: the CAA counts and the log counts are from one day, one query per domain. Transparency logs grow over time and CAA changes without notice.

My reading is that the padlock never meant “this site belongs to Google”. It means “somebody proved control of this name to an authority”. September’s attack did not break cryptography, it broke the proof of control, because names are administered by registries that are also systems run by people, with admin access and passwords. It is the same kind of fragility that shows up when an essential piece of the internet changes hands, and the defense is the same one: measure from outside what the owner cannot see.

Anyone with a handful of domains and no CAA record has a ten minute task. Anyone with hundreds has a monitoring project, and now knows the project needs a baseline before it needs an alert.