Security explainer · Checked 1 November 2026. This article examines an incident reported on 6 October, rather than a newly announced attack.
Google’s 6 October report describes hijacks affecting .gh, .sl and .as. Attackers changed authoritative DNS and obtained unauthorized HTTPS certificates. Google says its systems were not compromised and it found no reason to blame the issuing CAs. Chrome blocked identified certificates; Google also sought CA revocation. Chrome users needed no action, but Google could not guarantee complete detection or protection in other clients.
Three controls, three different jobs
It helps to separate the operational questions: who can obtain a certificate, how an unexpected certificate becomes visible, and how clients stop trusting it. A team that checks only whether its website loads successfully has answered none of those questions completely.
CRLSets block certificates. Chromium describes them as Chrome’s emergency blocking mechanism. They also include a subset of other revocations collected from CA certificate revocation lists. They are not an exhaustive copy of every revocation everywhere. That distinction matters when assessing an incident across browsers, applications and embedded clients. Chromium’s CRLSet documentation explains the scope.
Certificate Transparency makes issuance observable. Public, append-only logs let monitors find certificates and precertificates associated with a domain. Logging is visibility, not an approval from the domain owner. An unfamiliar entry therefore needs investigation rather than an automatic conclusion that an intrusion occurred. Compare it with your own issuance records and the services authorized to manage certificates. See how CT works and the monitor directory.
CAA constrains future issuance. A Certification Authority Authorization record identifies permitted issuers. It is checked during issuance, not used by a browser to invalidate an existing certificate. Changing CAA therefore does not replace revocation. A certificate inconsistent with today’s policy could also have been permitted by an older policy. RFC 8659 defines these boundaries.
Allowing a CA is broader than allowing your account
RFC 8657 adds two useful restrictions: accounturi identifies permitted CA accounts, while validationmethods limits validation methods. Confirm that your CA implements them before depending on them. Incorrect settings can block legitimate renewals. DNS delegation can also override an ancestor’s restrictions, so these controls are not a universal defense against an attacker who controls the relevant DNS.
For example, Let’s Encrypt documents support for account binding and the methods HTTP-01, DNS-01 and TLS-ALPN-01. Its documentation also explains that CAA permissions are additive: a permissive additional record can allow issuance. Review the entire effective record set, including wildcard rules and delegated services, rather than checking one reassuring-looking line.
A practical review for domain owners
The following is an operational checklist, not a claim that any particular domain is compromised:
- Build one inventory. List production, regional and parked domains, their DNS operators, approved certificate services and the person responsible for each.
- Assign an alert owner. Someone must reconcile unexpected CT entries with legitimate CDN, hosting and renewal activity.
- Investigate before changing policy. Record the certificate, issuer, timestamps and relevant DNS changes. Escalate unexplained issuance to the responsible providers.
- Check recovery end to end. Restored DNS, certificate revocation and successful legitimate renewal are separate checks. Test restrictive CAA changes against your actual renewal workflow.
The useful lesson is to connect DNS ownership, certificate inventory and incident response. A browser intervention can help contain damage, but your organization still needs a clear record of which certificates it intended to authorize.
Related: our Certificate Transparency guide.