Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Easy HTTPS for your private networks

getlocalcert.net

Post reply on HN
Print view View original

41–50 of 126 posts

Re: Easy HTTPS for your private networks

#41

Post by jart »

worik wrote: post #16

This is unnecessary It is straightforward to create your own Root CA and use it to sign certificates for your private network, using openssl. Ensure that you implement the V3 extensions with @altnames, for the certificates you issue, with a "DNS => " (or you can use an IP address instead of FDN. I have not experimented with that). .local domain names work fine If you do not implement "@altnames" the certificate will…

If you use the Redbean web server, I put a lot of thought into making local network SSL easy. https://redbean.dev/#ssl Basically all you have to do is create a single key signing key which is installed on all your client devices. Then whenever you want to spin up a web server on any given host, you just give Redbean access to the key signing key, and it'll create RSA/ECDSA serving certificates automatically, which list all of the local system's hostnames and network IPs in the correct manner (which is a nightmare to figure out how to get OpenSSL to do). In fact you can even embed the key-signing key inside your Redbean so that when you SCP it to another machine and run it via SSH, it'll just do the right thing there as well, and Chrome won't shut it down. Or you could email your redbean single-file executable to a coworker, who just has to double click on the thing, and it'll start up a valid HTTPS server on their workstation which you can access, for easy local web dev collaborations.

Re: Easy HTTPS for your private networks

#42

Post by soraminazuki »

housemusicfan wrote: post #15
abound wrote: post #9

Earlier quoted context omitted.

Doesn't that require being able to add your root CA on each device you access the application from? That can be a chore in some cases, esp when you want to share the application with others. For services I host on my Tailscale/Headscale network, I just use DNS challenges. With Cloudflare and Caddy, it's as straightforward as adding: tls { dns cloudflare {env.CLOUDFLARE_AUTH_TOKEN} } to the site's configuration in the…

This is a poor solution to a non-problem. 99% of "private networks" don't need HTTPS for most things, full-stop. Those that do, the correct solution is to deploy a private CA and use internal DNS. The implication being you do not trust your network. So the solution is to.....use public DNS and Let's Encrypt garbageware and leak details of your internal network so you can pretend you're now more secure because the caf…

> This is a poor solution to a non-problem. 99% of "private networks" don't need HTTPS for most things, full-stop.

The problem with your security model is that you assume your private network is flawless. Do you really think you can trust every device that connects to your network to be secure? Including your Wi-Fi router? Because I don't, even for devices I personally bought. Even less so in a corporate setting.

Re: Easy HTTPS for your private networks

#43

Post by 8organicbits »

worik wrote: post #16

This is unnecessary It is straightforward to create your own Root CA and use it to sign certificates for your private network, using openssl. Ensure that you implement the V3 extensions with @altnames, for the certificates you issue, with a "DNS => " (or you can use an IP address instead of FDN. I have not experimented with that). .local domain names work fine If you do not implement "@altnames" the certificate will…

I've been pretty frustrated with how private CAs are supported. Your private root CA can be maliciously used to MITM every domain on the Internet, even though you intend to use it for only a couple domain names. Most people forget to set Name Constraints when they create these and many helper tools lack support [1][2]. Worse, browser support for Name Constraints has been slow [3] and support isn't well tracked [4]. Public CAs give you certificate transparency and you can subscribe to events to detect mis-issuance. Some hosted private CAs like AWS's offer logs [5], but DIY setups don't.

Even still, there are a lot of folks happily using private CAs, they aren't the target audience for this initial release.

[1] https://github.com/FiloSottile/mkcert/issues/302

[2] https://github.com/cert-manager/cert-manager/issues/3655

[3] https://alexsci.com/blog/name-non-constraint/

[4] https://github.com/Netflix/bettertls/issues/19

[5] https://docs.aws.amazon.com/privateca/latest/userguide/secur...

Re: Easy HTTPS for your private networks

#44

Post by throwanem »

attentive wrote: post #36
worik wrote: post #16

This is unnecessary It is straightforward to create your own Root CA and use it to sign certificates for your private network, using openssl. Ensure that you implement the V3 extensions with @altnames, for the certificates you issue, with a "DNS => " (or you can use an IP address instead of FDN. I have not experimented with that). .local domain names work fine If you do not implement "@altnames" the certificate will…

What is often not straightforward is trusting this CA on every existing and future client.

Especially if it's an iPhone.

Re: Easy HTTPS for your private networks

#45

Post by jart »

8organicbits wrote: post #43
worik wrote: post #16

This is unnecessary It is straightforward to create your own Root CA and use it to sign certificates for your private network, using openssl. Ensure that you implement the V3 extensions with @altnames, for the certificates you issue, with a "DNS => " (or you can use an IP address instead of FDN. I have not experimented with that). .local domain names work fine If you do not implement "@altnames" the certificate will…

