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

[Michael Sweet <[e-mail]>]

Adam,

Thank you for reaching out.  This is exactly the problem SETTLE hopes to solve...

> On Sep 25, 2026, at 10:10 AM, Adam Raźniewski <adam.razniewski=[e-mail]> wrote:
> ...
> 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

That's a creative way to get around the local hostname/IP changing, and presumably your DNS server just returns an A record for the given FQDN to make it all work?

> ...
> 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.

That was the point of my IoT-ACME draft:

    https://datatracker.ietf.org/doc/draft-sweet-iot-acme/

TL;DR: Your Wi-Fi router would provide a local ACME server that is used to generate certs for your local domain and/or mDNS.

Fixing this properly requires some coordination amongst the various client OS and router developers, along with (of course) the IoT devices themselves using the local ACME service to get their certs.  And there are security issues WRT secure/verifiable device identity to solve.

________________________
Michael Sweet