The certificate authorities apparently followed the rules, yet attackers still obtained unauthorized HTTPS certificates for several Google domains. The break happened one layer above them: intruders hijacked the .gh, .sl and .as country-code registries, changed authoritative DNS, and passed the control checks used for routine certificate issuance. Google's incident account makes that distinction explicit. A browser can verify that a trusted authority signed a certificate while the authority was looking at DNS answers controlled by an attacker.
That is the useful lesson from an incident whose full size remains undisclosed. Google says the same campaign affected domains belonging to other organizations, including widely used online services, but it did not name them or publish a certificate count. Chrome blocked the unauthorized certificates it found through its CRLSet mechanism, and the issuing authorities revoked the certificates for Google properties. The company also warned that it cannot guarantee it found every affected domain and that Chrome's intervention does not protect people using other clients. Ars Technica's report captured the gap: the known risk was mitigated, while any undiscovered certificate would remain dangerous.
The certificate system accepted the attacker's evidence
A public TLS certificate binds a domain name to a public key. Before issuing one, a certificate authority has to establish that the requester controls the domain. That proof can involve placing a random value in DNS or responding at a prescribed web address. The Certificate Transparency project explains the normal sequence: the authority checks control, creates a precertificate, records it in public logs, and signs the final certificate.
The attackers reached the system before that check. According to Google's description, they compromised the third parties operating .gh for Ghana, .sl for Sierra Leone, and .as for American Samoa. They could then modify authoritative records and nameserver delegations for selected names below those top-level domains. To an automated validation system, the person answering the challenge looked like the domain controller because the registry itself was sending traffic to the attacker's chosen infrastructure.
Google says its own systems were not compromised, and it has no reason to think the issuing authorities did anything wrong. That limits what this incident proves. The evidence points to a registry and DNS trust failure; it does not show that attackers stole a Google private key or breached a certificate authority. The company's account says the unauthorized certificates covered several Google domains and additional organizations found later through public log data. It does not identify the exact hostnames.
A certificate alone does not redirect a connection. An attacker also needs a way to bring a victim's traffic to a server holding the matching private key. Registry-level DNS control supplied that path here: the attackers could change where selected names resolved and then answer traffic at the chosen addresses. Ars Technica describes both capabilities, which is why an apparently ordinary HTTPS connection could reach an impostor without a certificate warning.
Public logs exposed certificates after issuance
Certificate Transparency made the unauthorized issuance visible. Chrome requires publicly trusted certificates to be disclosed in append-only logs, and monitors can watch those logs for new certificates covering a domain. The CT documentation says subscribers can receive updates when a certificate or precertificate for their names appears in a monitored log. Google used that record after its initial response to find certificates for more organizations and block them in Chrome.
The logs did not stop issuance. They created a public trail that defenders could inspect, which is a different job. A monitor has to recognize an unexpected name or issuer, reach the domain owner, and start a response. Google advises organizations to monitor their whole portfolio, including parked names and regional country-code domains, because a forgotten hostname can still receive a trusted certificate. That recommendation appears in the Chrome team's response, alongside a specific review request for operators with .gh, .sl or .as domains.
Chrome then used CRLSets to block the certificates it had identified. The browser receives that block information through its update machinery, which can act faster than waiting for every client to process ordinary revocation data. Google also worked with the issuing authorities to revoke certificates so other clients could reject them. Even so, the company cautions that browser action is an emergency measure, not a complete defense for mail servers, API clients, embedded software, alternate browsers, or certificates that investigators have not found.
This distinction changes an operator's response. Checking that a website opens cleanly in current Chrome only tests one client against Google's known block list. It does not inventory every certificate issued for the organization or show whether a non-browser service would accept one. The CT system's append-only records offer the broader evidence: certificate teams can compare each logged name, issuer, key, and issuance time against the changes they approved.
CAA narrows issuance, with a DNS-shaped limit
Certification Authority Authorization records let a domain owner state which authorities may issue certificates for a name. Under RFC 8659, a compliant public authority must look for the applicable CAA record before issuance and refuse a request that conflicts with it. The issue property covers ordinary certificates, while issuewild can set a separate policy for wildcard names.
An operator can inspect the current policy with a standard DNS query:
dig +short CAA example.com
The result is useful only when it matches an intentional policy. A broad record may authorize more issuance paths than the organization uses, while a missing record leaves the choice of authority unrestricted. A restrictive record can also break legitimate renewal if a team changes providers without updating DNS. The CAA standard describes the record as an issuance control and explicitly says it is necessary but insufficient evidence for issuing a certificate.
CAA could not serve as a fixed anchor during these hijacks because its policy also lives in DNS. Google says an attacker with active DNS control can alter the CAA response along with the validation records. The company recommends restoring a restrictive policy after control returns because authorities may cache and reuse completed domain checks. A restored CAA rule can prevent an attacker from using that cached validation state to request another certificate. Google's guidance specifically calls for bindings to authorized accounts and validation methods where the selected authority supports them.
Those finer restrictions come from RFC 8657. Its accounturi parameter can limit issuance to a named account at an authority, and validationmethods can allow only selected control checks. Support is authority-specific, so publishing parameters without confirming that the chosen authority recognizes them can create a policy that looks strict but is ineffective. The RFC also warns that DNSSEC protection and DNSSEC-validating resolvers matter when these controls are expected to resist forged DNS answers.
DNSSEC deserves the same careful boundary. It can let a validating resolver detect modified or missing signed data when the chain of trust remains sound. RFC 8659's security section recommends DNSSEC validation to detect spoofed or suppressed CAA records. A compromise at the registry layer is especially serious because the registry participates in that delegation chain. The published incident account does not say whether DNSSEC was enabled for each affected name or how the attackers interacted with signed delegations, so it would be unsafe to claim that DNSSEC alone would have stopped this campaign.
The response has to cover the domain portfolio
For teams running public services, Google's first practical request is continuous CT monitoring across every owned domain. That inventory should include parked properties, redirect-only sites and regional names that rarely appear in deployment dashboards. The Chrome team calls out those quiet parts of a portfolio because an attacker does not need the main corporate hostname if a trusted regional name can impersonate a login, update service, or API endpoint.
The second task is to compare CAA policy with the actual certificate automation. RFC 8659 requires authorities to search upward through the DNS hierarchy for the applicable record, so a policy at a parent name may govern many subdomains. Teams need to know which authority accounts renew each certificate before tightening the record. Otherwise, the security change can turn into an outage at the next automated renewal.
An incident runbook should also separate discovery, blocking, revocation, and DNS recovery. Google's response used all four: CT revealed more issuance, Chrome blocked known certificates, authorities revoked certificates, and domain owners were expected to restore restrictive DNS policy. None of those steps establishes the others. Google's warning about non-Chrome users is the reason to test API clients and other TLS consumers instead of treating a browser update as closure.
The missing facts now matter more than another general warning about the padlock. Google has not published the affected hostnames, the number of unauthorized certificates, the issuing authorities, or a detailed timeline for each registry compromise. Its post also says the investigation may not have identified every domain. The next useful evidence is a fuller incident record that names the affected hosts and issuers, followed by confirmation that revocation is complete. Any changes to registry security or domain validation will then show whether the path used here has been closed. Until that evidence arrives, domain owners can measure their own exposure by watching the certificate logs and checking whether their issuance policy matches the accounts that should be allowed to act.