Domain Validation Is Dead. Certificate Transparency Won.

Wait — what actually happened?

On October 6, 2026, Google disclosed that attackers took administrative control of three country-code top-level domain registries — Ghana (.gh), Sierra Leone (.sl) and American Samoa (.as) — and used that control to obtain technically valid HTTPS certificates for several Google-owned domains. Not forged certs. Valid ones, signed by real CAs, that would show a green padlock in any browser.

They didn’t pop a certificate authority. They popped the registry operator’s systems — the administrative layer above the authoritative DNS. That distinction is the whole story.

How do you get a real cert without hacking a CA?

You prove you own the domain. That’s the entire security model behind ACME and domain-validated issuance, and it has exactly one assumption baked in: that whoever controls the DNS records is the legitimate owner.

Own the registry and you own that assumption. HTTP-01 challenge? You point the record wherever you like. DNS-01? You write the TXT record yourself. Email validation? You control the MX. Every validation method a CA offers is a question answered by DNS, and the attacker was holding the pen. The CA did its job correctly and still issued a malicious certificate. Sit with that for a second, because it’s the uncomfortable part.

So my CAA records would have stopped this, right?

No. CAA records live in DNS. The attacker controlled DNS. They could rewrite your CAA to permit whatever CA they wanted, or delete it entirely. CAA stops a misconfigured or rogue CA from issuing against your wishes — it does nothing when the attacker is impersonating you at the source of truth. Keep CAA set; it still earns its place against other failure modes. Just don’t expect it to help here.

Which Google domains got certs, and were they used in attacks?

Google’s disclosure describes “several Google-owned domains” but — as of this writing — does not publicly enumerate the specific hostnames in the primary advisory. If you need the authoritative list for your own detections, the CT logs are the record: the certificates themselves are public, by design. On active abuse: treat anything issued during the compromise window as hostile until proven otherwise. A certificate’s existence in a CT log is confirmed fact; “it was never used” is a claim you cannot verify from the outside, so don’t bank on it.

What’s the compromise window — what dates?

Google has not disclosed exact start and end dates for the compromise beyond the October 6, 2026 disclosure. Which means you cannot scope your audit to a tidy date range and call it done. Treat the window as open-ended until Google says otherwise, and review all issuance for the affected names, not just a convenient slice of it.

How did Google even catch this?

Certificate Transparency. Every publicly trusted cert gets logged to append-only CT logs, and Google monitors those logs for its own domains. The unauthorized certs showed up where Google could see them. That’s the takeaway worth repeating: CT was the detection, not the prevention. By the time a cert appears in a log, it already exists and already works. CT tells you you’ve been robbed; it doesn’t lock the door.

I run domains under a ccTLD. How do I check right now?

Query CT logs for your domains and diff against what you actually issued. Read-only, start now:

1
2
3
4
5

# Dump all logged certs for a domain and its subdomains (report only)
DOMAIN="example.com"
curl -s "https://crt.sh/?q=%25.${DOMAIN}&output=json" \
  | jq -r '.[] | [.not_before, .issuer_name, .common_name] | @tsv' \
  | sort -u

1
2
3
4
5
6
7
8

# PowerShell equivalent - inventory issuance, flag by date window
$domain = "example.com"
$uri = "https://crt.sh/?q=%25.$domain&output=json"
Invoke-RestMethod -Uri $uri |
  Select-Object not_before, issuer_name, common_name |
  Sort-Object not_before -Descending |
  Format-Table -AutoSize
# Compare issuers/dates against your known CA and enrolment records.

Cross-reference every row against your own issuance log. Anything you can’t account for — especially from a CA you don’t use — is a finding.

I found a cert I don’t recognise. Now what?

Report it to the issuing CA for revocation and open a problem report; CAs are obligated to act on verified misissuance. If the domain sits under .gh, .sl or .as, assume your DNS could have been tampered with during the window — re-verify delegation, nameservers, DS records and registrar lock status directly with the registry. Rotate anything that trusted that DNS.

How urgent is this?

This week — immediately if you hold names under the three affected ccTLDs. The compromise is confirmed and the certs are real. The fix is boring and permanent: continuous CT monitoring with alerting on unexpected issuance, for every domain you own, under every TLD. Validation told you a lie. The log told you the truth, just a little late.