←back to thread

314 points Bogdanp | 10 comments | | HN request time: 1.11s | source | bottom
1. sschueller ◴[] No.44385074[source]
What about internal IPv4 addresses? Can we have browsers ignore 192.168.x.x, 172.16.x.x and 10.x.x.x if we can't get certs for those or can we get a public wildcard for internal networks?
replies(4): >>44385117 #>>44385282 #>>44385784 #>>44386470 #
2. cpach ◴[] No.44385117[source]
I don’t believe that makes sense in the context of certificates generated by a public CA. Unlike domain names, there’s not one owner of 10.10.10.10, there are millions of “owners”…

But what problem is it that you want to solve?

For local development, one can use a tool such as mkcert. For shared internal resources (e.g. within a company), it’s probably easier to use a TLS cert tied to a domain instead of using naked IP addresses.

replies(1): >>44386218 #
3. jeroenhd ◴[] No.44385282[source]
If you can somehow prove that your device can manage to have a private key that will never be extractable then you should already be able to do that with any regular CA.

The problem with certificates for internal addresses is that every single time someone tries to pull it off, it doesn't take long for someone to buy one of those devices, extract the private key, and then post about it online, requiring the key to be revoked immediately.

There is a solution to that, of course. If you trust your device, import its certificate manually so you can visit the page without errors, or if you have a lot of devices, set up a certificate authority to distribute these certificates. There are open source ACME servers that'll let you publish certificates the exact same way you'd do with Let's Encrypt, except now you can keep everything local.

4. yread ◴[] No.44385784[source]
Point your dns to an existing public server, get a cert, copy it to internal server, point your dns to 192.168.... address and copy the cert and key over.

Only problem is some routers blackhole dns responses pointing to local addresses so you need to test it

replies(1): >>44386248 #
5. sschueller ◴[] No.44386218[source]
My cameras are internally accessibly via https.

Every time I open a browser I need to click two buttons to get past the certificate error. Sure I could configure a real domain, do split DNS and get a certificate but these cameras require manual uploading a certificate. I would need to do this every three months for every camera and eventually even more frequently.

replies(2): >>44386454 #>>44386695 #
6. sschueller ◴[] No.44386248[source]
With automated certs having shorter and shorter expiration this becomes a tedious waste of time just so one can access ones cameras without having to click past the browser warnings.
7. arccy ◴[] No.44386454{3}[source]
and IP certs would help how? you'd have to upload every 6 days.

just run your own CA with ~infinite lifespan.

8. arccy ◴[] No.44386470[source]
Browsers shouldn't ignore private networks. your private network might just be your local router, someone else's might span across the globe.
9. throw0101c ◴[] No.44386695{3}[source]
There are numerous tutorials on running your own private certificate authority (CA):

* https://smallstep.com/blog/private-acme-server/ ; https://smallstep.com/blog/build-a-tiny-ca-with-raspberry-pi...

* https://openvpn.net/community-resources/setting-up-your-own-...

* https://www.digitalocean.com/community/tutorials/how-to-set-...

Import the CA's root cert on your browsing devices and anything it issues will be trusted.

replies(1): >>44387328 #
10. cpach ◴[] No.44387328{4}[source]
Good idea. In Firefox, one could have a separate profile for this, so that the CA cert is not imported in one’s general profile.

Another option could be to put the cameras behind a reverse proxy (e.g. Nginx or Envoy) and terminate TLS there.