On October 6, Google published a warning that attackers had obtained unauthorized HTTPS certificates for several of its domains. A public certificate authority had issued them after domain-control validation succeeded. The attackers already held the country-code registries for Ghana (.gh), Sierra Leone (.sl), and American Samoa (.as). If your cybersecurity program treats TLS as a finished checkbox behind the firewall, this is the week that story stops working.
Google’s production stayed intact. Board decks will quote that as comfort. The padlock your users trust is a claim about domain control, and domain control is a claim about whoever runs the registry. Steal the registry, and the CA does the honest thing. It checks a nameserver you now own. It issues a certificate every browser will treat as legitimate.

The CA followed the rules you wrote
Issuance is supposed to be boring. You prove you control a name. The CA signs. Certificate Transparency logs the leaf. Browsers accept the chain. That pipeline treats the registry as an honest broker of who owns the zone. When .gh, .sl, and .as fell, the broker failed for every name under those suffixes, not only Google’s marketing hostnames.
You already know the rest of the path. With a valid cert, an attacker can sit on a network and present HTTPS that looks correct. Captive portals, messy roaming, a poisoned resolver, a last-mile box, a helpful intercept appliance; pick your insertion point. The encryption is real. The peer is a lie.
This is a different failure than a stolen private key on one of your load balancers. You can rotate that. You can see your own CSR. A registry-backed rogue cert is someone else’s key, for a name that still resolves, on a chain your threat-protection stack is built to trust. Plenty of IDS deployments will log a clean handshake and move on.
Google can watch Certificate Transparency at a scale most of you cannot. A bank with a leftover .gh campaign site, a carrier portal under a ccTLD from 2014, a vendor that registered something.as because the letters looked cute; those teams find out when a customer forwards a screenshot. Or they never find out.
Cybersecurity inventories still skip the registry
Walk the asset list. You have EDR, identity, maybe a SOC that can spell Certificate Transparency. You probably do not have an owner for “who can prove control of this name to a CA.” Registrar logins live in a shared mailbox. Registry lock is off because someone needed a DNS change last quarter. CAA records were a ticket that died in change review.
That gap is the story. Defense in depth is supposed to mean controls that fail separately. TLS, DNS, and registrar access collapse into one control if the same on-call can rewrite the zone and request a cert. A brute-force or stolen session against a registrar portal then mints trust for every name in the account. You do not need a custom implant. You need the password nobody rotated after the contractor left.
Call it cyber security with a space if that sells the change ticket. Name ownership is a privileged identity. Treat the registrar like a domain controller that happens to live at a vendor.

Same week, Google shipped Android security updates that many devices will not receive. You cannot patch Ghana. You can decide whether your fleet still believes every public CA equally, and whether anyone looks at CT when a new leaf appears for a name you thought you owned. Stale mobile TLS stacks are how a desk investigation says “we’re fine” while the CFO’s phone is still happy to complete the handshake.
Citizen Lab’s Ron Deibert spent the week arguing that the U.S. government wants more pervasive surveillance, and that some technology executives are eager to help. You can skip the adjectives and keep the operator point. Unauthorized certificates are how intercept still shows a lock icon. A hijacked ccTLD is how you get those certificates without persuading a CA to violate its own policy. The policy held. The identity of the registrant did not.
Hunt the certificate you never requested
Do the ugly finite work first. Export every domain you own, including country variants, parked names, and microsites. Query Certificate Transparency for each one and compare issuer, validity window, and SANs against the certs on your actual terminators. If you have any customer-facing name under .gh, .sl, or .as, treat those zones as hostile until the registry and your CA say otherwise. Rotate keys. Cut stale hostnames. Ask the CA to revoke anything you did not mint. Turn on registrar lock and registry lock where the TLD offers it. Put hardware keys on registrar accounts and kill shared passwords tonight.
CAA belongs in the zone today. It will not save a name whose registry is already owned, because the attacker who controls the zone can rewrite CAA too. It will stop a random public CA from issuing for the names you still control. Pair it with an account constraint when your CA supports one, and watch for CAA failures instead of setting the record once.
After that, fold unexpected certificates into threat detection the way you already fold unexpected admin tokens. Page someone when CT shows a new leaf for your brand from an issuer you do not use, or a SAN for a hostname you retired. Write incident response so a rogue cert is a name-system event: revoke, replace, flush caches, then ask which registrar session, which nameserver, which WHOIS change happened first. Reimaging a web head that did nothing wastes the hour you still have.
Security hardening here is boring on purpose. Dual control for DNS changes. Registrar API logs in the same place you send IdP logs. An inventory that lists the TLD operator and the registrar, not only the application owner. Tabletop a 45-minute window where a valid cert exists for a payment hostname you did not request. If the runbook says “check the firewall,” rewrite the runbook.
You will not get a patch Tuesday for a country-code registry. You get CT, CAA, locks, and a habit of treating the padlock as a claim that needs a second source.
Sources
- Attackers Hijack .gh, .sl, and .as Registries to Obtain Certificates for Google Domains
- Google issues Android security updates: who can get them and how
- Citizen Lab Slams Trump Administration, ‘Techno-Fascist’ Executives
Take Control of Your Server Security
Don't let brute-force attacks slow you down. Try IPBan Pro risk-free for 30 days.
Secure. Automated. Lightweight.
Take Control of Your Server Security
Don't let brute-force attacks slow you down. Try IPBan Pro risk-free for 30 days.
Secure. Automated. Lightweight.
