I simply cannot make any assumption about the network these devices will run, and can certainly not rely on any sort of DNS validation. Virtually 100% of the time the devices are addressed directly by IPv4. I really can't think of a solution for this situation.
For network you control your solution makes a lot of sense though.
https://blog.filippo.io/how-plex-is-doing-https-for-all-its-...
That makes a lot of sense for Plex, but it's really not applicable for my equipment.
If you were using Electron you wouldn't have to worry about browser support either as you'd just have to target Chrome/Blink.
Just brainstorming ideas here, someone will probably shoot me down.
All the end user device needs is a connection to the internet once per 90 days. The vast majority of networks have sufficient network connectivity for this.
If the vendor of your dumb device goes out of business, you can just keep using the device until it breaks down.
If the vendor of a "smart" device - or now anything with a modern web interface - goes out of business, the device will have a broken UX at best and at worst turns into a brick 90 days later.
In the end, browsers are now a platform and you have to register and pay a subscription fee to make use of them.
I'm no expert on long-tail use cases, but I'd imagine that most networks either have internet connectivity or they don't. I can't think of many situations where you'd only have internet once every 90 days.
Of course one could argue that 90 days long is enough so an employee could go around with a memory stick and manually copy the certificate to every device - which is theoretically possible but sounds like a ridiculous thing to do just to keep a web interface workable. (And even then, you'd somehow need a unique certificate for every device)
Having worked in broadcast news, I can think of hundreds.
News doesn't happen in the newsroom. It happens in the field. And very often in places without internet access. Sometimes for weeks or months at a time. (Think siege at Waco, plane crashes, hurricanes, etc.)
There’s not much point in doing broadcast news of you can’t file, and you can only file if you have an IP connection (we do have some non ip satelite but without IP you wouldn’t be able to do much in the way of production - no production system, no email, no phone)
Covering natural diaaaters is why we have bgans and generators and MREs and water cleaning kits. Internet access is as essential as any other high risk safety equipment, and there’s no point deploying if you can’t file back.
Is there no way to have a sideband of that used to broadcast/multicast am X.509 cert over a 90 day period?
Just going through the trouble of having the customer mess with their OS's DNS resolver to connect to the device is ludicrous. Can you even do it on Windows without having to deal with the hosts file manually?
Then they need to remember to update it when the IP inevitably changes because they've moved onto a new project with a different address plan, and they'll invariably forget to change it or forget how to do it or do it wrong and then call me to help them.
And on top of all that, no I can't really expect my devices to have internet access, not even once every 60 days. It's not uncommon for broadcast operations to use costly and critical satellite links for internet access, and they're not going to let random devices use that without a good reason. More generally, even if there's an internet connection available they're likely not to configure the gateway correctly, then complain when the night of the big event their browser refuses to connect to my equipment, saying that they're about to be h4x0r3d.
My use case is certainly a niche, but I think it's probably a significant niche given that everything and anything has web interfaces these days. Cameras have web interfaces for configuration, middle end smart switches and routers have web interfaces, I've even seen power plugs with web interfaces...
1. You set up a private PKI using a private CA. AWS will sell you one for $400/month. Install the public root in the trust stores of the clients and then issue 5 year private certs for either IP addresses, or for .local and use DNS-SD.
2. You create a private domain at private.example.com. You get letsencrypt to issue a wildcard for .private.example.com. Then you set up private DNS for that zone. Server cert needs to be updated every 90 days. That involves downloading a single PEM file from your internal network.
Then it's just a matter of the devices connecting to the internet at least once a year and doing a very simple "Hey, I'm $device and using $address. Issue me a cert plz."
I'm no expert, but wouldn't that make GP's company effectively a delegate CA? This seems like it would need a very close relationship with the original CA - and all just for a simple web interface.
> include ip addresses in the SAN.
Not sure if this may be different with intermediate certs, but you won't find any public CA that will add private IP addresses as a SAN - as this would undermine the whole security model. If any CA did this, Chrome would likely ban them quickly.
I'm sceptical a CA would let you do that with intermediate certs if there is any danger the leaf certs get into the wrong hands (e.g. because the devices are sold, someone reverse-engeneers one and manages to talk to the back-end service)