this post was submitted on 28 Jan 2025
17 points (94.7% liked)

Selfhosted

41524 readers
501 users here now

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:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. 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.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 2 years ago
MODERATORS
 

Yesterday I decided to start "officially" selfhosting. With almost no experience with Docker, I struggled for eight hours straight, but I finally have it working.

Currently, the two tools I am selfhosting with Docker Compose are LibreTranslate and spotDL. I'm only accessing them over the local network using a direct IP:PORT, so there's no domain name. I don't want to use a custom DNS, since it is fingerprintable online, so I want to keep it the same as my VPN.

With that said, I want to add encryption to the connections. I was able to generate my own self signed certificates with this command:

sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout ./certs/key.key -out ./certs/cert.crt

spotDL was easy to setup with these self signed certs, since it has command flags for --enable-tls, --key-file, and --cert-file. LibreTranslate has an environment variable for - LT_SSL=true, however it gives the following error:

libretranslate  | (URLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1006)')),)

That led me to this issue which is 2 and a half years old. LibreTranslate doesn't have a way to specify certificates that I know of.

I tried using Nginx Proxy Manager to create a reverse proxy, but I couldn't quite figure it out. (I also didn't understand Docker Compose at the time. I had a few hours to go before I did) NPM also seems to want Let's Encrypt certificates which can't be given without a DNS record. I tried manually providing certificates in the config file, but I don't quite understand NPM enough to be able to set it up properly on my own.

My requirements are:

  • No changing the DNS from my VPN's default
  • No port forwarding, everything should be accessed by the local network only
  • No email required (ability to use a fake email without risk is fine)
  • Only free and open source software
  • Modern security standards where available

I also would like help adding the self signed certificates as a permanent exception in Brave browser, if possible.

top 8 comments
sorted by: hot top controversial new old
[–] HybridSarcasm@lemmy.world 5 points 1 day ago

TL;DR: Op needs to sort out reverse proxy with SSL/TLS.

[–] ikidd@lemmy.world 3 points 1 day ago

If you take another stab at it, look for NPMPlus, its a better maintained fork. But yah, without a real domain, let's encrypt will be a pain to get to fly.

[–] rhymepurple@lemmy.ml 2 points 1 day ago

If you know your VPN's DNS server, you can change your local DNS so that it redirects your specified domains/subdomains to the appropriate, local IP address and all other requests would then use your VPN's DNS.

If you don't know your VPN provider's DNS server information, you may be able to still do something similar to the above depending on your setup. Otherwise, you could run your own DNS resolver or use a different DNS provider. I guess doing so could potentially be used to further fingerprint you, but the concern about "DNS fingerprinting" is moreso DNS leaks where your DNS queries are accessible to unintended parties due to improper configuration.

I believe the only other option would be to change your hosts file on each device you want to use to connect to your services, which is probably not the best approach and may be challenging/impossible for certain devices.

Also, unless you setup the self signed certs to be trusted on a network/domain level (or again on each individual device), you will likely get a warning/error about the self signed certs when accessing your services. You may need to work through this process each time the certs renew.

I recommend buying a domain if you do not already have one and finding a service that provides wildcard certification challenges. This would allow you to setup a valid, trusted certificate that you could reuse for all of your services. The only thing that you would need to provide is an email address (can be any email address) and your domain name (in addition to other information that may be required to setup an account at the cert provider, but you may already have an account there as it could be the domain name registrar or other services like VPS providers, Cloudflare, etc.). Since it is a wildcard cert, each subdomain does not need to be set publicly and if you only use the domain within your network, the domain does not need to be publicly associated with any IP address.

If you do go forward with that approach, you could use the wildcard cert directly within NginxProxyManager or other reverse proxies. They will also automatically update/maintain the cert for you.

[–] catloaf@lemm.ee 2 points 1 day ago

If you've got certs generated, you should be able to upload them to nginx proxy manager. https://anthonyconstant.co.uk/blog/f/local-ssl-certificate-using-nginx-proxy-manager-dockerportainer

[–] muntedcrocodile@lemm.ee 0 points 1 day ago (2 children)

https://www.youtube.com/watch?v=BKCj6A4CHV4

Not necessarily docker but gives a good vibe for self signed certs. Also i don't see why u need encryption if ur only accessing ur data over local network (I presume via a vpn) its unnecessary unless ur worried about someone snooping packets on ur lan.

Personally I have my services available to the internet with a letsencrypt cert for a domain served via nginx that served my services at relevent routes. SSL isn't really nessasary unless ur transporting across an untrusted network (such as the internet instead of over a VPN).

[–] False@lemmy.world 2 points 21 hours ago

Encryption in transit even internally is a good practice. That said, op is making life hard by refusing to use DNS.

[–] Voroxpete@sh.itjust.works 2 points 1 day ago (1 children)

Seconding this, I really can't see the point of encryption on local only connections. Are you ready worried about someone hacking your WiFi?

Anyway, if you do want to do a reverse proxy, I'll make my usual recommendation of Caddy instead. It handles certificates for you, using Let's Encrypt, so there's no need to add exceptions in your browser. And reverse proxying with Caddy is literally a one line config.

[–] AbidanYre@lemmy.world 2 points 1 day ago

I really can't see the point of encryption on local only connections

Browsers are starting to get pissy about http and once you have it done once it's like a half dozen lines to add caddy to whatever docker project you're spinning up.