Selfhosted
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
view the rest of the comments
Would that even work? Pointing my domain to a 192 IP address? I don't see how that would work.
You can use a DNS challenge to show you are in control of the domain without having anything exposed to the net. Essentially LE gives you a special value you have to add as a TXT DNS entry. LE will check if this record exists for your domain, and gives you a certificate, no public IP involved. This even allows you to create wildcard certificates.
Yeah, but you'd need to own a public domain and use it for your LAN, no? Or would it be possible to get a letsencrypt certificate for
example.local?I recently moved my internal network to a public domain. [random letters].top was $1.60 at porkbun, and now I can do DNSSEC and letsencrypt. I added a pre-hook to LE's renew that briefly opens the firewall for their challenges, but now I'm going to have to look at the DNS challenge.
Almost everything I do references just hostname, with dns-search supplied by dhcp, so there was surprisingly little configuration to change when I switched domains.
In order to automate the DNS challenge the LE bot needs the DNS server to have an API and needs an API access token. See if your DNS service is among the ones supported.
How are you dealing with mDNS and your custom domain? Isn't it causing... issues and mismatches?
Haven't noticed any issues, but I'm not intentionally using mDNS. dhcpd tells all the clients where the nameserver is and issues ddns updates to bind, so I haven't needed any of the zero-config stuff. I did disable avahi on a linux server, but that was more because it was too chatty than caused any actual problems. I wouldn't think there would be any more issues between mDNS and a fake domain than between mDNS and a real, big-boy domain on the same network.
“Big boy domains” on a network aren’t very easy to deal with. For instance sometimes you’ve devices in your network running DNS queries for your devices and they end up leaking to the outside because well… they’re FQDN… I also have experience mDNS issues due to some reason it seems to slow down a lot once you’re not using .local as your domain as well.
Would this work offline? Say a device only has access to LAN; no outside access. Can it still verify correctly?
The verification part is done by the LE server with your DNS server so that's not a problem. But you need to connect to the internet to launch the renewal process and to get the new certificates.
Like the other commenter said, you can use Let's Encrypt without needing to expose anything on your network to the internet. I set it up on my network a couple of weeks ago using this guide; I couldn't get caddy to work with duckdns but it worked with Cloudflare without any trouble.
The article sounds like you could have the A records on a local DNS service like Unbound or Pi-hole instead of public DNS. I guess maybe they just need to be defined somewhere that they'll resolve for your Caddy instance.
After looking at my cloudflare records, it seems I misremembered my setup.