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