Your device is not a browser

On 6 October 2026 Google said that attackers had compromised three country-code domain registries and used them to obtain HTTPS certificates, issued by real certificate authorities, for domains that were not theirs, several of Google's among them. Chrome blocked the certificates Google found. A connected device calling its server is not Chrome. This note is about what it would have done.

What happened

According to Google's account, the attackers compromised the registries of .gh, .sl and .as, changed DNS records, and obtained unauthorised certificates covering several Google domains and domains of other organisations. Google writes that it has "no reason to believe" the certificate authorities that issued them did anything wrong. Ars Technica reports that, holding the DNS records, the attackers passed the authorities' automated checks of who controls a domain. That Chrome had to block the certificates suggests it would otherwise have accepted them.

Chrome blocked the certificates for Google's own domains through CRLSets, the list it uses to block certificates in an emergency, and Google worked with the authorities that issued them to have those revoked, in its words "to protect users in clients other than Chrome". When Certificate Transparency logs showed certificates for other organisations, Chrome blocked those as well; Google does not say whether they have been revoked. It also writes that it cannot guarantee its analysis "identified every affected domain", and that Chrome's measures do not "reliably protect non-Chrome users". Its post does not name the other organisations or give a number of certificates.

A device is a client other than Chrome

A browser has a vendor that can send it a block list quickly. A device has the TLS library, the list of trusted authorities and the settings that were compiled into the firmware it runs. Whether a certificate like these could be used against your product is decided there. Four questions.

1. Whom does the device trust?

Some firmware projects compile in a whole public root list. ESP-IDF's certificate bundle, for one, comes by default with the complete list from Mozilla's root store, more than 130 certificates. With such a list any of those authorities can vouch for your server, and a certificate obtained through a hijacked registry would be accepted like the real one. A device usually talks to one or two servers. It can trust one authority. If that is your own, kept for device traffic, a certificate from any public authority is refused. If it is the one public authority you buy from, the list shrinks from more than 130 to one, but whoever controls your DNS can ask that same authority.

2. Does it check revocation?

Revocation is how Google meant to protect, for its own domains, the clients other than Chrome. It works only for a client that checks. Find out whether yours does, as you built it. Mbed TLS, the TLS library ESP-IDF builds on, tests a certificate against a revocation list only if your own code hands it one for the authority that signed the certificate; fetching the list is your job. Where nothing checks, a certificate that should not exist stays acceptable to the device until the day it expires, for anyone who can get between the device and its server.

3. Can you change the trust list in the field?

The list of trusted authorities is data, and it will have to change: an authority is distrusted, your own is replaced. In ESP-IDF the bundle is embedded in the application and changes with an over-the-air update. That update must not lean on the trust it is replacing. Have the device check the image's own signature, as in our note on updates, so that somebody holding a valid certificate for your update server still cannot install an image you did not sign. Add a version check, so that an old signed image is refused too. If you pin a single certificate or key, ship a second pin beside it, for a key you keep offline, and know the date the first certificate expires. Otherwise the pin locks out your own devices.

And over the connection itself: do not send a secret that can be used again, and give the commands that matter a signature of their own, with a counter, so that an old command cannot be played back.

4. What does the device's address hang from?

Google says its own systems were not compromised; the registries above its domains were. Every name depends on its registry, and .io and .ai are country codes, as .gh, .sl and .as are. For the name that is written into firmware, choose the registry on purpose, publish a CAA record that names the authorities allowed to issue for it, and watch the Certificate Transparency logs for certificates you did not ask for. The last two are Google's advice to domain owners, and Google is plain about the limit: CAA "can not prevent certificate issuance during an active DNS hijack". It counts once you have your DNS back, and the logs tell you after the fact.

A drill for the bench

Three checks. Count the authorities in your firmware's trust list and find the date the list was made. Put a test server behind your device's server name, on a test network of your own, with a certificate from a public authority you do not use, and see whether the device connects. Keep the test key on the bench, revoke the certificate afterwards, and see whether the device ever notices.

Sources

• Google: Chrome's Response to Recent ccTLD Registry Hijacks (6 October 2026)
• Ars Technica: Hackers obtain counterfeit TLS certificates for Google and other large services (6 October 2026)
• The Chromium Projects: CRLSets
• Espressif: ESP x509 Certificate Bundle, ESP-IDF programming guide
• Mbed TLS API: X.509 module, the notes on mbedtls_x509_crt_verify
• IANA: Root Zone Database
• RFC 8659: DNS Certification Authority Authorization (CAA) Resource Record

All notes

First published at newlinebreak.com/notes/your-device-is-not-a-browser.