Fake Google HTTPS Certificates Came From Hijacked Country Domains

Attackers hijacked parts of the country-code domain registries for Ghana, Sierra Leone and American Samoa, changed authoritative DNS records and obtained valid HTTPS certificates for Google domains and other major online services.

Google disclosed the incidents on October 6, identifying the affected namespaces as .gh, .sl and .as. Its systems were not breached, and Google found no reason to believe the certificate authorities that issued the certificates had broken industry rules. The attackers instead manipulated the layer those authorities use to verify control of a domain.

Chrome has blocked the unauthorized certificates Google identified through its CRLSet mechanism. Google also worked with issuing certificate authorities to revoke certificates covering its own properties and proactively blocked certificates it associated with other affected organizations. Chrome users do not need to take action, but Google warned that its investigation may not have found every affected domain and that Chrome’s response does not reliably protect people using other browsers.

How a registry hijack became a valid certificate

HTTPS certificates bind a domain name to a cryptographic public key. Before issuing one, a certificate authority must verify that the applicant controls the domain. Automated systems commonly do that by checking a DNS record or retrieving a token from a website.

The recent attacks broke the assumption beneath those checks. Control of a top-level registry can let an attacker alter nameserver delegations or authoritative records for selected domains beneath that suffix. A certificate authority querying the manipulated DNS then sees the attacker’s answer. A web-based validation request can also be routed to infrastructure the attacker controls.

The sequence is straightforward:

1. The attacker gains control inside a country-code registry.
2. DNS records or nameserver delegations for a selected domain are changed.
3. The attacker requests a certificate and completes the authority’s domain-control check.
4. The authority issues a publicly trusted certificate because the validation result appears legitimate.
5. The attacker can use that certificate to impersonate the affected service if traffic can also be directed to the attacker’s server.

The last condition matters. A rogue certificate does not automatically redirect users. It becomes dangerous when paired with DNS manipulation, routing control, a compromised network or another way to place the attacker between a user and the real service. In that position, the browser can see a correctly signed certificate for the requested hostname and establish an encrypted connection to the wrong server without displaying the usual certificate warning.

Certificate Transparency exposed the wider impact

Google first blocked the unauthorized certificates it found for its own properties. It then used Certificate Transparency data to identify certificates for other organizations, including what it described as leading global brands and widely used online services.

Certificate Transparency logs are public, append-only records of trusted certificates and precertificates. They do not stop a certificate from being issued, but they give domain owners and browser teams a near-real-time trail to inspect. A monitor can alert an organization when a new entry includes one of its domains, turning a normally invisible issuance event into something its security team can investigate.

Google did not identify the affected domains, the other organizations, the issuing authorities, the number of unauthorized certificates or the attacker. It also did not report whether the certificates were used to intercept real user traffic. Those omissions limit what can be concluded about the operational impact. The confirmed issue is unauthorized issuance following compromise of three third-party namespaces, not a demonstrated break of TLS encryption or Google’s internal infrastructure.

Why Chrome’s block is only part of the response

Chrome’s CRLSet system lets Google distribute compact certificate revocation information through browser updates. That provides a faster path to reject known certificates than waiting for every client to obtain and process conventional revocation data.

It is still a detection-dependent control. A certificate must first be found and classified. Google explicitly cautioned that the complexity of DNS hijacking means some affected domains may have escaped its analysis. A Chrome-specific block also cannot protect software that uses another browser engine, embedded client, operating-system trust stack or custom TLS implementation.

Revocation by the issuing authority broadens the response, but revocation checking varies across clients. Domain owners therefore need their own issuance monitoring and a plan to contact the issuing authority quickly, rather than assuming a browser vendor will discover and contain the problem for them.

What domain owners should check now

Organizations with any .gh, .sl or .as property should review recent Certificate Transparency entries immediately. The inventory should include active sites, parked names, redirect domains, regional brands, mail hostnames, API endpoints and domains retained after a product shutdown.

1. Monitor the complete portfolio. Subscribe every owned domain to a Certificate Transparency monitor, including low-traffic country domains. Route alerts to a queue that is staffed and has a documented escalation path.
2. Validate every unexpected entry. Compare the certificate’s subject names, issuer, serial number, validity window and public key with approved issuance records. Confirm whether a CDN, cloud platform or certificate automation account requested it before treating it as malicious.
3. Revoke and contain. For unauthorized issuance, contact the issuing authority, preserve the CT entry and DNS history, rotate any exposed application secrets, and review traffic, authentication and edge logs for the affected period. Restoring DNS alone may not end the risk if completed validation can be reused.
4. Publish restrictive CAA records. CAA lets a domain specify which certificate authorities may issue for it. Google recommends binding policy to approved ACME accounts and validation methods where the chosen authority supports those extensions.
5. Harden domain administration. Use phishing-resistant multifactor authentication, separate registrar and DNS roles, restrict API tokens, enable registry lock where available, alert on nameserver and delegation changes, and keep recovery contacts current.
6. Rehearse certificate incidents. Security, infrastructure and legal teams should know who can change DNS, suspend issuance, request revocation and communicate with customers outside the affected domain.

CAA helps after control is restored, not during the hijack

CAA is useful here, but it is not a magic shield. An attacker who controls authoritative DNS can also change or remove ordinary CAA records during the active hijack. Google emphasized a different benefit: after legitimate control is restored, a restrictive policy can stop the attacker from using cached domain-validation results to obtain more certificates.

The IETF’s CAA extensions allow policy to be narrowed to a particular certificate-authority account through accounturi and to approved validation methods through validationmethods. Operators must confirm that their authority supports and documents those parameters before deploying them. A mistake can block legitimate renewals, so changes should be tested against the organization’s actual ACME clients and emergency issuance path.

DNSSEC can authenticate DNS data when the chain of trust and validating resolvers remain intact, but it does not replace registrar, registry and account security. The practical defense is layered: strong domain administration, signed DNS where supported, narrow certificate issuance policy, continuous CT monitoring and a revocation process that has been tested before an incident.

For ordinary users, Google’s guidance is simple: Chrome users are already protected against the certificates it identified. Everyone should keep browsers and operating systems updated. For website operators, the incident is a sharper warning. HTTPS can encrypt a connection perfectly while still authenticating the wrong endpoint if the domain-control checks feeding certificate issuance have been manipulated.