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…
Easy HTTPS for your private networks
11–20 of 126 posts
Re: Easy HTTPS for your private networks
#12Haven'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…
Re: Easy HTTPS for your private networks
#13[1] https://github.com/schlarpc/rfc2136_bridge/blob/main/src/rfc...
Re: Easy HTTPS for your private networks
#14Re: Easy HTTPS for your private networks
#15I 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…
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
#16It 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
#17I 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…
Inconvenient? Maybe. Security rubs against the grain of convenience, true
Re: Easy HTTPS for your private networks
#18Earlier 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…
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
#19This 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…
So I just pull in stuff from LetsEncrypt.
Re: Easy HTTPS for your private networks
#20This 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.