Account-bound CAA records stop hijackers reusing cached validation after DNS is restored

The certificate authorities followed the rules. A CA issues a certificate once the applicant shows control of the domain, for example by adding a record to the domain's DNS ^[5]. In the hijacks Google disclosed on October 6 ^[1], the company said, "attackers modified authoritative DNS records and obtained unauthorized HTTPS certificates covering several Google domains, as well as domains belonging to other organizations" ^[3]. When a CA checked control of a Google name under .gh, .sl or .as, the attackers were the ones answering ^[31]. Malwarebytes described the result: by controlling DNS records, attackers can pass domain verification checks, and the authority can then issue a genuine, signed certificate ^[6]. Google said its own systems were not breached ^[2] and that it has no reason to believe the CAs did anything wrong ^[4].

CAA lives in the same DNS. A CAA record names the CAs allowed to issue certificates for a domain, and a CA must check it before issuing ^[7]. An attacker who controls the authoritative records also writes the CAA answer the CA reads ^[31]. According to Infosecurity Magazine, Google said CAA cannot prevent issuance during an active DNS hijack ^[8].

With a certificate like these, an attacker could pose as the real site over an encrypted connection and read the private data sent to it ^[27]. Malwarebytes noted that the three endings are not limited to sites serving Ghana, Sierra Leone or American Samoa ^[28].

What the CT logs recorded

Certificate Transparency is why anyone outside Google can count these certificates. The Hacker News found them on October 7 through two CT search services, ctlogs.dev and Cert Spotter ^[12]. It counted at least 12 certificates issued between September 22 and 27 for Google and YouTube names under the three ccTLDs, including google.com.gh, google.sl and google.as ^[11]. They cover seven domains. Let's Encrypt issued 11 and ZeroSSL issued one ^[12]. All 12 are domain-validated ^[14].

Per The Hacker News, the certificates were logged one namespace at a time: .gh on September 22, .sl on September 25 and .as on September 27 ^[13]. The run lasted five days across three ccTLDs ^[32].

The two .gh certificates and the ZeroSSL certificate were revoked on September 26, and the other nine on October 1 ^[15]. The .gh pair stayed valid for about four days after it was logged ^[34]. The shortest gap between a certificate's first log entry and its revocation was about a day and a half, and the longest nearly a week ^[16]. Nine days passed between the first log entry and the last revocation ^[33].

The first .as certificate was recorded on September 27, about a day after the .gh certificates were revoked ^[16]. Revoking the two .gh certificates did not slow the attackers, who went on validating under a namespace they still controlled.

Only a small set of Google and YouTube names was searched, The Hacker News said ^[17], so 12 is a minimum. Google said CT data pointed to other organizations it believes were hit, including leading global brands and widely used online services ^[22]. It blocked those certificates in Chrome and contacted the organizations where possible ^[22]. Let's Encrypt confirmed its share. "Yes, certificates for Google and YouTube were issued, and have been revoked," Matthew McPherrin, a Let's Encrypt staff member, wrote on the CA's community forum on October 7 ^[18].

The window after DNS comes back

CAA starts to matter when real DNS answers return. Google explained why: "Because CAs are permitted to cache and reuse completed domain control validation (DCV) checks for subsequent issuance, restoring a restrictive CAA policy, especially one that restricts issuance to specific authorized accounts and validation methods, prevents an attacker from using cached validation state to mint new certificates after a hijack ends" ^[9].

1. During the hijack, the attackers pass domain control validation at a CA, because they control the DNS the CA queries ^{[6] [31]}. 2. The CA may cache that completed check and reuse it for later issuance ^[9]. 3. The hijack ends and the real authoritative records return. The attackers no longer hold DNS, but the cached validation state still exists ^[9]. 4. The attackers request a new certificate. The CA must check CAA before issuing ^[7], and the CAA answer now comes from the restored zone.

Step 4 is the one an operator controls. If the restored zone publishes a restrictive record, Google says, the attacker cannot use cached validation state to mint new certificates ^[9].

The restriction has to be specific. Google's advice is a policy limited to specific authorized accounts and validation methods ^[9]. Infosecurity reports it as CAA records with ACME account bindings ^[10]. A record that names only a CA permits any account at that CA. Let's Encrypt issued 11 of the 12 certificates here ^[12]. An owner who uses Let's Encrypt and lists only Let's Encrypt in CAA would still let an attacker's Let's Encrypt account use its cached validation ^[36]. Google's own names were a simpler case. In the records The Hacker News reviewed, every other certificate for them came from Google Trust Services ^[14]. A record limited to that CA would have refused both hijack issuers once real DNS returned ^[37].

The record helps only if it is already in the zone when DNS control comes back. Google framed the CAA advice as a safeguard for after DNS control has been restored ^[29]. A restrictive record published beforehand applies to the first issuance request after restoration, with nothing to change mid-incident ^[38].

For owners under these three ccTLDs, restoration is not in their hands. Infosecurity Magazine describes the registries themselves as compromised ^[30]. According to The Hacker News, Google's post does not say how the ccTLDs were compromised, whether they have been secured, who the attackers were, or whether any certificate was used to pose as a Google site ^[24].

Catching the next one

Google's other instruction is monitoring. Owners should watch CT logs for every domain they hold, including parked domains and regional ccTLD names, and anyone under .gh, .sl or .as should review recent entries for certificates they did not request ^[25]. CT monitoring services send an alert when a certificate is issued for a domain ^[25].

The signal in this case was clean. In records back to at least September 10, every other certificate for google.com.gh, google.sl and google.as came from Google Trust Services ^[14]. The hijack certificates came from Let's Encrypt and ZeroSSL ^[12]. An alert on any issuer other than the one in use would have fired on each of the 12 on the day it was logged ^[35]. The first .gh entries were public from September 22 ^[13]. Google said it learned of the hijacks the week before its October 6 post and acted immediately ^[23].

Browser blocks cover part of the population. Chrome blocked the certificates for Google's domains through CRLSets, its emergency blocking mechanism, and Google worked with the issuing CAs to revoke them for people on other browsers and apps ^[19]. Google wrote: "Due to the complexity of DNS hijacks, we cannot guarantee that our analysis identified every affected domain, nor do Chrome interventions reliably protect non-Chrome users." ^[20] Chrome users do not need to do anything, Google said, but domain owners should not rely on the browser to protect their users ^[21].

What would narrow the window

Google said it will keep working on broader HTTPS changes, including shorter certificate validity periods and less reuse of domain-control validation ^[26]. We'd expect less DCV reuse to narrow the post-hijack window that restrictive CAA now covers, since that window exists because CAs may reuse completed checks ^[9]. Shorter validity would also cap how long a certificate like these 12 stays usable if nobody finds and revokes it ^{[11] [26]}.

Until those changes land, we think operators should have two things in place before the next incident: a CAA record bound to their own ACME account and validation method, and CT alerts on every name they own, parked ones included ^{[9] [25]}.