Live data from Hacker News

Easy HTTPS for your private networks

getlocalcert.net

11–20 of 126 posts

Re: Easy HTTPS for your private networks

#11
post #9
post #5

I recommend just using something like XCA [1]. Just configure your own root CA and distribute it. [1] https://hohnstaedt.de/xca/

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…

https://docs.getlocalcert.net/acme-clients/caddy/

Re: Easy HTTPS for your private networks

#12
post #4

Haven't used this myself, but I did find out about Lego ( https://github.com/go-acme/lego ) recently and used it to get a Let's Encrypt cert for a local network website I have using the DNS challenge. It was fairly straight forward, $ export NAMESILO_API_KEY=... $ export NAMESILO_POLLING_INTERVAL=10 $ export NAMESILO_PROPAGATION_TIMEOUT=1800 $ export NAMESILO_TTL=3600 $ lego --email --dns namesilo --domains *. .com r…

LEGO works great for this kind of thing. If you want to try with a localcert.net domain, the instructions are here: https://docs.getlocalcert.net/acme-clients/lego/

Re: Easy HTTPS for your private networks

#13
Somewhat related - I made a bridge server [1] that lets ACME clients use standard RFC2136 to solve DNS-01 challenges for internal names without them needing credentials for the actual DNS backend (Route 53 in my case).

[1] https://github.com/schlarpc/rfc2136_bridge/blob/main/src/rfc...

Re: Easy HTTPS for your private networks

#14
Interesting idea, but I think I'll stick with DNS challenge and LetsEncrypt. Lazy me really needs to finally sit down and automate the process (all the pieces are in place on my registrar's side). Did the private CA thing for almost two decades, and yes, it was a PITA, but even that was mostly because I failed to invest the time to automate it (Linux and Windows devices aren't _that_ hard to manage with OSS tools, printers might be a harder challenge; Android refusing to play nice with private DNS just makes it easier to disregard it altogether, as do all those IoT firmwares that don't even pretend to give you a choice). Ultimately, the current infrastructure, like that for message encryption, is just too damn convoluted. Eventually it might get fixed, but I'll probably be long retired to an Internet dead zone by then (raising goats can't be harder than managing fleets of application servers, can it?).

Re: Easy HTTPS for your private networks

#15
post #9
post #5

I recommend just using something like XCA [1]. Just configure your own root CA and distribute it. [1] https://hohnstaedt.de/xca/

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 cafeteria menu is hosted over HTTPS? Save the black hats some time and just email them the Visio of your core network.

If you don't have access to install the root certificate then by definition you don't control the private network, simple as that.

> when you want to share the application with others

This is literally the definition of no longer a "private network".

Re: Easy HTTPS for your private networks

#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 work for tools like curl, wget "openssl s_client", but not for browsers. (In my notes some place I am too lazy to go and read there is a reference to the RFC that documents that you do not have to use the subject/CN, mēh)

There are other tools (than openssl) that do this to.

Using this service means you really do not have a private network

Re: Easy HTTPS for your private networks

#17
post #9
post #5

I recommend just using something like XCA [1]. Just configure your own root CA and distribute it. [1] https://hohnstaedt.de/xca/

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…

Yes you need to install the Root CA into each device's root of trust.

Inconvenient? Maybe. Security rubs against the grain of convenience, true

Re: Easy HTTPS for your private networks

#18
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…

> 99% of "private networks" don't need HTTPS for most things, full-stop.

The encryption HTTPS provides isn't important if you trust your network. However server authentication is important if your devices move between networks (phone, laptop, etc). Applications don't know you switched networks, they just want to connect and will happily send sensitive data to an attacker if you ever connect to a malicious network. There was an example of `git push` leaking the entire commit history mentioned on HN not too long ago.

Re: Easy HTTPS for your private networks

#19
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 love this idea. Except I have devices on my network that don't allow me to do that. Company lock downs etc.

So I just pull in stuff from LetsEncrypt.

Re: Easy HTTPS for your private networks

#20
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 love this idea. Except I have devices on my network that don't allow me to do that. Company lock downs etc. So I just pull in stuff from LetsEncrypt.

As a rule I don't connect to my local services from my company laptop—it sits in the guest network isolated from the rest of the network.
Post reply on HN