3 ms·

I actually just started using Let's Encrypt to issue certificates for web services (router config pages, Firewall, NAS server) on my local network. You _do_ nee

I actually just started using Let's Encrypt to issue certificates for web services (router config pages, Firewall, NAS server) on my local network. You _do_ need your own domain and DNS server so unfortunately it isn't free, but it _is_ definitely doable. Basically I just setup [acme-dns][1] on a VPS, pointed the relevant _acme-challenge domains at that server via a CNAME entry, and gave each device on my LAN an account on the acme-dns server so they can fulfill challenges at will. Unfortunately as you said that's probably a little too complex for the average user, not to mention domains and VPSes aren't free. Probably wouldn't be too expensive to offer as a service of some kind though; I'm only spending $3.50/month total, and I'm sure my VPS could handle _much_ more traffic than it currently does just fulfilling acme challenges for my LAN. [1]: https://github.com/joohoi/acme-dns https://github.com/joohoi/acme-dns

xg15 8y ago
It's good that there is at least a way to do it, but it's still absurd that showing a page from a server in a LAN on a browser in the same LAN now requires third-party services on the internet and incurs running costs. (* yes, you could simply tolerate the insecurity warning if you're ok with not using more recent JS/CSS features. I imagine though the warnings will become more obnoxious and the amount of features you can't use will grow.) (* yes, you can install your own root CA cert. For admin pages, this is even a reasonable thing to do - however, you'll need to do it on any machine that is expected to open your page. So say goodbye to raspberry pi media experiments or kiosk systems.)
- Ajedi32 8y ago
  The problem is that the address associated with a publicly trusted cert _has_ to be universal. We can't give users certificates for `https://192.168.1.1/` https://192.168.1.1/` or `https://my-router.local/` https://my-router.local/`, because then attackers could get certs for those names as well, which would defeat the whole purpose of HTTPS. DNS is well suited for allocating unique, memorable names to devices, but, as you said, it _does_ rely on third party services (registrars, at the very least) to operate. If we don't want to rely on third party services, we'll need to come up with an alternative to DNS that accomplishes the same goals.

xg15 8y ago

It's good that there is at least a way to do it, but it's still absurd that showing a page from a server in a LAN on a browser in the same LAN now requires third-party services on the internet and incurs running costs. (* yes, you could simply tolerate the insecurity warning if you're ok with not using more recent JS/CSS features. I imagine though the warnings will become more obnoxious and the amount of features you can't use will grow.) (* yes, you can install your own root CA cert. For admin pages, this is even a reasonable thing to do - however, you'll need to do it on any machine that is expected to open your page. So say goodbye to raspberry pi media experiments or kiosk systems.)

Ajedi32 8y ago
The problem is that the address associated with a publicly trusted cert _has_ to be universal. We can't give users certificates for `https://192.168.1.1/` https://192.168.1.1/` or `https://my-router.local/` https://my-router.local/`, because then attackers could get certs for those names as well, which would defeat the whole purpose of HTTPS. DNS is well suited for allocating unique, memorable names to devices, but, as you said, it _does_ rely on third party services (registrars, at the very least) to operate. If we don't want to rely on third party services, we'll need to come up with an alternative to DNS that accomplishes the same goals.