Can Let’s Encrypt be used on embedded devices that run a local webserver (think similar to a router configuration web panel)? There would be potentially thousands of these devices running the same local web server and the web server is used as a way to configure the device via a local network connection. Each device has a unique ID and could have a FQDN of “deviceid.companyname.com”.
I basically need HTTPS for a local web app that does not require the end-user to accept a self-signed cert with the nasty warning dialog browsers generally show.
We’ve had a couple of forum threads about versions of this topic before—I’ll try to see what earlier discussions I can find for you.
@jsha and @cpu, can you suggest anything in the way of best practices for this?
One thing I remember is that there was an effort to change browsers’ rules about mixed content when embedding resources from localhost URLs, but I don’t remember the exact new rule about this.
He already gave each device unique public subdomian, a think all he need is dns api for subdomain(it may sit behind NAT) and a rate limit increase.
Well, the devices don’t have these domains in the sense of a regular website. I am saying they have a unique ID that could maybe be used to set the hostname of the system, which in turn could maybe be used to access the device by that in the browser instead of the IP. The devices could be on various different private networks, depending on which customer owns them and how they connect them. The devices are basically IoT devices with intermittent connections over 3G when running normally. During configuration a human would connect to it over local ethernet connection.
I am not sure if that clarifies anything or makes it more confusing?
I think the way Plex did it is still considered pretty much best-in-class: https://blog.filippo.io/how-plex-is-doing-https-for-all-its-users/.
Note: If you are developing a Let’s Encrypt client for embedded devices, I have some extra recommendations:
- Don’t have your devices contact Let’s Encrypt directly. Instead, run an ACME proxy on your own servers. That way you have an easy way to measure how much traffic you are generating, and switch it off if your devices get out of control (this is unfortunately common). This also means you can control for future API changes.
- Make sure you can auto-update and restart all your devices in a rolling fashion (i.e. not all at once).
- Your devices should have persistent storage, and should write not only the account information, but also the status of errors and retries to that storage. This ensures that you can properly handle backoffs, and that devices don’t always start hammering the ACME server on restart (this is a pattern we’ve seen with lots of IoT devices).
- Each device should pick a random time of day to check status and renew. Don’t have all devices renew at midnight.
- Follow the best practices at https://letsencrypt.org/docs/integration-guide/.
That’s a very interesting read. It seems like it needs the https://plex.tv proxy in the middle which your user account links to, as well as where the PMS broadcasts its availability. plex.tv then under the hood does XHR to IP.HASH.plex.direct.
In my case there is no middle man, such as plex.tv. I think a user would have to point their browser directly to IP.HASH.plex.direct. This might not be a problem because IP is the same default on all local connections to these systems, and HASH (device ID) is known by the human.
I believe this would require an internet connection on the humans laptop (not always present) that is connecting to the device, otherwise how else would it know how to resolve plex.direct and thus P.HASH.plex.direct. I suppose the device could run a local DNS and do that job?
With no internet connection on either human laptop or device (until device 3G is configured), can SSL verification work and thus HTTPS work?
What are your thoughts?
Yep, I think the device knowing its public DNS name and serving that in local DNS is the most straightforward approach here.
Thanks for the help Jacob. I think I have enough to start prototyping something. One last question though - Plex partnered with DigiCert to get a wildcard cert. Can the same kind of certs be obtained through Let’s Encrypt?
Yes. You can obtain a certificate for a wildcard domain name with Let’s Encrypt the same as any other certificate with two caveats:
- It isn’t supported with the legacy ACME v1 API
- Wildcard identifiers have to be authorized using a DNS-01 challenge type (not HTTP-01, or TLS-ALPN-01).
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.