Hacker News Reader

Comment by mook | Hacker News Reader

Yeah, I hate how it made housing things locally without a proper domain name very difficult. My router _shouldn't_ have a globally recognized certificate, because it's not on a publicly visible host.

There's certainly advantages to easily available certificates, but that has enabled browsers and others to push too far; to be sure, though, that's not really a fault of Let's Encrypt, just the people who assume it's somehow globally applicable.

View on HN

> My router _shouldn't_ have a globally recognized certificate, because it's not on a publicly visible host.

If you're not encrypting local network traffic then any rogue device on that network can decide to intercept it and steal your admin password. That's one of the biggest reasons why we adopted HTTPS in the first place - whether a host is public or not isn't relevant.

It doesn't need a "globally" recognized certificate signed by a public CA, self-signed ones are fine. At home I manage mine with XCA. I have a root CA that's installed on all of my devices, with name constrains set to ".internal", ensuring it can't be used to sign certificates for any other domains.

A related issue is that most consumer devices (both iPhone and current Android) make it impossible or extremely difficult to trust your own root CA for signing such certs.

Android is pretty easy, you just add it to the keystore and that's it. I've had my own CA long before Let's Encrypt, but now mostly only use it for non-public devices that can't easily use Let's Encrypt (printers, switches, etc).

You can add it to your user CA store, but no app will trust it since it's treated differently from the system CA store, which you can't modify without root or building your own ROM. In effect it is out of reach for most normal users, as well as people using security focused ROMs like Graphene, when ironically it can improve security in transit in many cases.

It's technically possible to get any Android app to accept user CAs. Unfortunately it requires unpacking it with apktool, adding a networkconfigoverride to the XML assets and pointing the AndroidManifest.xml to use it. Then restitch the APK with apktool, use jarsigner/apksigner and finally use zipalign.

Doesn't need a custom ROM, but it's so goddamn annoying that you might as well not bother. I know how to do these things; most users won't and given the direction the big G is heading in with device freedom, it's not looking all that bright for this approach either.

I mean it works fine for me on Chrome

A long time ago when I was playing with rolling my own PKI, each of Android, iOS, Chrome, Firefox, and even Internet Explorer allowed me to install a root CA by opening the .crt file. From what I remember, iOS popped up some warnings and added the cert as part of a profile, but it did work.

I know things like MDM/Intune/Group Policy/etc and such can A) faciliate doing this on a large number of devices and B) prevent users from doing this on their own.

Does this not work anymore?

I don't want to trust my own root CA as I don't trust myself to keep it secure.

I want to important it only for a specific set of domains. "Allow this rootca to authenticate mydomain.com, addmanager.com, debuggingsite.com", which means even if compromised it won't be intercepting mybank.com

You can absolutely do that with name constraints extension set on the root CA certificate. You should verify compatibility but it's pretty universally supported on modern browsers and consumer devices last I checked.

    nameConstraints=critical,permitted;DNS:.iso1631.internal

- "critical" ensures that any clients who don't understand this extension fail the certificate validation outright instead of ignoring it.

- "DNS:.iso1631.internal" limits the scope to all subdomains of the given domain, e.g. "www.iso1631.internal"

https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1....

If you generate the root CA sure. However name constraints aren't well supported.

A far better option would be to allow me, the user, to do this in the user agent. I can import my mitm cert and today I can trust it for "abc123.com" and point that to something I want to access in that manner for some reason, but tomorrow simply toggle that trust off.

If I find that I want to use a specific website and want to do something with the traffic, then I could point that DNS to my middle-box and turn that on in my browser. With name constraints I'd have to regenerate the root certificate with the new domain, and then re-import it.

the entire concept of the name constraints puts the power into the CA issuing person rather than the user.

Where are you finding that name constraints aren't supported? I've only come across that on embedded/IoT devices. They work fine for me across Firefox and Chrome on Linux, on Android, and they are supposed to work fine on Apple devices too.

> If I find that I want to use a specific website and want to do something with the traffic...

I agree but that's a different problem. If you just need a certificate for your router and some internal services (the original discussion), you can do that using an internal root CA and you have nothing to worry about as long as you using name constraints.

On IoT devices without nameConstraints support I just use an alternative CA certificate without name constraints (same key, different extensions).

Reply on news.ycombinator.com