Hacker News Reader

Comment by jakobbuis | Hacker News Reader

This fails utterly when you can't control your clients. My student society for example ran into this problem. Students bring their own laptops and installing our root certificate on all of them is infeasible (if they even would allow us to do so). As a consequence, we need to expose critical internal services on the public internet, some of which contain private user data.

View on HN

If you let any student that brings their own laptop connect to it, then it's already pretty darn public.

And you don't actually have to expose it to the internet to get a certificate, you only have to give it a public name.

Additionally, if you let anyone bring their own device in a diverse semi-public environment like a school, you owe it to the students and faculty alike to provide them with some protection against creative types placing fake wifi access points in busy places, trying to play man-in-the-middle for any credentials and other stuff sent to your local services. HTTPS does that.

Using a proper FQDN for each service only makes everything easier to maintain.

You don’t need to expose them. You need to use public DNS records, but there is no reason those records have to point to public IPs.

e.g. my company uses *.int.cuvva.co which all point to IPs in the 10.0.0.0/8 block, but we still have HTTPS certificates for all of those.

> As a consequence, we need to expose critical internal services on the public internet, some of which contain private user data.

No, you just need to have a public DNS entry, no need for that service to be reachable from the internet.

foo.example.com can resolve to your private RFC1918 address, when you send the CSR to a CA, they'll verify your ownership of example.com.

A public domain name costs the price of a coffee (and less than a raspberry pi) and you can get a certificate for free with Let's Encrypt. There is really no reason to resort to a private CA unless you want to MITM your client's connection.

You don't need to expose your server to the public internet to use let's encrypt. I use DNS authorization and it works perfectly.

Even if you could I would highly recommend against doing that, given that this would grant you access to every https connection that isn't hpkp secured.

I actually have all webservices in my home network secured by https, all you need to do is click a cheap vps, install nginx and tinc, and then proxy /.well-known/acme-challenge/ to your internal servers. Either setup domain or ip hijacking so the public IP is routed inside your lan. Done.

If I can do this for me and my cat in my spare time, you can do this for your university.

> My student society for example

> need to expose critical internal services on the public internet, some of which contain private user data.

The heck? Are they aware of this? Might you get sued for this?

If you can’t control your clients - maybe use a captive portal style landing page with a link to install the local certificate or something along those lines, it’s also useful to have a wireless network (SSID/VLAN) for BYOD that just has internet access and as such doesn’t need the very and one that has access to internal services that does.

Reply on news.ycombinator.com