I've been pretty frustrated with how private CAs are supported. Your private root CA can be maliciously used to MITM every domain on the Internet, even though you intend to use it for only a couple domain names. Most people forget to set Name Constraints when they create these and many helper tools lack support [1][2]. Worse, browser support for Name Constraints has been slow [3] and support isn't well tracked [4]. P…

Your private root CA can only be used maliciously if it's compromised. If you use certificate transparency to publicly leak all your local network administrative activities, then you won't need to worry about someone compromising your network because you've already compromised yourself.

Re: Easy HTTPS for your private networks

#46

Post by 8organicbits »

jart wrote: post #41
worik wrote: post #16

This is unnecessary It is straightforward to create your own Root CA and use it to sign certificates for your private network, using openssl. Ensure that you implement the V3 extensions with @altnames, for the certificates you issue, with a "DNS => " (or you can use an IP address instead of FDN. I have not experimented with that). .local domain names work fine If you do not implement "@altnames" the certificate will…

If you use the Redbean web server, I put a lot of thought into making local network SSL easy. https://redbean.dev/#ssl Basically all you have to do is create a single key signing key which is installed on all your client devices. Then whenever you want to spin up a web server on any given host, you just give Redbean access to the key signing key, and it'll create RSA/ECDSA serving certificates automatically, which li…

Redbean may work well for a domain auto-registration idea I mentioned elsewhere [1]. I've been looking for an excuse to play with redbean.

[1] https://news.ycombinator.com/item?id=36675925

Re: Easy HTTPS for your private networks

#47

Post by jart »

housemusicfan wrote: post #15
abound wrote: post #9

Earlier quoted context omitted.

Doesn't that require being able to add your root CA on each device you access the application from? That can be a chore in some cases, esp when you want to share the application with others. For services I host on my Tailscale/Headscale network, I just use DNS challenges. With Cloudflare and Caddy, it's as straightforward as adding: tls { dns cloudflare {env.CLOUDFLARE_AUTH_TOKEN} } to the site's configuration in the…

This is a poor solution to a non-problem. 99% of "private networks" don't need HTTPS for most things, full-stop. Those that do, the correct solution is to deploy a private CA and use internal DNS. The implication being you do not trust your network. So the solution is to.....use public DNS and Let's Encrypt garbageware and leak details of your internal network so you can pretend you're now more secure because the caf…

> use public DNS and Let's Encrypt garbageware and leak details of your internal network

I've seen certbot take 1+ hour to install on GCE micro VMs because it's so bloated. I've tried implementing the ACME protocol to avoid needing to use it, but it's one of the most byzantine processes I've seen. Let's Encrypt takes so much leverage from the edge to give us something that costs a latte. It's how freedom dies.

Re: Easy HTTPS for your private networks

#48

Post by nine_k »

worik wrote: post #16

This is unnecessary It is straightforward to create your own Root CA and use it to sign certificates for your private network, using openssl. Ensure that you implement the V3 extensions with @altnames, for the certificates you issue, with a "DNS => " (or you can use an IP address instead of FDN. I have not experimented with that). .local domain names work fine If you do not implement "@altnames" the certificate will…

This sounds very much like the famous HN comment saying that Dropbox is unnecessary because you can construct an analog using rsync and half-dozen other tools.

It's like saying that having a chair is unnecessary because you have a log, an axe, a saw, etc, and can build a sit to your liking when need be.

The thing is that when the need actually comes to be, you want a seat right now and of a known working kind, and strongly prefer a comfortable one. So thank the carpenter.

Re: Easy HTTPS for your private networks

#49

Post by captn3m0 »

jart wrote: post #45
8organicbits wrote: post #43

Earlier quoted context omitted.

I've been pretty frustrated with how private CAs are supported. Your private root CA can be maliciously used to MITM every domain on the Internet, even though you intend to use it for only a couple domain names. Most people forget to set Name Constraints when they create these and many helper tools lack support [1][2]. Worse, browser support for Name Constraints has been slow [3] and support isn't well tracked [4]. P…

Your private root CA can only be used maliciously if it's compromised. If you use certificate transparency to publicly leak all your local network administrative activities, then you won't need to worry about someone compromising your network because you've already compromised yourself.

The risk in both of theses is vastly different.

A root CA leak is hard to detect, has tremendous consequences, and adding limitations to the cert (TLD/domain) don’t work across every OS.

OTOH, leaking the existence of your private services (which are likely inaccessible over the internet for the general attacker) is a much smaller risk, and can be contained with wildcard certs as a workaround.

Re: Easy HTTPS for your private networks

#50

Post by denkmoon »

step-ca is an excellent for running your own private CA with ACME support. Individual software support for defining your own acme directory isn't always there, but such is the life of running your a private PKI. Worst case, you manually issue a cert like you would have done anyway.
Post reply on HN