[Settle] Deployment experience - public CA certs for LAN devices (devicessl)

[Adam Raźniewski <[e-mail]>]

Hey all,

I saw the call for volunteers for the problem statement in February, so
maybe this insight will be useful.

We are small Polish electronics manufacturer.
We make time and attendance terminals and firmware for other companies, and
also other devices.
Our customers are restaurants, shops, small offices. No IT team, devices
are self-installed.

Honestly, from manufacturer side it's really strange that in 2026 this is
still not solved. Every device on a LAN has a web panel, and there is still
no normal way to serve it over HTTPS (without warnings).
Sniffing a local network today is trivial, one cheap device or an infected
laptop is enough, and passwords to the panel go in plain text or behind a
self-signed cert that everyone clicks through.

And we also have to comply with EN 18031-1, the harmonised standard for the
EU Radio Equipment Directive (Delegated Regulation 2022/30, mandatory since
August 2025). For a device with a web panel on a LAN this means:
- SCM-1 (6.5.1): the device shall always use secure communication for
security and network assets, e.g. panel passwords. Exceptions are only
physically closed environments or a VPN - not a restaurant Wi-Fi.
- SCM-2 (6.5.2): integrity and authenticity protection, i.e. against
man-in-the-middle. The standard itself says the way the initial trust
relationship is established is "crucial".
- SCM-3 (6.5.3): confidentiality, so encryption.
- CCK-3 (6.9.3): preinstalled keys must be practically unique per device,
so no shared key or cert in the firmware.


So "just use HTTP" is not an option anymore.
Self-signed gives encryption but not authenticity, since users click
through the warning.
And "install your own CA" is not an option for a restaurant owner. There is
simply no compliant option that normal people can use.

And honestly, I suspect a lot of manufacturers don't really comply with EN
18031-1 not because they don't care, but because there is no practical way
to do it.



We built our own thing, to somehow WORKAROUND a problem.
But from user perspective and user experience to be honest it's... You know
the word (bad at least).
a) every device has its own zone <device-id>.d.devicessl.com
b) device generates its key itself, sends only CSR
c) we do DNS-01 on our own DNS and get Let's Encrypt wildcard *.<device-id>.
d.devicessl.com
d) private IP is encoded in the name, e.g. 192-168-1-50.<device-id>.
d.devicessl.com

So it results in "green" padlock on 192-168-1-50.DEVICE_ID.d.devicessl.com

It works, but with problems:
1. many routers block DNS answers with private IPs (rebinding protection),
customer must add exception
2. needs internet, offline sites fall back to self-signed
3. no site isolation between devices - we applied to PSL and were declined
(LAN only use case) - cookie issue
4. Cumbersome - nobody will remember it.


Also, today we can't even properly use mDNS in the local network. Our
devices announce themselves as e.g. rcp-a1b2c3d4.local, which is the most
natural way to find a device on a LAN. But we can never open it over HTTPS
with a valid cert, because no public CA will issue a certificate for
.local. So the "nice" local name is exactly the one that can never be
secure.


A standard would *really* help.

My dream is that user can have encrypted and authenticated connection on
https://please-its-just-my-local-device.local
And we, as manufacturers of local IoT devices, have a super easy way to
achieve it.

Happy to share more details if it's useful.
Adam Raźniewski
https://adaraz.com