Seize a National Registry and the Web Will Certify You as Google

last month, someone obtained valid, publicly trusted tls certificates for google and youtube domains across three national namespaces. google was not hacked. no certificate authority was tricked into breaking its own rules. the attackers compromised three country-code registries and let the system hand them certificates it was designed to issue.

the registries were .gh in ghana, .sl in sierra leone, and .as in american samoa. each is run by a third-party operator, and each was compromised. whether the three share a common operator or backend, which would explain why they fell together, has not been disclosed. with control of the registry, the attackers could manipulate authoritative dns beneath it and create the conditions needed to prove control over domains they did not actually own.

certificate transparency logs show at least twelve certificates covering seven google and youtube domains, including google.com.gh, youtube.sl, and google.as. let's encrypt issued eleven of them and zerossl issued one. the certificates appeared in public logs between september 22 and september 27. some remained valid for roughly a day and a half before revocation. others survived for almost a week.

when you ask for a domain-validated certificate, the authority does not need to establish your real-world identity. it merely needs to establish you control the domain.

there are several automated ways to prove that control. authoritative dns sits underneath the process because it decides where the name points and what answers the world receives. whoever controls that layer can influence the evidence the certificate authority relies upon. authoritative dns ultimately rolls uphill to the registry. compromise the registry, and control can propagate downward into domains beneath it, and the certificate authority receives evidence consistent with domain control and follows the validation process in front of it.

the deeper problem is that two systems we tend to think of as separate are coupled at exactly the point where trust gets created. dns determines who can authoritatively answer for the name, and the certificate system relies on evidence rooted in that naming infrastructure to decide who controls it. that is not two independent security layers failing. it is one poisoned source of authority propagating trust into the next.

there is another uncomfortable detail. modern certificate authorities use validation from multiple network perspectives to make localized routing and dns manipulation harder. the idea is simple. if different observers in different places all see the same answer, confidence in that answer goes up. but a compromised registry changes the authoritative answer at the source. every validation perspective can therefore receive the same poisoned truth, and more observers do not help when the authority they are observing is the thing that has been taken over.

this is also why it is worth asking what the padlock in your browser actually certifies. it does not establish the real-world legitimacy of the organization standing behind a site. a domain-validated certificate binds a cryptographic key to a domain name after control of that name has been demonstrated. the modern web standardized around scalable domain validation because making real-world identity verification a prerequisite for encryption would never have scaled to the internet we have now. automated issuance helped make encrypted web traffic nearly universal, and this incident shows one of the costs of building trust around control of the name itself.

the weak link was never google. it was three national registry environments the average internet user has probably never considered. for a stretch in late september, trust in google-branded domains under those namespaces depended on infrastructure far upstream from google itself. google was not the only name exposed; certificate transparency data pointed to several leading global brands and widely used online services google has not named. that is what makes trust chains uncomfortable. the most recognizable name in the chain is not necessarily the part deciding whether the chain remains trustworthy, and sometimes the smallest piece of infrastructure holds authority over everything beneath it.

there is a sharp irony in one of the defenses meant to constrain issuance. domains can publish caa records telling certificate authorities which issuers are permitted to create certificates for them, but caa itself lives in dns. during an active dns hijack, the attacker may control both the thing being protected and the policy describing who is allowed to protect it. caa becomes useful again once legitimate dns control is restored, particularly when issuance is tied more tightly to a specific acme account. but during the hijack itself the attacker is standing inside the room with the keys.

control of the registry can be temporary while the trust manufactured during that window lasts longer. once transient control has satisfied domain validation, the attacker has converted a short-lived dns compromise into a cryptographic credential with its own lifetime. that helps explain why google's longer-term response is not limited to revoking these certificates. it also points toward shorter certificate lifetimes and reducing how long previous domain-control validation can be reused. cut how much future trust a brief period of stolen authority can buy can increase security.

what exposed the incident was not prevention. it was observation. publicly trusted certificates are written into certificate transparency logs where anyone can inspect them. google used that data to identify additional affected organizations, while researchers used the same public record to enumerate the google and youtube certificates. certificate transparency does not stop the lie from becoming trusted. it makes sure the lie cannot remain secret.

chrome blocked the affected certificates through crlsets while google worked with the issuing authorities to revoke them for the wider ecosystem. that response matters, but it also shows the limits of browser-side intervention. chrome can protect its own users quickly, yet it cannot guarantee equivalent protection across firefox, safari, edge, and every other browser, application, tls stack, or device. google has said it cannot guarantee its analysis identified every affected domain. others may still exist but are yet unknown.

we also do not know the ending. no attacker has been publicly named, and there is no evidence so far that the certificates were actually used to intercept anyone's traffic, nor using the traffic for nefarious purposes. what is confirmed is that valid cryptographic credentials were created and remained usable for periods ranging from roughly a day and a half to almost a week before revocation.

that distinction matters because a certificate alone does not magically redirect traffic. the attacker still needs some way to place victims on infrastructure using the certificate. restoring legitimate dns removes one major part of the attack path even if the certificate itself remains technically valid until revoked or expired.

the lesson is not that https is broken. cryptography can only authenticate the reality presented to it. if the authority defining that reality has already been compromised, mathematically perfect verification can produce a perfectly trustworthy answer to the wrong question.

the certificate authorities were not fooled. they were obeyed. by the time cryptography entered the picture, the lie was already authoritative.