According to Ars Technica, attackers broke into three domain registries and used that access to get unauthorised TLS certificates for Google and other large services. Domain owners can spot certificates like these by watching Certificate Transparency logs, and they can make them harder to obtain.
What you need before starting
You need a complete list of the domains your organisation owns, including any you no longer use. You also need to know which certificate authorities (CAs) you actually use, and you need admin access to your DNS provider and your registrar account. A shared mailbox or chat channel for security alerts helps, as does a named person who can act quickly if something turns up.
It helps to understand why a registry compromise matters. A CA checks that you control a domain before it issues a certificate. It usually does this by asking you to publish a DNS record, serve a file from a web server or answer an email. The registry is the organisation that runs a top-level domain. It holds the records that say which name servers are authoritative for every domain under that ending. An attacker who can change those records can point a domain at name servers they control, pass the CA’s checks and receive a certificate that browsers trust. Ars Technica’s summary does not say which registries were affected, which CAs issued the certificates, how many were issued or whether they have been revoked. Those details remain unknown here.
List every domain and certificate authority you rely on
Start with an inventory. Include main brand domains, regional variants, marketing domains, domains held only to stop others registering them, and subdomains that serve real traffic. For each domain, write down the registrar, the top-level domain and its registry, the DNS host, and the CAs that legitimately issue certificates for it.
This list is the baseline for everything else. A certificate only counts as unauthorised if it does not match what you expect, and you cannot recognise an anomaly without a clear record of what normal looks like.
Search Certificate Transparency logs for existing certificates
Certificate Transparency (CT) is a system of public, append-only logs. Publicly trusted CAs record the certificates they issue in these logs, and major browsers generally reject certificates that have not been logged. As a result, an attacker who gets a trusted certificate usually leaves a public record of it.
Search the logs for each of your domains using a public CT search service or the search tools built into many security platforms. Look for certificates from CAs you do not use, certificates for subdomains you never created, wildcard certificates nobody requested, and certificates issued at times when no one on your team was renewing anything. Record anything unexplained before you move on.
Set up continuous monitoring and alerts
A one-off search only shows the past. Set up a monitoring service that watches CT logs and alerts you when a new certificate appears for any domain on your list. Several commercial providers offer this, and some free services and open-source tools do too.
Send alerts to a place people actually read, and make clear who responds. Tune the monitor so that routine renewals from your usual CA do not bury real anomalies. A good approach is to raise a high-priority alert for any certificate from an unexpected CA and a lower-priority notification for expected ones.
Publish CAA records and restrict account bindings
A Certification Authority Authorization (CAA) record is a DNS entry that lists the CAs allowed to issue certificates for your domain. CAs are required to check it. Publish CAA records that name only the CAs you use. Where your CA supports it, add the extension that ties issuance to a specific account with that CA. Add a reporting address as well, so CAs can tell you about refused requests.
Know the limits. CAA lives in DNS. An attacker who controls your domain’s delegation through a compromised registry can serve their own CAA records. CAA raises the cost of opportunistic attacks but does not stop an attacker who already controls your DNS.
Lock the domain at registrar and registry level
Most registrars offer a transfer lock, and many registries offer a stronger service usually called registry lock. With registry lock, changes to name servers or contact details need a manual, out-of-band verification step. Enable both where they are available, and protect your registrar account with strong, phishing-resistant multi-factor authentication.
Consider DNSSEC too. It lets resolvers check that DNS answers have not been tampered with. Again, be realistic: registry lock and DNSSEC both depend on the registry’s own systems. If the registry itself is breached, an attacker with enough access may be able to get around them. They still close off many other routes, such as a hijacked registrar account.
Report and revoke anything unauthorised
If you find a certificate you did not request, contact the issuing CA through its published problem-reporting channel. Include the certificate’s serial number or CT log entry and explain why it is unauthorised. Industry rules set by the CA/Browser Forum require CAs to investigate such reports and revoke certificates that were issued improperly within set deadlines.
Next, check your domain’s delegation and DNS history to find out whether and when your name servers were changed. Review logs for signs that traffic was redirected. Revocation works unevenly in browsers, so treat any window during which a fraudulent certificate was valid as a possible interception period.
Mistakes people actually make
The most common mistake is monitoring only the main domain. Attackers often target forgotten domains and unusual subdomains because fewer people watch them. Another is setting up CT alerts and then sending them to an unmonitored inbox, or filtering them so heavily that unexpected issuers slip through.
Organisations also overestimate CAA and DNSSEC. They treat these controls as complete protection when both depend on DNS infrastructure an attacker may already control. Some teams delay reporting a suspicious certificate while they investigate internally, which extends the period in which it can be misused. Others revoke the certificate but never check how the attacker passed validation, which leaves the same route open for next time.
When this approach is the wrong choice
This approach suits domain owners. It does little for people who only browse the web. Ordinary users cannot usefully watch CT logs for services they do not run, and their best protection is keeping browsers and operating systems updated so that revocations and distrust decisions reach them.
It is also not enough on its own for organisations that face determined, well-resourced attackers. Monitoring detects misuse after issuance and does not prevent it. Those organisations should also use certificate pinning carefully where appropriate, use mutual authentication for sensitive internal services, and work directly with their registry and CAs on escalation procedures.
Frequently asked questions
What is a counterfeit TLS certificate?
A counterfeit or unauthorised TLS certificate is technically valid and issued by a trusted certificate authority, but it was requested by someone who does not legitimately control the domain. Browsers trust it because it looks the same as a genuine certificate. An attacker who holds one, and who can also redirect traffic, can impersonate the website without triggering the usual browser security warnings.
How can hacking a domain registry produce valid certificates?
A domain registry holds the records that say which name servers answer for each domain under its top-level domain. An attacker who changes those records can redirect a domain’s DNS to servers they control. Certificate authorities verify domain control through DNS or web checks, so the attacker can pass validation and receive a certificate the CA believes is legitimate.
Can Certificate Transparency stop fraudulent certificates?
Certificate Transparency does not stop a certificate from being issued. It makes issuance public. Because major browsers generally require certificates to be logged, an unauthorised certificate usually appears in public logs where the domain owner can see it. Its value depends on someone actually watching the logs and acting quickly when an unexpected certificate appears.
Should ordinary users do anything after a certificate breach?
Ordinary users have limited direct options. The most useful steps are to keep browsers and operating systems updated so revocations and trust changes take effect, to be cautious on untrusted networks such as public Wi-Fi, and to pay attention to any security warnings the browser shows. Detecting and revoking fraudulent certificates is mainly the job of domain owners and certificate authorities.
Sources and further reading
- Ars Technica: the report on the registry compromises and the resulting unauthorised certificates
- CA/Browser Forum: the Baseline Requirements that govern how publicly trusted certificates are issued and revoked
- Internet Engineering Task Force: the standards documents defining Certificate Transparency, CAA records and DNSSEC
- Certificate authority and browser vendor documentation on CT monitoring and problem reporting
Surfaced from the rss:arstechnica signal “domain registry certificate breach”. AI-assisted draft, editorially reviewed.
