tl;dr: MCUs are space-constrained and often don't include root certs that aren't used by the one host they talk to.
In my experience it's equally likely they just don't do validation to begin with. For example, my Elk M1XEP (physical security system's Ethernet expander) runs a configuration server with and without TLS. They recommend with, but it uses a self-signed certificate, and the crappy VB.NET configuration program doesn't validate the cert in any way, so it can be trivially MITMed. The Elk M1XEP also can connect to a user-chosen alarm monitoring service ("central station") over the Internet. I don't think it uses TLS at all for this. I think there's optional shared secret auth/encryption?
Over a decade ago, I created an AWS ELB to serve a production API. It was HTTPS-only, using an Amazon-signed certificate served from ACM for my employer's domain. Right after deployment, logs showed a regular pattern of 404s trying to POST/PUT to my API at paths I didn't support. Thousands of requests per hour, and they continued for days. It didn't look like a DoS--the paths looked like someone else's API.
I got curious what all the traffic was, so I added a route to the API that saved some of the uploaded data. It was live home surveillance video and photos! Indoors, outdoors, baby monitors, living rooms, etc. It was pretty easy to find which vendor's hardware was doing this (from headers, paths, watermarks) and I reached out to their security contact to let them know what I found. They responded generically but didn't seem to care that much.
In short, because HTTPS was required, and an ELB gets assigned IPv4 addresses arbitrarily, I can only conclude that a whole fleet of home security cameras were sold across the US that hard-coded the IP address of their cloud server and had certificate validation disabled.
This is unfortunately accurate, sometimes due to real constraints and more often due to loose threat models. I am hopeful that more open source firmware options (e.g. Zephyr RTOS) and more software investment from silicon vendors is helping to change the status quo. That being said, we are still a long way away from a "Let's Encrypt movement" for embedded devices.
IMO this should always be pushed back against, because it's not a valid excuse. If the hardware is too constrained to support appropriate security then that hardware is not appropriate for the application (or no longer appropriate for the application, as the story often goes).
Unless you plan to assign your Ethernet expander a domain name, how do you expect it to participate in WebPKI? The vendor similarly has no interest in explaining its buyers how to do that so it can connect "securely" to their particular alarm monitoring service.
There are some goodish options for how we could secure communications with local network devices hosting simple configuration WebUIs, but the browser vendors have overwhelmingly demonstrated that they have no interest in any of them. So what you ship is HTTP, not even the self-signed certificate, that just gets scary messages.
(What the browser vendors seem to want, to be clear, is that your gadget reaches out securely to the Vendor Cloud^TM, and you similarly use your Google and Apple notarized smartphone to reach out to that same Cloud, so you can talk to the hardware sitting a meter away from you)
> Unless you plan to assign your Ethernet expander a domain name, how do you expect it to participate in WebPKI?
Well, it does support DDNS, [1] so presumably some people do assign it a domain name. But I don't expect it to participate in WebPKI necessarily. That's not the only way to secure communication from the config program to the device, e.g.:
* The routers I worked on in 2006 had baked-in keys/certs signed by our own CA with cn based on serial number rather than reachable customer-chosen FQDN. That's not WebPKI but it actually works. Elk's configuration software knows the expected serial number and could use a similar approach. The configuration is not http-based (much less browser-based) anyway.
* It'd be better to just punt and say the communication should be secured by proxy or VPN or something than to offer TLS in a misleading way and suggest it should be directly exposed to the Internet.
As for the Ethernet expander to the central station, that totally could use TLS and WebPKI.
I don't think that applies here. The trust store contains the _root_ certificate, not these intermediates.
The main eMudhra root cert backing these intermediates is "emSign ECC Root CA - G3", which was issued back in 2018 and was widely trusted for TLS way before these intermediates were created. The certs were also cross-signed by Sectigo using their "AAA Certificate Services" which was issued in 2004 (!!!) and was trusted in TLS stores until 2025 (after that it got removed/demoted to email signing only, depending on the store).
Everything which trust one of those roots will trust the intermediates (putting aside revocation, CT checks, lack of ECC support, etc) so the window is much much longer. The AAA does expire at the end of 2028 though!
Of all the places for what is otherwise eMudhra's epic fail, various MCUs was the one place I thought perhaps there'd be some silver lining. Some interesting and good, for the hackers: to get to have some chance to see what their devices are doing, to man-in-the-middle those conversations home those devices in our homes are doing, and see what they are saying.
Fun fact: esp-idf includes an x509 Certificate Bundle API[0] that will pull in the entire Mozilla trust store by default. However, they will be stripped unless firmware calls `esp_crt_bundle_attach`. There is an issue[1] tracking removal of the eMudhra root CA certificate.
IoT devices typically run on MCUs and they have WiFi connections, often. The price of MCUs with WiFi has gone down dramatically. Often $5 or less for a MCU capable of WiFi and usually Bluetooth. Think, ESP32-S3 and such.
tl;dr: MCUs are space-constrained and often don't include root certs that aren't used by the one host they talk to.
In my experience it's equally likely they just don't do validation to begin with. For example, my Elk M1XEP (physical security system's Ethernet expander) runs a configuration server with and without TLS. They recommend with, but it uses a self-signed certificate, and the crappy VB.NET configuration program doesn't validate the cert in any way, so it can be trivially MITMed. The Elk M1XEP also can connect to a user-chosen alarm monitoring service ("central station") over the Internet. I don't think it uses TLS at all for this. I think there's optional shared secret auth/encryption?
Over a decade ago, I created an AWS ELB to serve a production API. It was HTTPS-only, using an Amazon-signed certificate served from ACM for my employer's domain. Right after deployment, logs showed a regular pattern of 404s trying to POST/PUT to my API at paths I didn't support. Thousands of requests per hour, and they continued for days. It didn't look like a DoS--the paths looked like someone else's API.
I got curious what all the traffic was, so I added a route to the API that saved some of the uploaded data. It was live home surveillance video and photos! Indoors, outdoors, baby monitors, living rooms, etc. It was pretty easy to find which vendor's hardware was doing this (from headers, paths, watermarks) and I reached out to their security contact to let them know what I found. They responded generically but didn't seem to care that much.
In short, because HTTPS was required, and an ELB gets assigned IPv4 addresses arbitrarily, I can only conclude that a whole fleet of home security cameras were sold across the US that hard-coded the IP address of their cloud server and had certificate validation disabled.
This is unfortunately accurate, sometimes due to real constraints and more often due to loose threat models. I am hopeful that more open source firmware options (e.g. Zephyr RTOS) and more software investment from silicon vendors is helping to change the status quo. That being said, we are still a long way away from a "Let's Encrypt movement" for embedded devices.
> sometimes due to real constraints
IMO this should always be pushed back against, because it's not a valid excuse. If the hardware is too constrained to support appropriate security then that hardware is not appropriate for the application (or no longer appropriate for the application, as the story often goes).
To be clear, I agree that it is not a valid excuse and pushback is warranted.
> physical security system
> can be trivially MITMed
Crazy how poor security can be even from a purported security vendor.
Unless you plan to assign your Ethernet expander a domain name, how do you expect it to participate in WebPKI? The vendor similarly has no interest in explaining its buyers how to do that so it can connect "securely" to their particular alarm monitoring service.
There are some goodish options for how we could secure communications with local network devices hosting simple configuration WebUIs, but the browser vendors have overwhelmingly demonstrated that they have no interest in any of them. So what you ship is HTTP, not even the self-signed certificate, that just gets scary messages.
(What the browser vendors seem to want, to be clear, is that your gadget reaches out securely to the Vendor Cloud^TM, and you similarly use your Google and Apple notarized smartphone to reach out to that same Cloud, so you can talk to the hardware sitting a meter away from you)
> Unless you plan to assign your Ethernet expander a domain name, how do you expect it to participate in WebPKI?
Well, it does support DDNS, [1] so presumably some people do assign it a domain name. But I don't expect it to participate in WebPKI necessarily. That's not the only way to secure communication from the config program to the device, e.g.:
* The routers I worked on in 2006 had baked-in keys/certs signed by our own CA with cn based on serial number rather than reachable customer-chosen FQDN. That's not WebPKI but it actually works. Elk's configuration software knows the expected serial number and could use a similar approach. The configuration is not http-based (much less browser-based) anyway.
* It'd be better to just punt and say the communication should be secured by proxy or VPN or something than to offer TLS in a misleading way and suggest it should be directly exposed to the Internet.
As for the Ethernet expander to the central station, that totally could use TLS and WebPKI.
[1] https://elk-manuals.s3.amazonaws.com/M1XEP_v2_Installation_M... page 14
Related:
https://news.ycombinator.com/item?id=50166579 - “eMudhra intermediate CA compromise” - 947 points | 19 hours ago | 408 comments
https://news.ycombinator.com/item?id=50177916 - "Eight Bits of Trust; eMudhra's CA keys cracked in milliseconds" - 604 points | 7 hours ago | 270 comments
Your device would also have to be pretty recent to ship any of these certs in a frozen cert store as they were only generated in April/May of 2025.
I don't think that applies here. The trust store contains the _root_ certificate, not these intermediates.
The main eMudhra root cert backing these intermediates is "emSign ECC Root CA - G3", which was issued back in 2018 and was widely trusted for TLS way before these intermediates were created. The certs were also cross-signed by Sectigo using their "AAA Certificate Services" which was issued in 2004 (!!!) and was trusted in TLS stores until 2025 (after that it got removed/demoted to email signing only, depending on the store).
Everything which trust one of those roots will trust the intermediates (putting aside revocation, CT checks, lack of ECC support, etc) so the window is much much longer. The AAA does expire at the end of 2028 though!
Of all the places for what is otherwise eMudhra's epic fail, various MCUs was the one place I thought perhaps there'd be some silver lining. Some interesting and good, for the hackers: to get to have some chance to see what their devices are doing, to man-in-the-middle those conversations home those devices in our homes are doing, and see what they are saying.
This fact alone though makes that very unlikely.
Fun fact: esp-idf includes an x509 Certificate Bundle API[0] that will pull in the entire Mozilla trust store by default. However, they will be stripped unless firmware calls `esp_crt_bundle_attach`. There is an issue[1] tracking removal of the eMudhra root CA certificate.
[0] https://docs.espressif.com/projects/esp-idf/en/latest/esp32/...
[1] https://github.com/espressif/esp-idf/issues/19282
I must have missed when de facto definition of MCU started including being on the network and doing crypto :-)
IoT devices typically run on MCUs and they have WiFi connections, often. The price of MCUs with WiFi has gone down dramatically. Often $5 or less for a MCU capable of WiFi and usually Bluetooth. Think, ESP32-S3 and such.
Right, I'm used to the name referring to 8-bit parts without MMUs. How the times have changed...
TL;DR: Your MCU likely doesn't have enough space to dedicate so much of it to a full CA store, so it is unlikely to trust those CAs (claims the post).
So many words for such a simple point/claim...