The recent hijacking of infrastructure supporting the .gh, .sl and .as country code top level domains exposed a trust gap that many organizations still treat as two separate problems.
One team manages domains and DNS. Another team manages certificates and PKI. An attacker only needs the gap between them.
According to Google’s incident disclosure, attackers modified authoritative DNS records and obtained unauthorized HTTPS certificates for several Google domains and domains belonging to other organizations. Google said its systems were not compromised. It also said there was no reason to believe the certification authorities that issued the affected certificates had done anything wrong.
That last point deserves attention. The public Web PKI can follow its validation rules and still produce an outcome the legitimate domain owner never approved.
The certificate can be correctly formed. Its signature can verify. The issuing CA can be trusted. The domain validation process can appear successful. Yet the identity binding can still be unauthorized because the signal used to establish domain control was manipulated.
The certificate was not the beginning of this failure. It was the cryptographic result of trusting compromised DNS.
What the attacker needed to control
A publicly trusted domain validated certificate proves that the requester demonstrated control of a domain through an approved method. It does not prove that the request passed the domain owner’s internal approval process.
The CA cannot see the organization’s change record, application owner or intended certificate profile. It applies its validation procedure to the evidence available from the public internet.
DNS influences more of that evidence than many teams realize.
With the ACME dns-01 challenge, a requester places a value supplied by the CA in a DNS TXT record. With http-01, the CA retrieves a token from a web path. DNS still determines where that request goes. RFC 8555 identifies DNS as a common point of vulnerability for both methods. An attacker who can provision false DNS records can answer the DNS challenge directly or redirect the HTTP validation request.
The attack path is not complicated:
- The attacker gains the ability to alter registry, delegation or authoritative DNS state.
- The attacker redirects validation or publishes the value expected by a CA.
- The CA observes evidence that is consistent with domain control.
- The CA issues a trusted certificate for a new attacker controlled key.
- The certificate becomes visible through public transparency data.
- The domain owner must identify, block, revoke and investigate an identity it never authorized.
The attacker does not need the legitimate server key. A CA signing key does not need to be compromised. Control of the name can be enough to create a different trusted binding.
This is why calling the result a fraudulent certificate can hide the architectural issue. The certificate was unauthorized from the domain owner’s perspective. The CA may still have received evidence that satisfied its procedure. The evidence was false because the attacker temporarily controlled the system producing it.
Internal inventory is not enough
Most certificate inventories answer operational questions about deployment, expiration, ownership, issuers and algorithms. They do not reveal every certificate issued in the organization’s name. An attacker certificate may never enter an enterprise network or appear in a managed CA account. The public Web PKI can still trust it.
Certificate Transparency provides an external view. Chrome requires trusted certificates it relies on to be disclosed in public CT logs. Google recommends ongoing CT monitoring across the full domain portfolio, including parked domains and regional country code properties.
CT does not decide whether a certificate is malicious. It records issuance. The organization must compare that event with its own source of truth.
A useful alert should ask whether the domain, issuer, CA account, validation method, key and profile match an authorized workflow. It should also examine change records and nearby registry or DNS activity. The highest value signal is a certificate that cannot be reconciled with an authorized enterprise process.
CAA helps after authentic DNS is restored
Certification Authority Authorization records let a domain owner specify which CAs may issue certificates for a domain. RFC 8657 adds the ability to bind authorization to specific ACME accounts and validation methods when a CA supports those parameters.
That control is useful, but it is delivered through DNS.
During an active DNS or registry hijack, the attacker may be able to change the CAA policy along with other authoritative data. Google therefore makes a careful recommendation. Restrictive CAA becomes a critical safeguard after legitimate DNS control is restored. ACME account binding can also limit reuse of domain authorization obtained during the compromise.
Organizations should verify that their chosen CAs support the relevant account and validation method parameters. RFC 8657 warns that these restrictions are not effective when the CA does not recognize them.
CAA constrains issuance when the CA receives authentic policy. CT exposes issuance so the domain owner can assess it. Neither replaces protection of registrar, registry and DNS administration.
DNSSEC can authenticate DNS data when the delegation chain is intact and the relying system validates it correctly. RFC 8555 recommends DNSSEC validating resolvers for ACME related queries. This reduces important forgery and routing risks, but it does not make registry security optional. An attacker who can alter delegation or change a signed zone through an authorized administrative path may still produce data that validates. Cryptographic validity and organizational authorization remain separate questions.
Treat domain administration as privileged identity
Domains are often scattered across business units, acquired companies and regional teams. Parked names may have no obvious technical owner. Recovery contacts may depend on email hosted under the domain under attack. This is privileged identity risk, not only asset management.
Organizations should use dedicated administrative identities, phishing resistant multifactor authentication where supported, least privilege and separation of duties. High impact changes such as nameserver updates, delegation changes and lock removal should require strong approval. Recovery channels should not depend entirely on the affected domain.
ICANN guidance recommends formal domain maintenance procedures, multifactor authentication, registrar locks and registry locks where available. These controls form layers. They are not guarantees.
The organization also needs tested emergency contacts at the registrar, registry, DNS provider and CA. A control that cannot be reached during an incident is only a policy document.
Build one DNS and PKI evidence chain
DNS and PKI teams need a shared operating picture that connects:
Domain owner → registrar and registry state → delegation → authoritative DNS change → validation method → CA account → certificate request → issuance → deployment → observed runtime identity → client acceptance → revocation or containment
Each step should have an owner, a policy, a timestamp and evidence. When those records disagree, the organization should be able to classify the state as authorized, unauthorized or unknown.
Start with a complete portfolio of production, regional, parked, defensive, legacy and acquired names. Connect public issuance monitoring to approved accounts, profiles, subject names, keys, change windows and DNS state. Then verify deployment. Issuance proves that a CA created a certificate. A deployment response does not prove what an endpoint serves or what a client accepts.
Recovery is more than restoring a DNS record
Unauthorized certificate issuance should trigger a coordinated security incident, not only a PKI ticket.
The response should include these actions:
- Freeze unauthorized registry and DNS changes.
- Restore known good delegation and authoritative records.
- Preserve registration, DNS, CA, CT and endpoint evidence.
- Identify every unauthorized certificate and affected domain.
- Request revocation and seek browser or platform intervention when warranted.
- Rotate affected administrative credentials, keys and tokens.
- Review traffic, mail, identity and application logs for exploitation.
- Restore restrictive CAA and validate DNSSEC state.
- Confirm what endpoints serve and what representative clients accept.
- Continue monitoring for follow on issuance or reused validation state.
Google used CRLSets to block identified certificates in Chrome and worked with the issuing CAs on revocation for other clients. It also warned that browser intervention should not be the primary defense. Chrome cannot guarantee that every affected domain was identified and browser controls do not protect every user or client.
Recovery is complete only when the organization can show that domain control was restored, unauthorized credentials are rejected and legitimate services present the intended identity.
The control signal matters as much as the certificate
The ccTLD hijacks did not break certificate cryptography. They compromised a signal that certificate issuance was designed to trust.
That distinction changes the operational question. Security teams should not ask only whether a certificate verifies. They should ask who authorized the request, what evidence the CA relied on, where the resulting identity became active and how the organization will prove that it no longer works after authorization is withdrawn.
DNS and PKI are not separate trust domains. DNS can authorize certificate issuance. Certificate monitoring can reveal DNS compromise. Incident recovery in either system depends on evidence from the other.
A follow up article will examine this failure in a Merkle Tree Certificate world. MTC changes how issuance is logged and proved. It does not make compromised domain control trustworthy.
Sources
- Google Security Blog, “Chrome’s Response to Recent ccTLD Registry Hijacks,” October 6, 2026.
- IETF, “RFC 8555: Automatic Certificate Management Environment,” March 2019.
- IETF, “RFC 8659: DNS Certification Authority Authorization Resource Record,” November 2019.
- IETF, “RFC 8657: CAA Record Extensions for Account URI and ACME Method Binding,” November 2019.
- ICANN, “Practical Steps for Protecting Domain Names,” September 6, 2013.
Limitations
Google’s disclosure is a high level incident account rather than a complete forensic report for every affected registry, domain, CA and validation method. This article does not attribute a specific validation method, registrar failure or DNSSEC condition to each unauthorized certificate.